Re: [tcpPrague] [aqm] L4S status update

"Bless, Roland (TM)" <roland.bless@kit.edu> Tue, 22 November 2016 16:45 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384CE1297A7; Tue, 22 Nov 2016 08:45:44 -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=ham 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 Oo6pQmvr9HVs; Tue, 22 Nov 2016 08:45:42 -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 298321296CA; Tue, 22 Nov 2016 08:45:42 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1c9ECR-0004rn-Ei; Tue, 22 Nov 2016 17:45:39 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 2D3FBB00254; Tue, 22 Nov 2016 17:45:58 +0100 (CET)
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, TCP Prague List <tcpPrague@ietf.org>, AQM IETF list <aqm@ietf.org>, tcpm IETF list <tcpm@ietf.org>
References: <be67928d-e1f7-2495-147d-1d42d6783cc8@bobbriscoe.net> <f6b89407-14d8-b532-b793-7490cb5a2117@kit.edu> <DB4PR07MB34816BE4EBF717E026A67ABC2B40@DB4PR07MB348.eurprd07.prod.outlook.com>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <70104ef0-3747-9b47-dcb7-be54fe454443@kit.edu>
Date: Tue, 22 Nov 2016 17:45:57 +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: <DB4PR07MB34816BE4EBF717E026A67ABC2B40@DB4PR07MB348.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1479833139.
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/jTIH0GeOsBOjOiI0s6XNlkAS9VI>
Subject: Re: [tcpPrague] [aqm] L4S status update
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Nov 2016 16:45:44 -0000

Hi Ingemar,

my point was that it's probably better to refrain from
building CC-specific behavior into network elements as the
CC algorithms may evolve faster and in more flexible ways
than we can foresee. Thus, it would be good to have a separation
(or coupling) scheme that actually doesn't depend on the
1/sqrt(p) dropping law.

Am 22.11.2016 um 15:35 schrieb Ingemar Johansson S:
> As regards to comments around other new congestion control algorithms
> and that they may need adapted dropping likelihood relation between a
> classic queue and L4S queue. I have not tried out but I suspect that
> BBR may get an unfair treatment, at the same time it is possible that
> other delay based CCs may suffer.

It would be interesting to see what happens if BBR is sorted into
the L4S queue in comparison to what happens if BBR is sorted into
the classic queue (BBR isn't reacting to loss according to 1/sqrt(p)).

> They question however if this is a major problem?, one may as well
> see this as an incentive to switch over to scalable congestion
> controls and L4S ? There is after all no requirement to stick to a
> particular congestion control no matter what. ?

Yes, and that's why I find that built-in coupling law too limiting.

> The question whether or not endpoint dependency should be built into
> the networks is of course  a valid question but given that the state
> of the art congestion controls like Reno and Cubic rely on a
> 1/sqrt(p) function then that is perhaps OK ?. There will for a
> foreseeable time come updated endpoint based congestion control
> algorithms that are optimized  for one thing or the other (I am
> guilty too :-). However if one can distinguish between two classes
> (classic and L4S) where classic belong to the 1/sqrt(p) family then I
> believe that it is possible to solve the problem. If we try find a
> solution where classic = "all sorts of non-scalable non-L4S dependent
> congestion controls" then I believe that we easily end up in big
> problems.

I'm not sure. Maybe we have a class of "queue-filling" CCs and
a class of low-delay targeted CCs.

Regards,
 Roland