Re: [aqm] [tcpPrague] L4S status update

Mario Hock <mario.hock@kit.edu> Thu, 24 November 2016 17:06 UTC

Return-Path: <mario.hock@kit.edu>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BC3129489; Thu, 24 Nov 2016 09:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ve_rbaBVwfZ; Thu, 24 Nov 2016 09:06:10 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2F81295F2; Thu, 24 Nov 2016 08:57:17 -0800 (PST)
Received: from i72t450mh.tm.uni-karlsruhe.de ([141.3.71.47]) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 587 iface 141.3.10.81 id 1c9xKl-0000bW-Tj; Thu, 24 Nov 2016 17:57:15 +0100
To: Bob Briscoe <ietf@bobbriscoe.net>, "Bless, Roland (TM)" <roland.bless@kit.edu>
References: <be67928d-e1f7-2495-147d-1d42d6783cc8@bobbriscoe.net> <f6b89407-14d8-b532-b793-7490cb5a2117@kit.edu> <f16c9830-f97a-64e0-76e6-66f146576616@bobbriscoe.net>
From: Mario Hock <mario.hock@kit.edu>
Message-ID: <67730f0d-7ee4-1366-1aaf-847b73e6b146@kit.edu>
Date: Thu, 24 Nov 2016 17:57:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <f16c9830-f97a-64e0-76e6-66f146576616@bobbriscoe.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1480006635.
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/U_Yrj7u66lJuL0vji83vOHXXmMw>
Cc: TCP Prague List <tcpPrague@ietf.org>, tcpm IETF list <tcpm@ietf.org>, AQM IETF list <aqm@ietf.org>, tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: [aqm] [tcpPrague] L4S status update
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2016 17:06:11 -0000

Hello Bob and Roland,

I followed your discussion and want to share my opinion, here. (Comments 
inline).

Am 22.11.2016 um 20:09 schrieb Bob Briscoe:
> *Is any AQM CC-neutral?**
> *Note rule 5 <https://tools.ietf.org/html/rfc7567#section-4.5> in the
> AQM Guidelines [RFC7567]
>       "AQM algorithms SHOULD NOT interpret specific transport protocol
> behaviors."
> In general, the advice in that section is sound, but I don't think we
> realized at that time just how subtle this issue is.
>
> Since then, I discovered that the autotuning parameter table in the PIE
> algorithm is designed very precisely around the 1/sqrt(p) rule of Reno
> (see Fig 5 in the PI^2 paper <http://www.bobbriscoe.net/pubs.html#PI2>).
> Similarly, the sqrt control law in Codel claims to be dependent on Reno
> {Note 1}.
>
> The point is that these AQMs still work fine with Cubic, Compound,
> Westwood, etc, because all these ccs were designed to interwork with
> Reno. {Note 2}

The reason that the AQMs also work with these CCs is because the CCs 
still have a lot in common with TCP Reno, like that they use a 
congestion window, that they increase the CWnd up until packet loss etc. 
Also the 1/sqrt(p)-law is still, more or less, applicable to them.

For newer CCs like BBR or PCC, the 1/sqrt(p) does not apply. They are 
based i.a. on throughput vs. loss/delay probing. BRR, for example, does 
not even use a congestion window (at least not in the same way as the 
other CCs do).


> The idea of L4S (and specifically the DualQ Coupled AQM and the L4S ID
> spec) is to enable a shift to a completely different "norm", but still
> coexist with all the 'Classic' cc's that coexisted around the old
> "norm". The new norm is intended to be just as fuzzy as the old norm
> {Note 3}. The idea is two fuzzy clouds of congestion controls, around an
> old and a new norm that are related together.

I agree with the general idea. But from that reasoning newer CCs, like 
BBR, belong into the "new" queue, where L4S lives in!

If they don't belong in the same queue as L4S, then the queues should 
not be coupled in the way you propose. This coupling prevents any 
innovation in the non-L4S queue.


>
> *BBR**
> *I believe BBR attempts to be 'friendly' to loss-based flows when
> competing in the same queue. But it's still research, and we don't yet
> know how good it is at that in all scenarios, although we do have code
> to test now. Given BBR currently sets Not-ECT, it would classify itself
> into the Classic queue of a DualQ AQM, and if it coexists with Reno it
> /should/ coexist with L4S traffic in the other queue. See Koen's recent
> posting
> <https://www.ietf.org/mail-archive/web/tsvwg/current/msg14771.html>
> about this.
>
> There would be nothing to stop someone designing a variant of BBR that
> coexisted in the L4S queue with Scalable CCs like DCTCP (the point being
> that if the bottleneck was not DualQ it would keep delay low and if if
> the bottleneck was DualQ it would benefit even more from the lower
> queuing delay there). However, it would have to be a bit more careful
> about its whole round trip of queue probing, to avoid increasing the
> delay in the L4S queue. You'll see that I suggested to Neil Cardwell
> that they consider probing with a few packets rather than a whole
> window, e.g. the chirping
> <http://www.bobbriscoe.net/pubs.html#chirp_impl> technique that Mirja
> and I looked into back in 2010 was designed to find the same knee
> between rate increase and delay increase, with far fewer packets. I
> thought of a better way of using chirping a few weeks ago, so I will be
> returning to that too.

I think L4S is not studied well enough, yet to be standardized in a way 
that other low delay approaches must adjust to the L4S concepts.

There is at least BBR, PCC, nv (New Vegas) currently under development 
that all bring in fresh ideas how congestion control could be made in 
the future. Standardizing L4S as "the" new concept without intensively 
study other approaches is just too soon.

If we want to act now, we should focus on a solution that enables new 
approaches in congestion control but is not tailored to either 
Reno/Cubic or L4S/DCTCP. Otherwise more research is required how we want 
the future of congestion control look like.

Best regards,

Mario Hock