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.
>
> 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