Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt
Bob Briscoe <ietf@bobbriscoe.net> Mon, 11 March 2019 16:29 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 1A239127962 for <tsvwg@ietfa.amsl.com>; Mon, 11 Mar 2019 09:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 v5BM5AYm7skF for <tsvwg@ietfa.amsl.com>; Mon, 11 Mar 2019 09:29:10 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 977A112008A for <tsvwg@ietf.org>; Mon, 11 Mar 2019 09:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=ysm9R5ZwAzpA5uFmJjCOkDPu5UrccEWjfx9xa2Mng84=; b=a81XUrs4LL/eWLBN3GxFR7Lsi lsxAj+FGTIelgc236lGJmaGMmJ6P3Y2XBCY5q0ipCbpvgTCwJND5QfAhLrkracnChqdR/dlUlvsTg obBoJrXg+kD4Cq9qaMVkVjIzHZm3FyhISlWAD7EMpcSrr5Bmj99/N4aOX2yK8S04tSAXL3SeYFT2d /bF/dbj8hXTu0FMeaP6c7eRmzOFaLN6gg9X6I4GTot6gDeCdiz7x5GrMS67dwILoS8NdIKEmML64L phzuaE6Vp/Bl7GYwbQEAtV0a5jYPaxuJe6exYsTD3Z/2iWlkfQrbfiN7vuqJYDuprICtihm79ALb6 x2gm4o9ew==;
Received: from [31.185.135.153] (port=50070 helo=[192.168.0.9]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <ietf@bobbriscoe.net>) id 1h3NnX-0001fo-2s; Mon, 11 Mar 2019 16:29:07 +0000
To: Dave Taht <dave@taht.net>, tsvwg@ietf.org
Cc: Jonathan Morton <chromatix99@gmail.com>
References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net>
Date: Mon, 11 Mar 2019 16:29:06 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <87h8canrc6.fsf@taht.net>
Content-Type: multipart/alternative; boundary="------------F674BC627153BF7C6C11CFF2"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/J26tvBVp57KNyuCoVB8v6CwkJPE>
Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt
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, 11 Mar 2019 16:29:13 -0000
Dave, I'm pasting my comments on this from the bufferbloat list here. I guess discussion on assignment of an IETF codepoint ought to continue here. ======================================================================================= L4S is far from dead. It's merely been working differently from how you're used to. Those working on an L4S AQM (at least those in the cable industry) had to have a private WG for the last ~18 months, but now we're allowed to publish and talk openly again. Similarly, there's work under the covers on an L4S AQM in switch hardware. And I see external signs of work under covers on DSL access equipment (covers that I am not under any longer). Nonetheless, I think you will see updated Linux code for an L4S DualQ Coupled AQM built against the mainline tree appear on netdev list today. ==In summary== The problem that the SCE draft identifies with TCP's sharp multiplicative decrease is also the primary problem that L4S identified. Like L4S, SCE requires changes to network, sender and receiver (see comment later about the rcv-window approach hinted at in the SCE draft). But SCE is just starting on its journey. Having to change end systems and network together is really tough and takes many years. It seems you're trying to do the same thing as L4S, but by slightly different means. Before splitting the people involved in this into two factions, can you say what you didn't like about the L4S approach in the first place? We've been very careful to specify L4S broadly enough so that it can encompass many different approaches within it. The only thing stated against L4S I can find is that it's taking a long time. Starting an identically difficult approach now is going to restart the clock, and take a lot lot longer. ==2 output values vs. 2 input values.== We considered schemes where the AQM can use a second marking as a lower strength /output/ (like VCP, my own QV and now SCE). But we worked out that there were a wider range of advantages and much more significant performance improvements from the sender using a second marking to distinguish how it will behave (i.e. a second /input/ to the classifier in front of the AQM). Don't get me wrong. It's useful that you guys are putting the work in on SCE. Then everyone can compare the two approaches (again), as a check on whether that decision was correct. That's important, cos ECT(1) is the last useful codepoint in the IP header. See: "Notification of Less Severe Congestion than CE" at https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#appendix-C.2 where we've written: Before assigning ECT(1) as an identifer for L4S, we must carefully consider whether it might be better to hold ECT(1) in reserve for future standardisation of rapid flow acceleration, which is an important and enduring problem [RFC6077 <https://tools.ietf.org/html/rfc6077>]. ==FQ-only vs. FQ or DualQ== One of the problems with the 2 outputs approach (SCE etc.) is that it is only possible with per-flow queuing. I doubt you'll get the last useful codepoint in the IP header for just that. It's sort-of obvious that, if you try to implement SCE in a FIFO, you can only have one queue length for all the flows. Then legacy TCP flows that don't understand SCE would push the queue deeper to the CE threshold, ruining it for the flows that support SCE. We worked out that the 2 inputs approach (L4S) is more generic - ie. it can be used with FQ or DualQ (multiple or just 2 queues). For instance, you can modify fq_CoDel for senders that uses ECT(1) to indicate that they support a small multiplicative decrease (L4S senders). You only need the following: Include the last bit of the ECN field with the flow ID when you do the classification for sfq. Then in the queues with ECN==X1, you instantiate a shallow threshold ECN AQM. This could be CoDel with a shallow 'target', but you also want it to respond immediately (zero 'interval'), so even a simple step at about 1ms will work, but a random RED-like ramp on the /instantaneous/ queue is much better. ==Re-purposing the Receive Window?=== Receiver congestion control using the receive window may seem like a useful stop-gap, but it runs counter to how nearly all today's transport protocols are intended to work (except, I know of a LEDBAT-like example from Microsoft Research). So you will have your work cut out proving that it is stable and that the two ends don't fight, etc. if you think L4S is taking years, you will find that takes longer. There is current research on this that I can point you to, if you want. That's why we chose an approach that had a pre-existing widely deployed existence proof (DCTCP) to start from. IETF groups like rmcat explicitly decided early on to require the approach where the receiver is a dumb reflector, then new sender congestion control algorithms can be deployed unilaterally. The argument was that the feedback function can be thought of as a sub-layer below the congestion control function. The ongoing addition of accurate ECN feedback to TCP and to QUIC also take the dumb reflector approach. And RTCP already does it that way. ==ECN feedback problems=== Over the last decades, we've made sure that the ECN feedback schemes for TCP, QUIC, RTP (but not SCTP yet) can all feed back ECT(1) as well as CE, in case a scheme like SCE came along. However, the solution in the TCP case [draft-ietf-tcpm-accurate-ecn] is still problematic for SCE if you're impatient. The base scheme overloads 3 bits in the TCP header, which it uses to feed back CE only. To feed back ECT(1) we had to add a TCP option. That's not going to get through middleboxes for many years. The TCP option is also optional to implement. Two of the main TCP developers are currently saying they will probably not implement it, at least not initially. ==Tunnels and lower layers== Over the years I've maintained a fairly lonely activity to make sure that the ECN propagation behaviour of tunnels and layer 2 protocols will treat ECT(1) as either a stronger output signal (as in SCE) or as an alternative input signal to an AQM (as in L4S). Theoretically, this allows either the SCE or the L4S approach. HOWEVER, you would probably not be surprised at how many people read the spec [RFC6040], and say "Ah, no router alters ECT(0) to ECT(1) today, so I'm not going to implement that unnecessary extra line of code in my tunnel decap." ==Wider benefit: Relaxing link ordering== By overloading the ECT(1) marking to mean "the sender uses time for loss detection" a link can relax the reordering requirement on ECT(1) packets today. You can do that with L4S, cos the sender is selecting the marking. You can't do that when the AQM is selecting the marking (as with SCE). If transport protocols detect loss in time units without tying it to any marking (as in RACK on its own), a link cannot use this to relax the ordering requirement until it is sure that all the legacy non-RACK transports have decayed out of the network. That would be measured in decades. HTH Bob On 11/03/2019 01:16, Dave Taht wrote: > I think this gets the procedure right for submittal here. > > internet-drafts@ietf.org writes: > >> A new version of I-D, draft-morton-taht-tsvwg-sce-00.txt >> has been successfully submitted by David M. Täht and posted to the >> IETF repository. >> >> Name: draft-morton-taht-tsvwg-sce >> Revision: 00 >> Title: The Some Congestion Experienced ECN Codepoint >> Document date: 2019-03-10 >> Group: Individual Submission >> Pages: 7 >> URL: https://www.ietf.org/internet-drafts/draft-morton-taht-tsvwg-sce-00.txt >> Status: https://datatracker.ietf.org/doc/draft-morton-taht-tsvwg-sce/ >> Htmlized: https://tools.ietf.org/html/draft-morton-taht-tsvwg-sce-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-morton-taht-tsvwg-sce >> >> >> Abstract: >> This memo reclassifies ECT(1) to be an early notification of >> congestion on ECT(0) marked packets, which can be used by AQM >> algorithms and transports as an earlier signal of congestion than CE. >> It is a simple, transparent, and backward compatible upgrade to >> existing IETF-approved AQMs, RFC3168, and nearly all congestion >> control algorithms. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- Re: [tsvwg] New Version Notification for draft-mo… Dave Taht
- Re: [tsvwg] New Version Notification for draft-mo… Michael Welzl
- Re: [tsvwg] New Version Notification for draft-mo… Bob Briscoe
- Re: [tsvwg] New Version Notification for draft-mo… Greg White
- Re: [tsvwg] New Version Notification for draft-mo… Loganaden Velvindron
- Re: [tsvwg] New Version Notification for draft-mo… Dave Taht
- Re: [tsvwg] New Version Notification for draft-mo… Greg White
- Re: [tsvwg] New Version Notification for draft-mo… Dave Taht
- Re: [tsvwg] New Version Notification for draft-mo… Holland, Jake
- Re: [tsvwg] New Version Notification for draft-mo… Luca Muscariello
- Re: [tsvwg] New Version Notification for draft-mo… Greg White
- Re: [tsvwg] New Version Notification for draft-mo… Holland, Jake