Re: Question about loss and retransmission reporting
[email protected] Fri, 7 Dec 2018 17:13:59 -0500
| Newsgroups | gmane.network.argus |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_0C81E5EA-DDB2-49E5-A77A-9F0F0C6C26E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Edward, So better to look at retransmission requests. If you have a packet = stream captured at the originator of the TCP, there are a number of = scenarios where you won=E2=80=99t see any indication of loss, just = packets out of order. If the loss occurs on the return path from the = dest to the src, then you will not see any retransmissions / duplicates, = you will only see the packets that successfully show up. The indicator = of loss is the selective retransmissions that the src sends to the far = side. We can tell you which side the loss occurs on, so don=E2=80=99t print = out loss, print sloss and dloss. sloss is on the src -> dest path, and = dloss Is on the dest -> src path. Carter =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <http://qosient.com/> =09 Carter Bullard=C2=A0=C2=A0 <mailto:[email protected]>=E2=80=A2 CTO 150 E 57th Street, Suite 12D New York, New York 10022-2795 Phone +1.212.588.9133 =E2=80=A2 Mobile +1.917.497.9494 =20 > On Dec 7, 2018, at 1:45 PM, Balas, Edward G <[email protected]> wrote: >=20 >=20 >=20 >> On Dec 7, 2018, at 1:21 PM, [email protected] wrote: >>=20 >> Hey Edward, >> Its always important to indicate which version your running, so we = can deal with known bugs etc =E2=80=A6 >=20 > Sorry about that=E2=80=A6 I hadn't gotten to point of thinking there = was a bug =E2=80=A6 > 3.0.8.2 is what I running now >=20 >>=20 >> Argus tracks loss in 3 basic conditions, connection oriented = protocols such as TCP, connection-less protocols that have sequence = numbers, such as RTP, UDT, and IPSEC, and strict request / response = protocols where you should see the same out as back. >>=20 >> Argus has a complete TCP state machine so that it can identify = requests for missing packets, retransmissions and out of order packets. = But argus is designed to recognize loss regardless of where it is along = the path. As a result, the algorithm is a little complex, mainly = because TCP is reliable and regardless of the loss rate you should = always see at least one copy of all the packets. Because argus is a = bi-directional flow monitor, argus can do things like look for requests = for retransmission as an indication of loss. It can infer that = observing multiple packets is an indication of loss (you don=E2=80=99t = retransmit unless there was loss), and it can needs to do this in the = event of stripping and asymmetric routing. >=20 > yeah we are defn interesting in the asymmetic situation, for now we = are validating using point of observation where traffic appears = symmetric. >=20 >>=20 >> Because loss can occur before and or after argus see=E2=80=99s the = packet stream, argus will use retransmissions and retransmission = requests from the far side as an indication of loss. If the far side = requests more than once, we assume that the packet was lost more than = once, or that the retransmission request was lost. This is a possible = source for argus saying there is more loss than other tools. >=20 > Ah ok that is in part what I was curious about, so if one were to look = at the individual packets in a flow and count the number of times any = sequence number shows up more than once, they should presumably come up = with the same value as argus loss calc? >=20 >=20 >> Now with that as a starting point, where is argus in relationship = with the the other tools, and what methods are they using to determine = loss ??? >=20 > Yeah this is a classic dilemma have having too many watches and not = knowing which is correct. What we have for a reference is ultimately = what iperf3 is reporting, and we are starting to look at what the kernel = can tell us as presumably the tcp implementation should have a pretty = authoritiative view of its own behavior, but I havent dug into proc = filesystem etc enough to know whats available. Im not really sure yet = what tsharks methodology is for determining retransmission, I have been = presuming it is similar to what you described, Ill take a look at = sequence numbers directly to see whats up and report back. >=20 >>=20 >> Carter >> =09 >> Carter Bullard =E2=80=A2 CTO >> 150 E 57th Street, Suite 12D >> New York, New York 10022-2795 >> Phone +1.212.588.9133 =E2=80=A2 Mobile +1.917.497.9494 >>=20 >>=20 >>=20 >>> On Dec 7, 2018, at 12:28 PM, Balas, Edward G <[email protected]> wrote: >>>=20 >>> Hey all, >>>=20 >>> Ive run into an issue Im struggling to understand, and thus far = googling has failed to right me. I am trying to use Argus to track = retransmissions / loss in flows and I am getting values that are = inconsistent with other tools including the sending application. As I = recurse into the various rabbit holes contributing to this on our end, I = was wondering if someone could guide me on the following: >>>=20 >>> 1. within ra etc there is the ability to report loss and retrans. = When I look at the documentation loss seems to imply it contains both = retransmissions and dropped packets, if Im looking at a TCP flow, is it = correct to assume there will be no drops and thus loss is synonymous = with retransmission? >>>=20 >>> 2. I am able to get ra and racluster to report loss values for my = flows, however retrans is always 0, is there a special -M or other = options or argus option I need to use to see retrans? Im making the = possibly bad assumption that because I can see loss values the tunings = of argus are sufficient. >>>=20 >>> 3. The Loss numbers are always higher than what I am seeing with = other applications, is there a document or place in the code I should go = look at that describes how this is calculated? >>>=20 >>> Motivating these questions is the following small test: >>> ------------------------------------------------------- >>> I transfered a file to my test host while doing full snaplen packet = capture, and then compared argus with tshark reports of loss and = retransmission.=20 >>>=20 >>> accuracy-test2]# argus -JA -r raw.pcap -w raw.argus >>>=20 >>> accuracy-test2]# racluster -n -r raw.argus -s = stime,dur,pkts,retrans,loss,appbytes,cause -- port 51170 >>> StartTime Dur TotPkts Retrans Loss TotAppByte = Cause=20 >>> 16:47:58.176366 15.206044 21513 0 24 20195392 = Start >>>=20 >>>=20 >>>=20 >>>=20 >>>>> Total packets between tshark and argus agree: >>>=20 >>> accuracy-test2]# tshark -r raw.pcap -nn -Y 'tcp.port=3D=3D51170 ' = | wc -l=20 >>> 21513 >>>=20 >>>>> Retransmissions / loss do not agree between tshark and argus: >>>=20 >>> accuracy-test2]# tshark -r raw.pcap -nn -Y 'tcp.port=3D=3D51170 and = tcp.analysis.retransmission ' | wc -l=20 >>> 17 >>>=20 >>> 17 vs 24 >>>=20 >>>=20 >>> Was curious if folks had insights they could share in these regards? >>>=20 >>> Thanks, >>>=20 >>> Edward Balas >>> [email protected] >>=20 >=20 >=20 --Apple-Mail=_0C81E5EA-DDB2-49E5-A77A-9F0F0C6C26E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div = dir=3D"auto" style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;" class=3D""><div dir=3D"auto" = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break: = after-white-space;" class=3D"">Hey Edward,</div><div dir=3D"auto" = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break: = after-white-space;" class=3D"">So better to look at retransmission = requests. If you have a packet stream captured at the originator = of the TCP, there are a number of scenarios where you won=E2=80=99t see = any indication of loss, just packets out of order. If the loss = occurs on the return path from the dest to the src, then you will not = see any retransmissions / duplicates, you will only see the packets that = successfully show up. The indicator of loss is the selective = retransmissions that the src sends to the far side.</div><div dir=3D"auto"= style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break: = after-white-space;" class=3D""><br class=3D""></div><div dir=3D"auto" = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break: = after-white-space;" class=3D"">We can tell you which side the loss = occurs on, so don=E2=80=99t print out loss, print sloss and dloss. sloss = is on the src -> dest path, and dloss Is on the dest -> src = path.</div><div dir=3D"auto" style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div = class=3D""><br class=3D""><div class=3D""><div class=3D"">Carter<br = class=3D""><div class=3D""> <div dir=3D"auto" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0); letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: = break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" = class=3D""><table id=3D"sig" width=3D"360" cellspacing=3D"0" = cellpadding=3D"0" border-spacing=3D"0" style=3D"width: 360px; margin: = 0px; padding: 0px;" class=3D""><tbody class=3D""><tr class=3D""><td = width=3D"142" style=3D"width: 142px; margin: 0px; padding: 0px;" = class=3D""><a href=3D"http://qosient.com/" title=3D"QoSient" = style=3D"border: none; text-decoration: none;" class=3D""><img = src=3D"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAR8AAABdCAYAAACcsGKeA= AAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAACy9JREFUeNrsndt140YShmt= 85n2RgbERCI5gMBEMNgLBEZiOQHAEtCOgHIFGEZCKgNoIyI2AzMArnGkcy5jqC9DVF4D/dw4eR= ElEo6vr7+oLqokAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMBN8CGTctSaz1/= frivMlJTi7apGn53VBcBixKdW193bVTKNWsfQ2F/eroO6QDixad+uT8pWheFvX9U12OUs2Ebe2= /4RZgFzaN6u3dt1ebv+EryelJMUqGIRSmUnH5scBWzSjb5zD9OAqb1n34hOwoLDXRflNCWqXcz= hJWyynWkTiA/wasiXCKLDXTtEQpM7iWPgjqGB+IAY8zmukc5e9Yyt+r/S8J2NapBPjqLW/80G5= rBSWex1Ujbi7FMpu2wdxKuD+ICQbCPO0dSOc0h7REHGiOdiEJ12xnyRbpgN8QHJwvZQ8zHDqsz= JEgVVMNN3HA228mVsE4gPiB627ynOJHBB9gnTFubSOneoOhpEaKr41Op/hgu2y48yZadeGcL2S= 6IGU1qiMDTib3XE1c02YMeAyHN9beiSKiI1Cc+R0i957yBAk+rmCH8CM6ZZ9ilufqH8J3hbgwA= 1N9x4ONvV8Ckwo/OKLj4hJypjCdCtTkLXxK9sAeA64km2ELA1RDy50hqGh7e2DN9RvLkesP7Oa= 5/qxkty4o7iTrLmyhNhDgwsUHxOmuFLuWDH++vGhl97wnwPyEh8fnCMHDiR+ZmWk9OlL+tVM5Q= EACTAJj79kOoX5vOv6loKvfD8qlHzW+798foJyFZ8NpoG+usCn/WR+CRkDzdiay5KxQZAkC3cX= M9uwc9T0+3O/XSEDYZAzne853w+Gn7Xb8Yrmc9/W3AF9pHPKyM29+rzGFRMNBkjV/WBifIq1ag= ON+5Y3GsgueYPrxdSTiumHM59hNOOPuvnef6z8IbWMtFbPyT5d6D79SL+RTXuykEgXlQ9hxDDC= yN8/T0/Z+Zc9cg2j8L3KEd20c19XVX9PCubSDl5Z/l53EHcqzqpLOV8UXV1negPpcPf/TjSg94= uf07o+CZ1cNyQaw2vJhQRhl4l+eetPpL8PpyOZBJ+xRwe7gPYxSddr8Qk/fi7daKzn1nObkI59= xQ+w+ik9lVpvmQtcBW+ERK2TthwJ5JbkTO9m9etXHyk7CKRKdPmV51Qu6lyFp+PBvHhQqe18MI= 4dH9UzO+eczk7B4NfmSFVbemt96psvquM/b37PU9PzO8eVB0saf+Wq+A+OQj4wdEm/ff1+8Pul= D2k51t2lojXtZylip5/tgxbXyfUY2Vpxzomtacu89BcYl5BcuWnIXN+o536m8IiXhsy5ySSyhy= wFQzbc458TJk2hxzVlUX4N6RPmjf39SJd5LPTlLOzlLNSz6Jrg3UAnwn2esWe1p2KohAcVrYBn= Lg2hMNS79PZ5j5SiZCU+OiE5zKzI201zn0UEp8d+SflKzR2vZBM7vRk4lPTuuAcrvA0iHQK2Y1= gg5/iUNzermZh4vOkqTefhYVSI2hbz7bXCEe4G5LfnxdNfCQcM3eOngJbahxXehOmLnOk1HtpJ= bmvAA1DgDJz8dkEjBh1k/a1h39dArQfTnzLpYrP2vCN7vYUb/d3ReGzEE4RoeFZ6wzFhxMH6Qw= MNfklZjPVqeTUwkXw+yE+mYgPN8/zFLi8vg1+igh15L5HSXo/kq/47CjOfCV3n9bDv0I485YRY= YjPwsXnxIhAjGFpR3ETgrXkvg/kJFQWH/EpKF6mzdKjAwoxIexaxgris1zxaSntSuCJ4udhLlU= v6nIctu9ku4/4bCjuQgk3r1LM8K8mYnvZ5C4+F+HJqhw5zXzGPaV9Mzy1+LlEQz5J+n3E5xhZm= OfaImbHPhbILhfx0eXzedX0fmuCe56zw/+Me9I/Ipf7kSnnl8j3/6yug2H4s6e4qUq4N9NDJ7z= jvv9TZu38v7mWTyc+15WLzxzhIU0InyKj41eHcoXmoARIl6K2oHhHZpNG6F4C3/PKtJvcckOdc= 3XCHxzVsuduReJTzTTSHeOAKXKpPDNimmofVh8J/aSJlocdtzGoHedkpK+SeWaIj/Cwq16R+Hy= a2UtWkXtWU9ThIqgxG/hnQ7tpI5ThXxl3bGCC+Oga91p2OTeOz2wbrqXMIHfNbFh8VQLE1ckDn= B6M+WhoSFy60Ybks8ql6Jk4EZkjPq8Jn+N1FI2WGdTtcErIjqm3KnJ99e30T7j48sSHlOG4XMd= LF5975rOvaAqiTv/AiGETWXz+R8hNvchhl84h64WHt4Vm/uEZTUGUJSxBg4zF56zpOX5Z8PNy5= 5CdEfmI8+wwZAUQHyPcMTktLXPlS3f66pRNgufRzymjwMpStpSk2KQ6Xnn8Ee69bPE5aKKfJZ5= xzp080E+QPnqIT6oGXmgiuFzI4RwpRFoLFx9d9NP3ut2CnrMhfnn9t4mOMiXxe0hqx2jjljhkY= hsgKD69Ubk5kQdaxuTzcKoE56xTT6t4Yb47RQ/7hXmWnE6tTLEf7FXT6YAFi0+P7v2dPeW98bA= g/UFvc46hOWTSwBuHcqUWfIpcRm6v1j1cfPniM5z3xDl3rgJkerP695nOcGWiwNirfy1T37ltp= uOGPOcI931mRLqEm68DXY5fqeTcksJzNJTV17FSnWnWP9eJ0uYTcoHLldQ6/m9HfpkMLxQp6ZU= HMfP51EL1UedQryanzqGXKQ1llEokvie55FlT2JJfGtUYZWzJL01oR/I5nDcQn3WIT2Fx7jpxu= G86ObQKZNAY0R/n1FMbwCWwIxaaqGdKWg1f8dEdbRNDeCvH+6xBfE6pnNwkQCmOVi7IfgSwdOP= bRhSgRuiZpA81tEWEc6LNjsKc2xU6Ot1M6HzXID5J87rbBOgUKQpqyZzYPFSj0z2/tAC1mudqZ= 3wX10lIHaS3E+qIOiFn0Qmh9OpkObrXLYlPmVqAbNni9hRmOdomOhLH47o0vEug4acpmpubHTD= EmeymObY5DV1KfEyd41ZAdAvizzdbq/gUFPfYptkNRhcJbT2dslGO53KgnUQDcx3nXwzOV88wc= mv4Tp+0pLYTJ7YTxLq0DHXnRoBS4mPqHN6fM1bMsPfW8L1rFR8ifqW1cLRDRwHnGyvLMIxzzK0= qVKMq6f3VqN/tyP3guqFC6sjia3v2QXgbjXPXyhFswrqNZKOTKks3skmrPjs62GCu8EuKjy0yG= 0R3R/oXpoe26HJumatzLVV8OtKfWFsy992MRkZdaEd0GQ6FuKROzAw5BJ17Sc9VtOR+HPLUa+c= ZcUqLT2jbDGWcMrxfqvjY5nltVxfLGVvPgrpeT5TXOzy1sPj6OrOpIW0Ey3oSskMI8Xk/bJe0z= XHmMy9VfGzTDNmIz3iMfBIWnA3lvXW+nThc5IYCsZ6v8YgMTsQnactRfCQ6xsE2PkP7JYvPnEj= yRMyixofIDlnS3xuxPhF/yuSY/m3lM307S+xAy8vLWyjnvnv37AXzjP17Yy8ZPGNjsc97e3wl+= VQe5Uh0rxQuXUj5zjalRlAOqgyS7a9m7hGy/VWB6rP/3nv6Pr3yWV0vgdqIKNtIcx0AAMD2uKY= l6xJVBAAIOSwzjcVj7d0BANwoHZkn/DqIEAAgZBRkWy3qVx18Xp9oIGIAAJNA2Jbph6W8Ka8GD= C9CdqhiAOLzYUFlbYk/hnfMsJT4Qt8vKw5LyMMKWv+7z5RX8nUAQMYiJLFzekp2PQAA+EcU4/q= Ge+zEUgCAG2FIteH6CkeLKgMAhIiINkqMuOFZhyoCID0fbuQ5a/o2v1PS9FNKAQAAAAAAAAAAA= AAAAAAAAAAAAAAASM3/BRgAaVGndQa4eeAAAAAASUVORK5CYII=3D" alt=3D"QoSient" = style=3D"border: none; height: 48px; font-family: "Gill Sans", = sans-serif; font-weight: 100; font-size: 48px; line-height: 48px; color: = rgb(0, 0, 0);" class=3D""><span = class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span></a><span = class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span></td><td width=3D"20" = style=3D"width: 16px; min-width: 16px; max-width: 16px; margin: 0px; = padding: 0px;" class=3D""> </td><td style=3D"margin: 0px; padding: = 0px; border-collapse: collapse;" class=3D""><table id=3D"sig2" = cellspacing=3D"0" cellpadding=3D"0" border-spacing=3D"0" class=3D""><tbody= class=3D""><tr class=3D""><td style=3D"font-family: "Gill Sans = Light", sans-serif; white-space: nowrap;" class=3D""><a = href=3D"mailto:[email protected]" style=3D"border: none; = text-decoration: none;" class=3D""><span style=3D"font-size: 16px; = line-height: 16px; color: rgb(0, 0, 176);" class=3D"">Carter = Bullard</span><span class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span></a><span style=3D"font-size:= 12px; line-height: 14px; color: rgb(0, 0, 0);" class=3D"">=E2=80=A2</span= ><span class=3D"Apple-converted-space"> </span><span = class=3D"Apple-converted-space"> </span><span style=3D"font-size: = 12px; line-height: 14px; color: rgb(0, 0, 0);" = class=3D"">CTO</span></td></tr><tr class=3D""><td style=3D"font-family: = "Gill Sans Light", sans-serif; white-space: nowrap;" = class=3D""><span style=3D"font-size: 12px; line-height: 14px; color: = rgb(0, 0, 0);" class=3D"">150 E 57th Street, Suite = 12D</span></td></tr><tr class=3D""><td style=3D"font-family: "Gill = Sans Light", sans-serif; white-space: nowrap;" class=3D""><span = style=3D"font-size: 12px; line-height: 14px; color: rgb(0, 0, 0);" = class=3D"">New York, New York 10022-2795</span></td></tr><tr = class=3D""><td style=3D"font-family: "Gill Sans Light", = sans-serif; white-space: nowrap;" class=3D""><span style=3D"font-size: = 12px; line-height: 12px; color: rgb(0, 0, 0);" class=3D"">Phone = +1.212.588.9133 =E2=80=A2 Mobile = +1.917.497.9494</span></td></tr></tbody></table></td></tr><tr = class=3D""></tr></tbody></table><br class=3D""> </div> </div> <div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On Dec 7, 2018, at 1:45 PM, Balas, Edward G <<a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D""><br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D"">On Dec 7, 2018, at 1:21 PM, <a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a> = wrote:<br class=3D""><br class=3D"">Hey Edward,<br class=3D"">Its always = important to indicate which version your running, so we can deal with = known bugs etc =E2=80=A6<br class=3D""></blockquote><br class=3D"">Sorry = about that=E2=80=A6 I hadn't gotten to point of thinking there was a bug = =E2=80=A6<br class=3D"">3.0.8.2 is what I running now<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""><br class=3D"">Argus = tracks loss in 3 basic conditions, connection oriented protocols such as = TCP, connection-less protocols that have sequence numbers, such as = RTP, UDT, and IPSEC, and strict request / response protocols where you = should see the same out as back.<br class=3D""><br class=3D"">Argus has = a complete TCP state machine so that it can identify requests for = missing packets, retransmissions and out of order packets. But = argus is designed to recognize loss regardless of where it is along the = path. As a result, the algorithm is a little complex, mainly = because TCP is reliable and regardless of the loss rate you should = always see at least one copy of all the packets. Because argus is = a bi-directional flow monitor, argus can do things like look for = requests for retransmission as an indication of loss. It can infer = that observing multiple packets is an indication of loss (you don=E2=80=99= t retransmit unless there was loss), and it can needs to do this in the = event of stripping and asymmetric routing.<br class=3D""></blockquote><br = class=3D"">yeah we are defn interesting in the asymmetic situation, for = now we are validating using point of observation where traffic = appears symmetric.<br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D""><br class=3D"">Because loss can occur before and or after = argus see=E2=80=99s the packet stream, argus will use retransmissions = and retransmission requests from the far side as an indication of loss. = If the far side requests more than once, we assume that the packet = was lost more than once, or that the retransmission request was lost. = This is a possible source for argus saying there is more loss than = other tools.<br class=3D""></blockquote><br class=3D"">Ah ok that is in = part what I was curious about, so if one were to look at the individual = packets in a flow and count the number of times any sequence number = shows up more than once, they should presumably come up with the same = value as argus loss calc?<br class=3D""><br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">Now with that as a = starting point, where is argus in relationship with the the other tools, = and what methods are they using to determine loss ???<br = class=3D""></blockquote><br class=3D"">Yeah this is a classic dilemma = have having too many watches and not knowing which is correct. = What we have for a reference is ultimately what iperf3 is = reporting, and we are starting to look at what the kernel can tell us as = presumably the tcp implementation should have a pretty authoritiative = view of its own behavior, but I havent dug into proc filesystem etc = enough to know whats available. Im not really sure yet what = tsharks methodology is for determining retransmission, I have been = presuming it is similar to what you described, Ill take a look at = sequence numbers directly to see whats up and report back.<br = class=3D""><br class=3D""><blockquote type=3D"cite" class=3D""><br = class=3D"">Carter<br class=3D""> = <span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span> <span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><br = class=3D"">Carter Bullard =E2=80=A2 CTO<br class=3D"">150 E = 57th Street, Suite 12D<br class=3D"">New York, New York 10022-2795<br = class=3D"">Phone +1.212.588.9133 =E2=80=A2 Mobile +1.917.497.9494<br = class=3D""><br class=3D""><br class=3D""><br class=3D""><blockquote = type=3D"cite" class=3D"">On Dec 7, 2018, at 12:28 PM, Balas, Edward G = <<a href=3D"mailto:[email protected]" class=3D"">[email protected]</a>> = wrote:<br class=3D""><br class=3D"">Hey all,<br class=3D""><br = class=3D"">Ive run into an issue Im struggling to understand, and thus = far googling has failed to right me. I am trying to use Argus to = track retransmissions / loss in flows and I am getting values that are = inconsistent with other tools including the sending application. = As I recurse into the various rabbit holes contributing to this on = our end, I was wondering if someone could guide me on the following:<br = class=3D""><br class=3D"">1. within ra etc there is the ability to = report loss and retrans. When I look at the documentation loss = seems to imply it contains both retransmissions and dropped packets, if = Im looking at a TCP flow, is it correct to assume there will be no drops = and thus loss is synonymous with retransmission?<br class=3D""><br = class=3D"">2. I am able to get ra and racluster to report loss = values for my flows, however retrans is always 0, is there a special -M = or other options or argus option I need to use to see retrans? Im = making the possibly bad assumption that because I can see loss values = the tunings of argus are sufficient.<br class=3D""><br class=3D"">3. = The Loss numbers are always higher than what I am seeing with = other applications, is there a document or place in the code I should go = look at that describes how this is calculated?<br class=3D""><br = class=3D"">Motivating these questions is the following small test:<br = class=3D"">-------------------------------------------------------<br = class=3D"">I transfered a file to my test host while doing full snaplen = packet capture, and then compared argus with tshark reports of loss and = retransmission. <br class=3D""><br class=3D"">accuracy-test2]# = argus -JA -r raw.pcap -w raw.argus<br class=3D""><br = class=3D"">accuracy-test2]# racluster -n -r raw.argus -s = stime,dur,pkts,retrans,loss,appbytes,cause -- port 51170<br class=3D""> = StartTime = Dur TotPkts Retrans = Loss TotAppByte Cause = <br class=3D""> 16:47:58.176366 15.206044 = 21513 0 = 24 20195392 = Start<br class=3D""><br class=3D""><br class=3D""><br = class=3D""><br class=3D""><blockquote type=3D"cite" class=3D""><blockquote= type=3D"cite" class=3D"">Total packets between tshark and argus = agree:<br class=3D""></blockquote></blockquote><br = class=3D"">accuracy-test2]# tshark -r raw.pcap -nn -Y = 'tcp.port=3D=3D51170 ' | wc -l <br class=3D"">21513<br = class=3D""><br class=3D""><blockquote type=3D"cite" class=3D""><blockquote= type=3D"cite" class=3D"">Retransmissions / loss do not agree between = tshark and argus:<br class=3D""></blockquote></blockquote><br = class=3D"">accuracy-test2]# tshark -r raw.pcap -nn -Y = 'tcp.port=3D=3D51170 and tcp.analysis.retransmission ' | wc -l <br = class=3D"">17<br class=3D""><br class=3D"">17 vs 24<br class=3D""><br = class=3D""><br class=3D"">Was curious if folks had insights they could = share in these regards?<br class=3D""><br class=3D"">Thanks,<br = class=3D""><br class=3D"">Edward Balas<br class=3D""><a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a><br = class=3D""></blockquote><br class=3D""></blockquote><br class=3D""><br = class=3D""></div></div></blockquote></div><br = class=3D""></div></div></div></div></div></body></html>= --Apple-Mail=_0C81E5EA-DDB2-49E5-A77A-9F0F0C6C26E8--