From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gx0-f171.google.com (mail-gx0-f171.google.com [209.85.161.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7195A200624 for ; Tue, 11 Oct 2011 08:25:59 -0700 (PDT) Received: by ggnk4 with SMTP id k4so8324369ggn.16 for ; Tue, 11 Oct 2011 08:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kVRrmcW5wfXRRQVoJ50tTFKFjY9+aFAlIkKFzEq6XIE=; b=oezOc3WB8xRldmuUTFCZJshX+Aj0DZbC7/GcjypbdlRiozo7usmrnUVQYe8F4MrHO/ 5JvQnaUAzI/jqoGHYZgs+IRxaK7cGBLujKBYuQKk2IhCL8PNlQ+lG1TGyy5YjTT5KRST NUGIpnjaoTGv5Vyc1VRcpjoy7D7F30EzSWZmQ= MIME-Version: 1.0 Received: by 10.150.138.15 with SMTP id l15mr10779589ybd.21.1318346758302; Tue, 11 Oct 2011 08:25:58 -0700 (PDT) Received: by 10.151.12.15 with HTTP; Tue, 11 Oct 2011 08:25:58 -0700 (PDT) In-Reply-To: <4E943FF7.5020208@gmail.com> References: <4E941A05.2050705@gmail.com> <20111011115816.GA24956@uio.no> <1318335234.2538.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <1318335509.2538.11.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <4E943FF7.5020208@gmail.com> Date: Tue, 11 Oct 2011 11:25:58 -0400 Message-ID: From: Justin McCann To: =?ISO-8859-1?Q?David_T=E4ht?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] the observed sack oddity X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:25:59 -0000 On Tue, Oct 11, 2011 at 9:09 AM, David T=E4ht 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 =3D=3D 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