On Tue, Oct 11, 2011 at 9:09 AM, David Täht <[email protected]> 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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
