Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Fri, 05 March 2021 09:48 UTC
Return-Path: <ingemar.s.johansson@ericsson.com>
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 568293A2295 for <tsvwg@ietfa.amsl.com>; Fri, 5 Mar 2021 01:48:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 PU0cSxnfGun4 for <tsvwg@ietfa.amsl.com>; Fri, 5 Mar 2021 01:48:24 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0610.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::610]) (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 0A99E3A2294 for <tsvwg@ietf.org>; Fri, 5 Mar 2021 01:48:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VHruvZDDYC5JL8hIecI5ab/Uvs6c8kBCo61Fil10LcURj8bFbVthmGA6kMJniBhCWTZ3JauMeyQKuxkJDKVMKeKtTwBIbdA07/y0ucSPI61b+nFJBoqUtStZy33GLN1irLzrT5U4+h2hqRgF6Kfvao3rNf7bdXc/wLDBp6wvGTjHW4EddLkwPEcM4gmGvhOPyXdgKYm+XHJ8tZRaI+zAu/dCeKINAKvwrv3xBPpYA98ZDmMgZ5DRuhpa5TuWqnItOHecmGVcGBoV4yMKvay6Cm9FEJUOBsZqQeQ85fvgi4RSF6kPtebHPB+vn820Rs8yu8pI6fSlWqgaFYRZjl652w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9A4dtxEKX2Mt3AOlmaI5K23LU5A4MlaC6WKXLX/eIFA=; b=k8hZNONRUM9aLpq+NXdO+G0WzZRLJhlbiauuM6HORBAt99WLDQoip3a/HBpmJYfPQQIUwOMDDxydRwmwzK822NcOLC0ySPlci7vzpYvrw/xNwIwQdjj4Ry08ZsUV9kHGzZboaKZGacRAMbbL+PItDTpoWglDTuUSpFA+AWmarA0oZDmfcZFopzg+1XW6OkhCg5qZA+5UTjCSljmvaDBS7b0u4zSvC5A1Li6VMwVps1SUsvmayvYTVwngV88sgtTb5oHxSSIC9qIzg0lr7z7pX8myWKzeCl7v7hr5xSaLn0bQZjquu2XvlKECI5+2s63198BWXrU9gHZ1SIONZU/Ysw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9A4dtxEKX2Mt3AOlmaI5K23LU5A4MlaC6WKXLX/eIFA=; b=ieIJ2yacvRyFNgQ7CLm7BvIdcz4L653zX/Amwp6z/0Md4nJFf/RSi1MIsiEWr4ni0POs2br7NsA9Q8xCYBfL1+3EtTwwRCTUqZ4Gq2ZVs2+feQTTjJkv9P5cJ7kVHLiJVz+yPwoIPzsATqJI9dyuxTdrIIcN0IUhO0wUXXUrPRc=
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com (2603:10a6:3:6c::8) by HE1PR0701MB2745.eurprd07.prod.outlook.com (2603:10a6:3:9c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Fri, 5 Mar 2021 09:48:08 +0000
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::a087:95cb:e76b:d57]) by HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::a087:95cb:e76b:d57%10]) with mapi id 15.20.3912.022; Fri, 5 Mar 2021 09:48:08 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
Thread-Index: AQHXCWZCvmGifpb3UU+S0XXgb+aApKppUHsAgAdzlwCAAZpxsIAAMPQAgADlLcCAAAnrgIAAtQAAgAD/bZA=
Date: Fri, 05 Mar 2021 09:48:08 +0000
Message-ID: <HE1PR0701MB22999191DE9B8F34FBA48174C2969@HE1PR0701MB2299.eurprd07.prod.outlook.com>
References: <161403126355.2878.575062349927307577@ietfa.amsl.com> <20210225200602.lix6lyq2w6c6bclz@debian.debian> <bb46880a-0e4a-b5a3-24a8-95123a3d6a48@bobbriscoe.net> <HE1PR0701MB22993AB48783A4E011335A36C2989@HE1PR0701MB2299.eurprd07.prod.outlook.com> <f618a4b0-eed3-f369-8646-bd6a6c99a2a7@bobbriscoe.net> <HE1PR0701MB22996B90865665EEAEACB8F7C2979@HE1PR0701MB2299.eurprd07.prod.outlook.com> <c2ff0735-6c48-dcd6-d59c-118cff3bfe2d@bobbriscoe.net> <5b46ce90-dd4a-2938-e47e-615af2c3032e@bobbriscoe.net>
In-Reply-To: <5b46ce90-dd4a-2938-e47e-615af2c3032e@bobbriscoe.net>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e5c7f4b8-ec4e-41be-469e-08d8dfbbc86f
x-ms-traffictypediagnostic: HE1PR0701MB2745:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB274506AD225F005AC9C26EC3C2969@HE1PR0701MB2745.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5516;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Sy5zsXnTW1mZ13I5xtqcucSuTShjI7ZDpsKeXUnCwHmFmnVGly210ApXgcHGLvTBbQxn/1AiOltLk3CKMg0UKntc6U5QoFIU3IEwbO+xTEzNfiQnOUrsQUxKXdm08S4Cbphsdjo6daf3bl/gGj9/YQ8vhi0XLcb0U2hMEPYDbdh621cx/ZcX3OcE26KZZMgVlzRSVxWstna1z1L4iQRUIUeaMaZljdKUx7jUo77/sySKZ8ThAXvW2kdNhQURPYcQe/Yf+6kzqURN+hDEl2ExRty3c4c+suZhbhHj2CyA8GHgbJAcAYn02bkn8l/8VOsjU6z0sITfdvLXEcguh83Ui9IwdeWiVYj5+lEOY36PczmNNTMe949JMkp113yftzG4MBaeQr8YjUpMdZtCFfPDkweeUjWF8IOmhpEN/kWOQFETP/WaGS8thznQbVgehP5zBmzQgQMosILqPweRUeoYBYTFTj1AoKP/Z3oelgiJY1xuNUoaej+cfxSPlrpjesehIiLDor1SDVRuMc4y5r/9kazM0eC6YeaTwgURZmSeb8NKOPzQueBNewXJR3NXDyGB29+w+Q0/qczw3hBqj+0D8Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2299.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(71200400001)(83380400001)(66556008)(66446008)(66574015)(107886003)(33656002)(4326008)(55016002)(99936003)(86362001)(498600001)(9686003)(110136005)(66476007)(64756008)(66946007)(2906002)(66616009)(26005)(966005)(186003)(8676002)(76116006)(7696005)(30864003)(52536014)(6506007)(5660300002)(53546011)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: TwJW4Q0FdZLRwIVPhzcXHTqRpIQjGx4gTG68oeRJxVKvb+nS5AHlg1MVM67PnwCgw5mflcjq+W1cmDGtQdjfaBS7OZDXLlAG/NBq2FpfeqCD/tDBghPl5CqMXqgiokQ/lEI87VJo/wo2ZL62rI49mJSPSzRlB80Jvek0ld+SW37A+edU6Dwc19bmXzWRRHhh74X983W68nzoOZ3LNOQ4+2s/IldY2PWdiz/gXMgOy3cm82P/VWwSojua17Cd3rygFD7Lx5peoULIE2A3uXA54oc9eBSsb35RSo/b1xCtJIrg5fGogOu322pvD4A+PprcBJgl+59YFdqWiZsajqw+oooXeMBcRQOc+OPuRjRd7L18tLURDhZn+SHknyZFlnFKuJXQhnhB06514lZGqcoJySQTyMusYCmGjSz/LgzfKUL2BOlTbHgxrvT5pHXYlHwf9+lEFSio44P8RjbyUQZbPuyOl1FoeORFRfn1CwZR19x18oTO40InN27/3MGye+ETrrDkA1BR5jVKMOfCYqwwbq6HYyaFmQV78HPDOQ5KJNabvwi0R/gqpG1EhJ9OGwPIumUiMKwn0lbh9Y1e/1dTnzgePfWfxljrS4t28EFJB2n26BFS73cgKjMzob4kT2WXPfica0NAGd39n+jp/z+n501HgDBXNkp/JqP9lykvZL3VGSgROyAkUVPLBFh4v0qgRWRthgSsU/l3z/vuiKPDFF+XDWqREiBzw49ART29VJfS+UhqSEAmYWJ8Z6hxO5j5ybxhIdZ5uUCkE0z6yq+mpVetUvhSg7w0127ZScHbskpI+XSLop6b2jQFYltid9NhZoT51Rm3Ml133EOQcDBal1ZAtQg7qvEx3xS+Q0NDw7cce+tRI/5dH1SNk+ybgXeLMX4XR4w+fUz6VZ5bLHXmcJw6HBZRKDCcD3/7w9VyULFXgaTlizcAeKuU0ZnswGFHl+grBHnx9xxOyXYrLUhDsIU+Ytkya1Fiu9k12yCcNCfve/AUCKm3ePRb76jB3mKDAAHAvMwMHTG04CB+OnT0q1v1NQStcsuyUzKrzqkr8cTpJMJPgEmlyYnrZevsLOBnMXE5ZgwuH+1MCsnxqZwqgl4SZsajekbGDCPMrUNmas7UGLQLDuVvdxhJDS4CxJ7KlQk8XUhJIMH+ZqD5qfK0eCrdlCMmUoQ7ue6fa/FZVWRf2Kdy7y9xvSJ7QdI8Fu8Mvg3MVx3uEazN4hVvnRltQm8omm/t3gcdWLm+fMSLvPvyccXPWcS0fxXfZ7BDzdA6/jGcHLy4cSoecbk+PINKj1qZZpo2suMkIRScolKaM63RpbpG/q6DUqOX47Y7Kb2+
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0A1F_01D711AD.062EBE20"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2299.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e5c7f4b8-ec4e-41be-469e-08d8dfbbc86f
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 09:48:08.6399 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FOnpg8Tx3caaZMR+IlAygy//N4X1JypQ+/L30fFFgZyZV92BpjxHNoVCsEhdCtWGX+PkAHVCWXxLnBTi9iB3wvjM6u3dJzLyi4omV8t1Efhz+spqQ2qULMYMKh9XPx6/
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2745
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/28zZx_0HFiGi7vjItvDWWVS4_Ew>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.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: Fri, 05 Mar 2021 09:48:27 -0000
Hi Please see inline > -----Original Message----- > From: Bob Briscoe <ietf@bobbriscoe.net> > Sent: den 4 mars 2021 19:21 > To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; > tsvwg@ietf.org > Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt > > Ingemar, > > Sorry, you probably thought this thread had ended this morning, but... > > I've had someone suggest (off list), that the conclusion that RTCP datagrams > can be ECN-capable ought to be written (informatively) into ecn-l4s-id. It > would go in Appendix A.2.1, which would have to be > retitled: "Setting ECT in -TCP- Control Packets and Retransmissions". > > Before doing that, I checked RFC6679. It says "RTCP reports MUST NOT be > ECT marked, since ECT-marked traffic may be dropped if the path is not ECN > compliant." > > This seems rather paranoid, given the path is first checked for ECN support > before using it on RTP media. It justifies this by saying the path might change > to one that black-holes ECN-capable traffic. Whatever, if RFC6679 (proposed > standard) says this, I don't want to contradict it. > Do you think it would be OK to say: > > "RFC6679 precludes the use of ECT on RTCP datagrams, in case the path > changes after it has been checked for ECN traversal. L4S experiments will > need to observe this rule. Nonetheless, as ECN usage becomes more > widespread, it would be useful to gather data on whether such caution is > necessary." [IJ] Yes. it makes sense. I guess the text was written at a time when it was uncertain how likely ECT traffic is to become black holed. I understand that today these cases are quite rate. Still, if it happens, then real time streaming applications should implement circuit brakers (https://tools.ietf.org/html/rfc8083) . This should make it safe to use ECT for RTCP traffic as well. > > Does that seem reasonable? > > > Bob > > On 04/03/2021 07:33, Bob Briscoe wrote: > > Ingemar, > > OK. I think we've converged. > > Thank you > > > > Bob > > > > On 04/03/2021 07:15, Ingemar Johansson S wrote: > >> 😊, quite likely that the misunderstanding was on my side Please see > >> inline [IJ2] /Ingemar > >> > >>> -----Original Message----- > >>> From: Bob Briscoe <ietf@bobbriscoe.net> > >>> Sent: den 3 mars 2021 18:18 > >>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Asad > >>> Sajjad Ahmed <asadsa@ifi.uio.no>; tsvwg@ietf.org > >>> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt > >>> > >>> Ingemar, > >>> I obviously didn't phrase my question clearly. Pls see inline [BB]... > >>> > >>> On 03/03/2021 14:31, Ingemar Johansson S wrote: > >>>> Hi Bob, Asad + others > >>>> > >>>> Answer to the @Ingemar question inline below [IJ1] : > >>>> > >>>> /Ingemar > >>>> > >>>>> -----Original Message----- > >>>>> From: Bob Briscoe <ietf@bobbriscoe.net> > >>>>> Sent: den 2 mars 2021 14:54 > >>>>> To: Asad Sajjad Ahmed <asadsa@ifi.uio.no>; tsvwg@ietf.org; Ingemar > >>>>> Johansson S <ingemar.s.johansson@ericsson.com> > >>>>> Subject: Re: [tsvwg] I-D Action: > >>>>> draft-ietf-tsvwg-ecn-l4s-id-13.txt > >>>>> > >>>>> Asad and Ingemar, > >>>>> > >>>>> @Asad. Thank you v much for reminding me of that section in > RFC3168. > >>>>> The text in ecn-l4s-id wasn't trying to allow a higher min window > >>>>> than existing RFCs. Indeed, it was trying to encourage > >>>>> implementers the other way - lower. But without forcing anyone, > >>>>> because implementing a lower minimum than 1 requires a > >>>>> step-change in complexity (as your thesis on this subject taught me). > >>>>> > >>>>> I don't think the first sentence with the SHOULD contradicts > >>>>> RFC3168, but it seems the second sentence makes it look that way > >>>>> to some > >>> people's eyes. > >>>>> So let's reword it. Also, I notice that it was only applicable to > >>>>> TCP, not all transports. How about... > >>>>> > >>>>> A scalable congestion control SHOULD remain responsive to > >>>>> congestion when typical RTTs over the public Internet are > >>>>> significantly smaller because they are no longer inflated > >>>>> by > >>>>> queuing delay. It would be preferable for the minimum > >>>>> window of a > >>>>> scalable congestion control to be lower than the 1 > >>>>> segment minimum > >>>>> for TCP mentioned in S.6.1.2 of [RFC3168] (or an > >>>>> equivalent for other > >>>>> transports). However, a lower minimum is not set as a > >>>>> formal requirement > >>>>> for L4S experiments (see Appendix A.1.6 for rationale)." > >>>>> > >>>>> > >>>>> @Ingemar, you said your min in SCReAM is 3 datagrams, but you > >>>>> could configure it lower. Are SCReAM's datagrams smaller than the > >>>>> MTU? Is the text above clear enough for a non-TCP transport? > >>>>> Whatever, would you set a different limit? > >>>> [IJ1] Yes, you can probably set it lower. In practice however I > >>>> have not seen > >>> much need to try that extreme as SCReAM is mostly to be used with > >>> services that require edge user access, where RTTs still are in the > >>> order of milliseconds at best. This means that the BDP will be a few > >>> kilobytes at a minimum. I probably need to look closer into this if > >>> necessary.. The RTP packets are delivered by the video encoder > >>> pipeline where the MTU is set in the RTP payload packetize. One can > >>> perhaps change the MTU on the fly to lower values of the BDP of the > >>> links become very low, not sure however if that is possible for > >>> instance in gstreamer. > >>> > >>> [BB] I was trying to ask what you meant the typical min window would > >>> be in bytes. > >>> That's the only reason I was trying to ask what MTU you were > >>> thinking of, not because I was thinking you could reduce the MTU to > >>> force more packets per window (that's a bad idea IMO). > >> [IJ2] OK, understood. SCReAMs window is in bytes, but the RTP packets > >> of course need to be transmitted as whole units. The background is > >> that SCReAM is desiged to be able to congestion control VoIP which > >> typically has much smaller packets than video (e.g. 200bytes istf > >> 1400bytes). A window size in bytes, rather than packets was therefore > >> easier to implement. SCReAM will have problem to go below 1 RTP > >> packet per window. I picked 3 packets as some kind of minimum but it > >> can perhaps be reduced to one packet but below one packet per window > >> that can be problematic. I believe that it is doable but then one > >> need to redesign a bit and I have never really tried out SCReAM over > >> links with very short RTT. > >> > >>> Also, what about this question: Is the text above clear enough for a > >>> non-TCP transport? > >> [IJ2] Yes, I don't see any difference for e.g. RTP/UDP in this respect. > >> > >>> > >>> Bob > >>> > >>> PS. See Fig 1 here https://arxiv.org/abs/1904.07598 for > >>> back-of-envelope calculations to work out if you could have a > >>> min-window problem once you reduce Qdelay. When we first started > >>> testing L4S we found we were hitting TCP's min window when we ran > >>> more than half a dozen flows in parallel. > >>> > >>>>> Bob > >>>>> > >>>>> On 25/02/2021 20:06, Asad Sajjad Ahmed wrote: > >>>>>> Bob, > >>>>>> > >>>>>> Thanks for updating and for have put in a lot of effort into this > >>>>>> draft. > >>>>>> I have a minor comment regarding the cwnd reduction over ECN > when > >>>>> cwnd > >>>>>> is already very low: > >>>>>> > >>>>>> Current draft gives a formal requirement: > >>>>>> > >>>>>> §4.3: > >>>>>> "A scalable congestion control SHOULD remain responsive > >>>>>> to > >>>>>> congestion when typical RTTs over the public Internet > >>>>>> are > >>>>>> significantly smaller because they are no longer > >>>>>> inflated by > >>>>>> queuing delay. It would be preferable for the minimum > >>>>>> window of a > >>>>>> scalable congestion control to be lower than the 2 > >>>>>> segment > >>> minimum > >>>>>> of TCP Reno [RFC5681] but this is not set as a formal > >>>>>> requirement > >>>>>> for L4S experiments (see Appendix A.1.6 for rationale)." > >>>>>> > >>>>>> §A.1.6: > >>>>>> "However, the requirement in Section 4.3 is worded as a > >>>>>> "SHOULD" > >>>>>> because the existence of a minimum window is not all bad. > >>>>>> When > >>>>>> competing with an unresponsive flow, a minimum window > >>>>>> naturally > >>>>>> protects the flow from starvation by at least keeping > >>>>>> some data > >>>>>> flowing." > >>>>>> > >>>>>> But, this contradict with RFC3168 (PS): > >>>>>> > >>>>>> §6.1.2: > >>>>>> "[...] Therefore, the sending TCP MUST reset the > >>>>>> retransmit timer on receiving the ECN-Echo packet when > >>>>>> the > >>> congestion > >>>>>> window is one. The sending TCP will then be able to send > >>>>>> a new > >>>>>> packet only when the retransmit timer expires." > >>>>>> > >>>>>> The contradiction here is "SHOULD" vs. "MUST". Also TCP CC, as > >>>>>> given out by RFC5681, does NOT mandate a minimum transmission > >>>>>> rate. TCP's loss recovery at low cwnd relies on RTO to recover > >>>>>> lost segments and TCP using ECN is supposed to mimic this behavior > [floyd98]. > >>>>>> Otherwise, > >>>>>> you risk starving the Not-ECT set of flow, driving up the queue > >>>>>> and increasing the marking probability by going unresponsive at > >>>>>> cwnd of two segments. This is about harm toward other traffic so > >>>>>> it make no sense to relax a formal "MUST". Of couse, it is > >>>>>> desireable that the AQM take action and evict packets from > >>>>>> non-responsive flows, but this is > >>>>> not true for all AQM, one example being CoDel. > >>>>>> But, the minimum cwnd of 2 does not originate from L4S, but has > >>>>>> been the current practice for a very long time at least under the > >>>>>> Linux TCP > >>> stack. > >>>>>> This, obviously, also needs to be addressed. > >>>>>> > >>>>>> Asad > >>>>>> > >>>>>> [floyd98] > >>>>>> https://protect2.fireeye.com/v1/url?k=b9da725e-e6414b1d- > b9da32c5- > >>>>> 861fc > >>>>>> b972bfc-e0a4204086eb23c8&q=1&e=417868d5-deeb-4c4f-9d1e- > >>>>> debe95d3e33c&u= > >>>>>> http%3A%2F%2Fwww.icir.org%2Ffloyd%2Fpapers%2Fecnsims.pdf > (§8) > >>>>>> > >>>>>> On 21/02/22 14:01:03, internet-drafts@ietf.org wrote: > >>>>>>> A New Internet-Draft is available from the on-line > >>>>>>> Internet-Drafts > >>>>> directories. > >>>>>>> This draft is a work item of the Transport Area Working Group WG > >>>>>>> of > >>> the > >>>>> IETF. > >>>>>>> Title : Identifying Modified Explicit > >>>>>>> Congestion Notification > >>> (ECN) > >>>>> Semantics for Ultra-Low Queuing Delay (L4S) > >>>>>>> Authors : Koen De Schepper > >>>>>>> Bob Briscoe > >>>>>>> Filename : draft-ietf-tsvwg-ecn-l4s-id-13.txt > >>>>>>> Pages : 58 > >>>>>>> Date : 2021-02-22 > >>>>>>> > >>>>>>> Abstract: > >>>>>>> This specification defines the identifier to be used on IP > >>>>>>> packets > >>>>>>> for a new network service called low latency, low loss and > >>>>>>> scalable > >>>>>>> throughput (L4S). L4S uses an Explicit Congestion > >>>>>>> Notification (ECN) > >>>>>>> scheme that is similar to the original (or 'Classic') ECN > >>>>>>> approach. > >>>>>>> 'Classic' ECN marking was required to be equivalent to a > >>>>>>> drop, both > >>>>>>> when applied in the network and when responded to by a > >>>>>>> transport. > >>>>>>> Unlike 'Classic' ECN marking, for packets carrying the L4S > >>>>>>> identifier, the network applies marking more immediately > >>>>>>> and more > >>>>>>> aggressively than drop, and the transport response to each > >>>>>>> mark is > >>>>>>> reduced and smoothed relative to that for drop. The two > >>>>>>> changes > >>>>>>> counterbalance each other so that the throughput of an L4S > >>>>>>> flow will > >>>>>>> be roughly the same as a non-L4S flow under the same > >>>>>>> conditions. > >>>>>>> Nonetheless, the much more frequent control signals and > >>>>>>> the finer > >>>>>>> responses to them result in much more fine-grained > >>>>>>> adjustments, so > >>>>>>> that ultra-low and consistently low queuing delay > >>>>>>> (typically sub- > >>>>>>> millisecond on average) becomes possible for L4S traffic > >>>>>>> without > >>>>>>> compromising link utilization. Thus even capacity-seeking > >>>>>>> (TCP-like) > >>>>>>> traffic can have high bandwidth and very low delay at the > >>>>>>> same time, > >>>>>>> even during periods of high traffic load. > >>>>>>> > >>>>>>> The L4S identifier defined in this document distinguishes > >>>>>>> L4S from > >>>>>>> 'Classic' (e.g. TCP-Reno-friendly) traffic. It gives an > >>>>>>> incremental > >>>>>>> migration path so that suitably modified network > >>>>>>> bottlenecks can > >>>>>>> distinguish and isolate existing traffic that still > >>>>>>> follows the > >>>>>>> Classic behaviour, to prevent it degrading the low queuing > >>>>>>> delay and > >>>>>>> low loss of L4S traffic. This specification defines the > >>>>>>> rules that > >>>>>>> L4S transports and network elements need to follow to > >>>>>>> ensure they > >>>>>>> neither harm each other's performance nor that of Classic > >>>>>>> traffic. > >>>>>>> Examples of new active queue management (AQM) marking > >>> algorithms > >>>>> and > >>>>>>> examples of new transports (whether TCP-like or real-time) > >>>>>>> are > >>>>>>> specified separately. > >>>>>>> > >>>>>>> > >>>>>>> The IETF datatracker status page for this draft is: > >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ > >>>>>>> > >>>>>>> There are also htmlized versions available at: > >>>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-13 > >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-i > >>>>>>> d-13 > >>>>>>> > >>>>>>> > >>>>>>> A diff from the previous version is available at: > >>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-13 > >>>>>>> > >>>>>>> > >>>>>>> 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. > >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>> > >>>>>>> > >>>>> -- > >>>>> > >>> > __________________________________________________________ > >>>>> ______ > >>>>> Bob Briscoe > >>> https://protect2.fireeye.com/v1/url?k=2a6f2e59- > >>>>> 75f4171a-2a6f6ec2-861fcb972bfc- > e28ad1342845f12e&q=1&e=417868d5- > >>>>> deeb-4c4f-9d1e- > debe95d3e33c&u=http%3A%2F%2Fbobbriscoe.net%2F > >>> -- > >>> > __________________________________________________________ > >>> ______ > >>> Bob Briscoe https://protect2.fireeye.com/v1/url?k=88a239c2- > >>> d73900a3-88a27959-86d8a30ca42b- > 6abcf6465bd4a19d&q=1&e=e8dae484- > >>> 35ef-4d79-b1ee-6fe94beff7ce&u=http%3A%2F%2Fbobbriscoe.net%2F > > > > -- > __________________________________________________________ > ______ > Bob Briscoe https://protect2.fireeye.com/v1/url?k=beec6770- > e1775e33-beec27eb-861fcb972bfc-cc8f2339192b7cc3&q=1&e=1a89d039- > 56b3-4ff5-acdf-759bba57d3b4&u=http%3A%2F%2Fbobbriscoe.net%2F
- [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-1… internet-drafts
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Rodney W. Grimes
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Tom Henderson
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Tom Henderson
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Rodney W. Grimes
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe