Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 6683] TCP bytes in flight should take SACK's into account

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6683

Paul Munford <munford@xxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |munford@xxxxxxxxxx

--- Comment #1 from Paul Munford <munford@xxxxxxxxxx> 2012-09-14 12:39:00 PDT ---
Copy/additional viewpoint from bug 7703:

Perhaps the real answer is to have two tcp.analysis fields (choose what names
you want, just making a point):

1) tcp.analysis.highest_expected_sequence = tcp.nxtseq - [most recent] tcp.ack
2) tcp.analysis.bytes_in_flight = 
   [from most recent data packet]  tcp.nxtseq - 
           [from most recent ack]  tcp.ack -
                                   tcp.options.sack_re1 - tcp.options.sack_le1
                                   tcp.options.sack_re2 - tcp.options.sack_le2
                                   tcp.options.sack_re3 - tcp.options.sack_le3
                                   tcp.options.sack_re4 - tcp.options.sack_le4
   where sack_re1, sack_re2, sack_re3, sack_re4 indicate the right edge of each
of the four allowed ranges in the SACK field of the Options section of the TCP
header.

In this manner, the "true" bytes in flight will only ever require knowledge of
the most recent data packet from the sender and the most recent prior ACK from
the recipient.  Similarly, the packet analyzer will be able immediately
understand "bytes in flight" as well as "when the Sender should stop
transmitting as per RFC793", making analysis easier.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.