Another vote for packet drop detection

[Carter Bullard]

Gentle people,
As I test the algorithms for gap detection, a few things are coming up, causing
me to simplify the strategy a bit.

There are two situations for TCP, and any other connection oriented transport
protocol.  When we are seeing both sides of the conversation, and when we
are not.  When we are seeing both sides, we can correlate received ACK's with
transmitted sequence numbers, and tick a status bit saying we've observed gaps
if there are discrepancies.   This will be very sensitive, but the condition itself
is not enough to know how much data was missed.

When we are seeing only one side, we can report gaps in the sequence numbers,
just by knowing the sequence number range, and comparing that against the
observed bytes.  As long as we account for sequence numbers out of order
this works very well.  However, when there are retransmissions, this method
breaks down.  Our observed bytes within a sequence number range can't
really be compared to give a realistic value, unless we are tracking retransmitted
bytes.  Currently argus does not track this metric, it tracks numbers of retransmitted
packets.  I'll change this for argus-3.1.0.

As a result, we will use the uni-directional algorithm to report gaps as unobserved
bytes, when there is no evidence of retransmissions.  I'm going to put a ' g ' in the
status flags field in the same column (#4) as the loss indicators,  when there are gaps.
I won't worry about the indication from argus, until argus-3.1.0 when we can change
the "retrans" metrics and their reporting.

Fields are called 'sgap' and 'dgap', and the Column labels are "SrcGap" and "DstGap".
There is support for printing, including xml, graphing, etc…. but there is no support
yet for filtering or sorting yet.  That is important, so I'll put that in before
I release the code.  Should be today or tomorrow.

The other protocol that we should implement this for is RTP.  Because RTCP, the
reverse control channel for RTP, contains loss values, we can compare the two
to realize that we are not seeing all the RTP traffic, but RTCP is not reporting loss.
This would be our indication of gaps in the RTP stream.  I'll work on that much later.

Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120201/c057c591/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120201/c057c591/attachment.bin>