From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.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 BBB8A20067D for ; Tue, 11 Oct 2011 08:37:46 -0700 (PDT) Received: by gyh3 with SMTP id 3so9586945gyh.16 for ; Tue, 11 Oct 2011 08:37:45 -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=I6DLiRduW7DS+1nEcrU6BL0zfWl0cTvOWEhKfrhkcPc=; b=eAiuldXTDDjUHHdyBkk+cR6f9YE7coQA4mC/0ltucVVUK4oGQhAbtN/yqNBNWkQFAs nNkJ55wZJ6xRTlx0oSZhvBS2diiwBk3mytcNtY1ATHQ63hmZyvhKF59mi05elw+XNIQp LsAxYWeru4az38J4ifKZDtpl1EXF/qwQr736U= MIME-Version: 1.0 Received: by 10.150.138.15 with SMTP id l15mr10825862ybd.21.1318347465459; Tue, 11 Oct 2011 08:37:45 -0700 (PDT) Received: by 10.151.12.15 with HTTP; Tue, 11 Oct 2011 08:37:45 -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:37:45 -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:37:47 -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. 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