From nobody Sat Oct 31 07:55:16 2020 Return-Path: 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 7145F3A0C8F; Sat, 31 Oct 2020 07:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 p3pgJkvI0BcV; Sat, 31 Oct 2020 07:55:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 424C53A0C8E; Sat, 31 Oct 2020 07:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604156057; bh=m9LpsCNdzeKYZNriu3Z9ws5G9ip+6uIexvvkHdozotI=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=dpmR2+W/4lqOy6F2Jr+0fYifb9y+F30rhceglNs85eWwhxZquyju1VQnQQkT7jAl/ FiHazVZirZK+HQs/1kwUEq69ZZ66b46MzjP62THfLTNQa1z+5P6MXsIelvj598YKZA Ba7ET/x3rBCQYXg1E4Zmvx1sXpNjaH7xwV9fyVcI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [134.76.241.253] ([134.76.241.253]) by web-mail.gmx.net (3c-app-gmx-bs36.server.lan [172.19.170.88]) (via HTTP); Sat, 31 Oct 2020 15:54:17 +0100 MIME-Version: 1.0 Message-ID: From: Sebastian Moeller To: Bob Briscoe Cc: tsvwg IETF list , iccrg IRTF list , TCP Prague List , "De Schepper, Koen (Koen)" Content-Type: text/html; charset=UTF-8 Date: Sat, 31 Oct 2020 15:54:17 +0100 Importance: normal Sensitivity: Normal In-Reply-To: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net> References: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:BiejEYDwIkaRC8AbzJkA7vtY3m71C5RBW/UITmRdlU5x5vuw9mnkkRc0rMz5a635fw6v9 3uAcNJa/gaOCTaoQqV+VgXnQyaddMWObST5RuUkJWPBbzX3oYATRKWNBWqRVXBsiYqpDCU/cfC6Y id7YF0LksKnHmYF8AN6q+tgmOZ0Tun+UdPQ2wwLhotdUoW/SXk1h4uVYK4TD3qUANevrekhmsWcT 5CPLNAR5Tm+vKjzVGYorvq84tKl/zvpp9upuK6dDP1u+qKyXci6qYWr1d2fBkwRbSRtzm66A1B4A GE= X-UI-Out-Filterresults: notjunk:1;V03:K0:oiQVmQRfIFg=:iTdJammkkGD5nl1b2PGu6+ WfGepWY3vrBVuH6l8seMBT4NraPUfMdduMt5HhzFOpnKgT72B6/yvAbB7Z3Dk8MKoZ0H6DJs8 O31r+RpjFoTtsBMJOEZ+3lAJQyNhxAV22/C390keZEIGh0Z3SKohNr/xBh4XMD2bh7l0/CDu0 a4v4lsvdDJn2x79OerZi68yc0vyTpOTaL/hd0f79fiZDYYBJakLsH6mG7rF0oqVeiVF1QCeWS 3IxjiSLEo++02wug8HYGmyT6/cLfnlhMOcv6EPJwspI1Jk04lXHcOL4rzz5k6c02EuWj8zLwI CRACSljjhNB/gHgPaBeVWO4oNPLOpFSUFFbbqc4QAZtwBj4fqCWOL1mmnBxLHFWaYSwIyOkXV 8zDZfZS6LjyiIfLEvax0kzHQa7pRLqhGBzJTl6EVOd/+Si1al+e4xiMnFZgA6S0ZlHvCX1DMS o1qCNsoPbT6CQyC8okc5uXJeiGsiojHeRHHswa5JGXvmpaZIYJN7KVK2m80tXjW7TeCBxdim6 wv8997In5pdmAdoPibbetkNFtChdjw8MrqeS7H+ChXl7ZsLpAGN69gCPzeJTu6C4OQCRbE66y rsDZJPY2cxx/M= Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.29 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 14:55:07 -0000
Dear Koen,
 
since Bob claims that he intends to correspond with my input, I am ad= dressing this response to you, See my comments in-line prefixed [SM].
 
Tl;dr: I appreciate that team L4S is finally admitting that it over-p= romised and under-delivered, I am less happy about the solution to this is= sue by simply reducing the requirments ot match the unsatisfactory state o= f the L4S implementation. After years of basically adveritizing on these r= equirements, watering those down at the last minute does not qualify as a = good faith effort in my book. It does confirm my negative view on team L4S= ' acumen and confirms my judgement that L4S "offers too little to= o late". Unfortunately I do not kid myself that this obvious fact is = going to stop the current intenet drafts gaining RFC status without any me= anigful changes. 
 
 
Gesendet: Samstag, 31. Oktob= er 2020 um 10:54 Uhr
Von: "Bob Briscoe" <ietf@bobbriscoe.net>
An: "tsvwg IETF list" <tsvwg@ietf.org>
Cc: "iccrg IRTF list" <iccrg@irtf.org>, "= TCP Prague List" <tcpPrague@ietf.org>, "De Schepper, Koen = (Koen)" <koen.de_schepper@nokia.com>
Betreff: [tsvwg] ecn-l4s-id: Proposed Changed to Normative Cla= ssic ECN detection Text
Folks,

The co-authors of ECN L4S ID have been reviewing the correctness of the no= rmative 'Prague' requirements.
 
        [SM] This seems less about corr= ectness and more about whether you managed ot hit those targets with your = implementation. Changing those requirements post-hoc might be justified, b= ut pleas do not frame that as a correctness isssue.
 

    See https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section= -4.3
This is the second of 2 emails, about 2 of the requirements that we think = ought to be reworded a little.

If you agree with the rationale, but think the new wording still doesn'= ;t fully capture the requirement, pls suggest sthg better.
If you disagree with the rationale, pls discuss.
4.3.  Prerequisite Congestion Response
...
CURRENT:

   o  A scalable congestion control MUST react to ECN marking from a
      non-L4S but ECN-capable bottleneck in a way that will coexist with
      a TCP Reno congestion control [=
RFC5681] (see Appendix A.1.4 for
      rationale).

      Note that a scalable congestion control is not expected to chan=
ge
      to setting ECT(0) while it falls back to coexist with Reno.
 
PROPOSED:
   o  A scalable congestion control MUST implement monitori= ng in order
      to detect a likely non-L4S but ECN-capable = AQM at the bottleneck.
      On detection of a likely ECN-capable bottle= neck it SHOULD be
      capable (dependent on configuration) of aut= omatically adapting its
      congestion response to coexist with TCP Ren= o congestion controls
      [RFC5681] (see Appendix A.1.4 for rationale= and a referenced
      algorithm).
 
        [SM] This is a significantly watering dow= n, and it seems rather non-logical, IFF an implementation does not want/ne= ed to actually react to the result of a detection then performing that det= ection seems pure busy work. So make both of these MUSTs. Otherwise y= our requirments pretend to care about existing rfc3168 AQMs but in name on= ly. 
 


      Note that a scalable congestion control is = not expected to change
      to setting ECT(0) while it falls back to co= exist with Reno.

RATIONALE:
1/ The requirement as currently written says what an omniscient sender MUS= T do. So there's an implied requirement that a sender MUST be omniscie= nt, which is of course impossible.
2/ The requirement needs to be recast to require a sender to aim to b= e as knowledgeable as possible. Then, what it does as a result needs to ta= ke into account the a priori likelihood of there being a non-L4S bottlenec= k present.
3/ This includes the possibility that the operator of the host knows that = the network it serves has not deployed any single queue classic ECN AQM (e= .g. in a CDN case they're doing out of band testing, or they've as= ked the ISP). So we've included the possibility of fall-back being dis= abled by configuration.
4/ Nonetheless, as has been pointed out on the list, there is still a poss= ibility that there is a Classic ECN AQM somewhere else on the path (to con= tinue the CDN example, perhaps beyond the ISP in a home network). The '= ;MUST monitor' requirement still stands to ensure the operator doesn&#= 39;t miss these cases.
5/ Then, if the server operators have disabled fall-back for their deploym= ent, they can reconsider their policy or at least do more focused testing = if they are frequently detecting a single-queue Classic ECN AQM.
 
        [SM] And we are back to engineering/netwo= rk administration by wishful thinking... Again with a syszem (L4S) that ha= s not yet been proven to actually work over the existing internet with the= sole exception of short RTT/low hop count paths (CDN to end-user fast-lan= es copme to mind).


Items 3-5 are the "react via management" model that I've tal= ked about on the list, given the unfairness doesn't amount to starvati= on, and it is possible that the prevalence of the problem is very low.
 
        [SM] Given that you never offered your ow= n specific defintion of what starvation entails, I fail to see how that cl= aim can b tre in a verifiable fashion?


Finally, after the bullet list of requirements in section 4.3, (which are = prerequisites for setting the ECT1 codepoint), we propose to add the follo= wing requirement, as suggested on the tsvwg list:

      To participate in the L4S experiment, a sca= lable congestion control MUST
      be capable of being replaced by a Classic c= ongestion control (by
      application and by administrative control).= A Classic congestion control
      will not tag its packets with the ECT(1) co= depoint.
 
        [SM] +1; I would appreciate if we could a= dd a sentence like:
 
"In the unlikely case of the L4S experiment being declared a fai= lure, this replacement will need to be permanent, and the ECT(1) responsiv= e elements in AQM nodes also needs to be disabled".
 
I added the unlikely in spite of my own predictions, to account for t= he fact that the drafts are written on the hypothesis that L4S works as ad= vertized.... 
 
Best
        Sebastian
 

Cheers


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