From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) (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 7758D200666 for ; Thu, 9 May 2013 16:43:32 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id d41so1881132eek.11 for ; Thu, 09 May 2013 16:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=aLSx9o4qiQVxK/c/x19xieF5CRBRiXd+1DzAj3yL5Yw=; b=oplsspWoNxK75k30BY+NVA7Hh/H0tLEtzCOqaSGjkokaeOm3yIkemFD64NYASJmeuM ULrsDLMdZI9QqOPbs82NUIwpcKzIj/c33+nPqqpsBXxDSyq12nBXF0D+SoD9HijZktAE KO4kJb6l9EZKwPDCk/i2Y4ivLBXzb1BdXD6FDuxuSEB9qRAjr7jiVjzk6iXdqMwzCJer n1byAU2ly3XgvJ4ym4Af+5FhbHUE2BMQlWJMUq9jvHXkchQxhip0y/3IzNKY0gODP4k4 xLG0sSrkF8/TKFBJMIGkBSBsLF+eES7GaUMTkMIntqPNFyq4YX8ZkLCa4m3kPZCpEroY ucbg== X-Received: by 10.15.23.69 with SMTP id g45mr34617925eeu.25.1368143010247; Thu, 09 May 2013 16:43:30 -0700 (PDT) Received: from bass.home.chromatix.fi (xdsl-83-150-84-172.nebulazone.fi. [83.150.84.172]) by mx.google.com with ESMTPSA id e2sm197074eem.16.2013.05.09.16.43.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 16:43:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Fri, 10 May 2013 02:43:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A071B88-52B6-4ADE-B3C6-F63B4E5798A8@gmail.com> References: <20130509213939.GB4170@virgo.local> To: Dave Taht X-Mailer: Apple Mail (2.1085) Cc: bloat Subject: Re: [Bloat] tcp loss probes in linux 3.10 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: Thu, 09 May 2013 23:43:32 -0000 On 10 May, 2013, at 2:01 am, Dave Taht wrote: > I have to admit that the 96% figure strongly suggests some degree of = bufferbloat in the tested mix here. I am curious however as to what = other causes there might be, ranging from tcp bugs to glitches in the = matrix?=20 For the specific case of YouTube servers, the fact that the video stream = is "bottled" so that only a few seconds of buffering-ahead are available = to the client probably plays a role. Sections of the file are released = in bursts, filling any buffers en route. There is a good chance that = the end of a burst is often consumed by a subsequent tail-drop loss = episode. If the time between release bursts exceeds the RTO, then the = RTO will be the only information (by default) reaching the server about = the loss event. The bursty release is worse for TCP than a free-streaming flow, because = the latter would be largely self-timed by the steady return of ACKs, = with the congestion window remaining full most of the time - so only the = bottleneck queue fills up and overflows. When a burst is released, = however, other intermediate queues can also fill up and overflow, = resulting in a larger number of lost packets - and yet a larger = congestion window might result. So it is still bufferbloat, but there can be strange and unintended = interactions with some systems. - Jonathan Morton