Re: [Bloat] the observed sack oddity

[Justin McCann <jneilm@gmail.com>]

On Tue, Oct 11, 2011 at 9:09 AM, David Täht <dave.taht@gmail.com> wrote:
> I have put up screenshots of tcptrace -G and xplot.org's analysis of my
> most recent capture of an ipv6 connection over freebox (wired) from a
> debloat-testing kernel here in france (pre 3.1 by a lot) to a 2.6.16
> kernel (the aformentioned netsonar box) in redwood city, ca, both
> running tcp cubic, over ipv6.
>
> at first glance, it looked a lot like a classic bufferbloat trace, with
> complete with periodic collapses and cubic increasing the window.

A side question on the outstanding data graph:
  http://www.teklibre.com/~d/sackoddity/freeboxoutstandingdata.png
compared with the sequence number graph:
  http://www.teklibre.com/~d/sackoddity/freeboxipv6seq.png

Looking at
  http://www.tcptrace.org/manual/node15_tf.html
the red line is supposed to approximate the sender's congestion window.

If you line up the segment timeline and the outstanding data timeline,
it seems like the (red) instantaneous outstanding data line doesn't
take SACKed segments into account, and just uses the normal
acknowledgment number. So, once the early missing segment gets
acknowledged, you see a sharp dropoff in the red line---that last ACK
covers all of the already-received and SACKed segments as well.

I guess the red line includes packets in the network, plus held up in
the receiver's buffer. Would it be useful to have a line that
estimates what is currently in the network that doesn't include the
SACKed packets (i.e. the ones in the receive buffer that can't make it
to the application)?

     Justin