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. > > Then I noticed the sacks.
It took me a bit to figure out what was odd about the SACKs. I see: - At the beginning, the sender is ramping up faster than the rate the ACKs are coming in (white vs. green). I'd expect them both to have near the same slope (and change in slope) if slow start wasn't going overboard. Is this difference in slope pretty common in bufferbloat traces? - Sender marks the first CWR shortly after the first SACKs come in. That looks like some sort of AQM kicked in and dropped packets at the head (or middle) instead of drop-tail, so you get the SACKs. Since the RTT is so large (France <-> CA), the retransmissions take a while to get to the receiver (and the ACKs returned), so the green line stays flat. But since packets are getting through (as seen by the SACKs), the window keeps advancing. Now I see the problem: Why doesn't the receiver cover the whole missing range in each SACK, while the green line isn't advancing (green == next seqno)? It does in the right hand side of http://www.teklibre.com/~d/sackoddity/freeboxipv6zoomtosackwindow.png but not at the beginning. If it was a dropped ACK, any one of the later SACKs would have advanced the acknowledged window, but they didn't--- the receiver isn't properly tracking the entire SACK window(s). Does that catch it? Justin _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
