Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim

Bob Briscoe <ietf@bobbriscoe.net> Mon, 16 March 2020 09:13 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3913A2195 for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 02:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 UarLw7q-yDGW for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 02:13:25 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 27F083A2198 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 02:13:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:Subject:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+rnmS0IOuihPgWiYrg3uYwf1G0Ulrwm6dx5FDSDTOxk=; b=MS5LpEDAxiWLAInL3ncD/rzIA0 DFc2D0MsSiA/2uA45fkYc7CgyuUaaY5S0dWeFPIduhUBnTyOnr8I06Tm2IZXI7XyQR2RnGeDH4tdA aRDWbN11tAXh0oFgG/WfaSJoT07rm2ul86iZqWdPn/3lpFGBjS+GPMMTxIfW2zXbbJfXJl9PcOK/V QGZ+a+/YMgY7E7BQXiASPOxh+T+vnBvypDGLhlFIRGYgizc4o6yKYX0W+TwFhm6BIsZb96MkpAh8m 68Fmgoh0BFd3arQWHyvkL1s7I2Ho3b17R3t3E0eWlYq5Ml6PMmIdsP14sroSnbLh3JLolmFSjxozM RmR8lFLg==;
Received: from host-79-78-166-168.static.as9105.net ([79.78.166.168]:58664 helo=[192.168.2.5]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1jDloJ-006Ghi-01; Mon, 16 Mar 2020 09:13:23 +0000
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Sebastian Moeller <moeller0@gmx.de>, tsvwg IETF list <tsvwg@ietf.org>, Steven Blake <slblake@petri-meat.com>
References: <7409b3a3-ba14-eb6d-154b-97c9d2da707b@bobbriscoe.net> <451679EC-B6F7-4176-B497-8189D238AF03@gmx.de> <0FF50545-9EDC-4C4D-B918-EE3D8A21005E@gmail.com>
Message-ID: <4a358308-cac1-ef73-23c0-b688cbab003c@bobbriscoe.net>
Date: Mon, 16 Mar 2020 09:13:22 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <0FF50545-9EDC-4C4D-B918-EE3D8A21005E@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/02FdztZgwya9C5bB9NzcUdNur48>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2020 09:13:27 -0000

Jonathan, [re-sending with improved quoting, 'cos it's been pointed out 
that the quoting made it impossible to work out who was saying what]

On 08/03/2020 01:35, Jonathan Morton wrote:
>> On 7 Mar, 2020, at 9:16 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>> [SM] I fully understand the challenges of using DSCPs end to end, and 
>> yet DSCPs still seem to be the IETF's endorsed intra-domain and 
>> end-to-end marking mechanism (see RFC 2474). Any other marking 
>> use-case (like the LE PHB) could lay claim on ECT(1) by the same 
>> rationale as L4S as it would be currently more reliable. Sure, L4S 
>> could claim that it also uses functionally uses ECN and hence has a 
>> slightly stronger claim, but since the L4S arch draft explicitly 
>> mentions allowing non-responsive bounded-rate (and hence essentially 
>> non ECN-aware) flows in the LL queue it seems clear that ECT(1) in 
>> addition to all it's other issues is not really fulfilling L4S's 
>> marking needs exhaustively.
>>
>> That said, the only real uses L4S is likely going to see any time 
>> soon, IMHO, are those that have an immediate monetary advantage for 
>> the ISP rolling out and operating the L4S infrastructure, and hence 
>> SLAs between content suppliers and ISP that make sure to conserve the 
>> L4S DSCPs seem like a natural solution to the issue.
>> In the spirit of walking before running it would IMHO behoove the L4S 
>> effort not trying to solve all potential problems a priori, but 
>> rather experimentally demonstrate that even a restricted scope L4S 
>> deployment has actual merits in real life.
> []JM I broadly agree with this argument. And, as noted further down, 
> the relatively small improvements in latency will only be significant 
> on paths where the baseline RTT is already quite small, implying both 
> a short geographic distance and a small number of routing hops between 
> the endpoints. These are exactly the conditions most likely to be able 
> to deploy a Diffserv solution through the normal SLA process.

[BB] The benefits of removing say 20ms of tail latency easily apply in a 
country up to the size of the US (45ms RTT coast to coast in glass).

I assume that you are aware that there is more than 1 ISP in the US.
And more than 1 ISP in Europe for that matter.

Details are important. And being on the right planet is even more important.

>
> [JM] The challenge with L4S is that it relies on the classifier not 
> only for low-latency service (a performance improvement, whose loss 
> would typically be tolerable) but to configure the type of congestion 
> signalling (a safety requirement, whose loss would be dangerous). This 
> is, I think, why they sought a classifier which would reliably 
> traverse AS boundaries. This design requirement ultimately stems from 
> their early design decision to perpetuate the DCTCP signalling method, 
> which changes the semantics of CE.
>
> Unfortunately this is not the only requirement exposed by that 
> decision. Not only must the classifier signal *survive* throughout the 
> path, but every potential bottleneck node must *understand* the 
> classifier and apply the different congestion signalling. This puts 
> L4S back in the position of having to limit deployment to controlled 
> environments, only now without the Diffserv "containment" mechanism to 
> help indicate when it strays outside of such an environment. This in 
> turn leads to the present attempt to work around the problem with 
> "classic detection" algorithms, which I believe will show significant 
> detection latency and will therefore be unable to switch modes as 
> seamlessly as SCE has already demonstrated.
>
> With SCE we have approached the problem from a different direction 
> from the start: Safety First. The spare ECN codepoint is used as an 
> additional output from the network, and CE retains its existing 
> meaning and usage. This means SCE can be deployed across any existing 
> network with congestion safety, competing normally with conventional 
> traffic - because on a conventional network an SCE flow is almost 
> indistinguishable from a conventional flow. The performance benefits 
> begin to appear, seamlessly, when the bottleneck on the path is SCE 
> enabled.
>
> And this means that if a Diffserv codepoint is used to request 
> low-latency service for an SCE flow, it can be given by simply 
> adjusting AQM parameters for that traffic, *without* impairing safety 
> should this classifier be lost en route, and with completely 
> equivalent performance. I think this is a very important point that 
> the L4S team has overlooked, in their continual attempts to discredit 
> the SCE project.

[BB] Yes, all this is known.
SCE is not the only way of doing safety though.

>
> [JM] We are working on a demonstration of this capability, which we 
> may be able to show at Vancouver (remotely), perhaps via the 
> Hackathon. Of course the fully-integrated code will also be publicly 
> available at the time of demonstration, so you can replicate and play 
> with the results.

[BB] As I said, we will publish results of another way of doing safety 
(that we also identified right from the start): Classic ECN AQM 
detection and fall-back. Probably early this week, but certainly also in 
Vancouver.

SCE shows that, if you hobble an experiment too much, you make it 
unworkable over real networks with real tunnels, real transport 
protocols and real applications.

For instance, is there any interest from the major end-system stacks in 
implementing SCE rather than L4S, given how often SCE is unlikely to work?


Bob

>
> - Jonathan Morton
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/