From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4AA1020019F for ; Fri, 29 May 2015 05:24:20 -0700 (PDT) Received: by vnbf1 with SMTP id f1so7870371vnb.2 for ; Fri, 29 May 2015 05:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nd3nMjIsMU6X143pncFQ2Ol4xTJ7ciWjUW6cgOW45vk=; b=ZskmPGkKi57JzqDJ0IoAQkI0D6sinmpDnS5SWyEnJ2Rp3eJfI4ZrZHUwTRTGr7cKrR u7xbl+WpQtAFk3ty+CYVRasHVG0RWHvOEObBOemdKdHsMag8oxH4QNyoTXmK0Ee4xn7g 1ooVwts794NDRrm9IIL/phYTbaa/OiodlEbRRpUoqbCel/yTU4WzqiUuVXHeBthNWXfM pUcEmDkRjK/xukfi/aaH7kzYQW4HENA0H5f+qzrS731DpuDI6KTAirvBYBGnghR2NBfZ Nb4chMP3ZieGmu9R0BUElLkgZ5G+WfOK6ZPhVv45lXRw0PJ0eX3rw+JNwRoS9h674lBw Tu7Q== MIME-Version: 1.0 X-Received: by 10.52.89.174 with SMTP id bp14mr6904577vdb.58.1432902254616; Fri, 29 May 2015 05:24:14 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Fri, 29 May 2015 05:24:14 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Fri, 29 May 2015 05:24:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 May 2015 15:24:14 +0300 Message-ID: From: Jonathan Morton To: Dave Taht Content-Type: multipart/alternative; boundary=20cf307abdc9e263a30517378d6a Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] cake byte limits too high by 10x X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 12:25:18 -0000 --20cf307abdc9e263a30517378d6a Content-Type: text/plain; charset=UTF-8 > However there are many other objectives that need to be met also - keeping the pipe filled and utilization high for starters. The ideal buffer length is 1 packet, all the time, no idle periods. trying to smooth out bursts. being resistant to attacks. etc. THIS STUFF IS HARD! It's not hard. It's impossible - as long as we only have this one bit per RTT per flow signalling capacity. Which is why I came up with ELR. Until we get ELR, we'll have to put up with oscillating congestion window sizes, and the inherent trade-off between utilisation and peak queue depth they imply. ConEx and DCTCP don't solve that either; they just allow different amounts of downward pressure at the upper end. Even Codel implicitly acknowledges this oscillation in its design. Someone described it recently as a self-adjusting bang-bang controller, and that's basically fair; it has distinct "on" and "off" phases with some hysteresis between them, just like your refrigerator. It works well for the given conditions, but it too is inherently incapable of providing perfectly smooth control. And then there's the vastly different dynamics of slow start versus congestion avoidance. Codel with ECN and either Westwood+ or CUBIC are actually pretty good in the congestion avoidance phase. Slow start behaves entirely differently, but it's hard to detect the optimal point at which it should be told to back off, without risking being too aggressive at signalling to congestion avoidance. An observation: 50 simultaneous slow start flows with IW10 is equivalent to one slow start flow with IW500. - Jonathan Morton --20cf307abdc9e263a30517378d6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> However there are many other objectives that need to be= met also - keeping the pipe filled and utilization high for starters. The = ideal buffer length is 1 packet, all the time, no idle periods. trying to s= mooth out bursts. being resistant to attacks. etc. THIS STUFF IS HARD!

It's not hard. It's impossible - as long as we only = have this one bit per RTT per flow signalling capacity. Which is why I came= up with ELR.

Until we get ELR, we'll have to put up with oscillating = congestion window sizes, and the inherent trade-off between utilisation and= peak queue depth they imply. ConEx and DCTCP don't solve that either; = they just allow different amounts of downward pressure at the upper end.

Even Codel implicitly acknowledges this oscillation in its d= esign. Someone described it recently as a self-adjusting bang-bang controll= er, and that's basically fair; it has distinct "on" and "= ;off" phases with some hysteresis between them, just like your refrige= rator. It works well for the given conditions, but it too is inherently inc= apable of providing perfectly smooth control.

And then there's the vastly different dynamics of slow s= tart versus congestion avoidance. Codel with ECN and either Westwood+ or CU= BIC are actually pretty good in the congestion avoidance phase. Slow start = behaves entirely differently, but it's hard to detect the optimal point= at which it should be told to back off, without risking being too aggressi= ve at signalling to congestion avoidance.

An observation: 50 simultaneous slow start flows with IW10 i= s equivalent to one slow start flow with IW500.

- Jonathan Morton

--20cf307abdc9e263a30517378d6a--