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, 5 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: =?utf-8?B?VHdKVzRRMEZkWkxSd0lWUGh6Y1hIVHFScElRakd4NGdURzY4b2VSSnhWS3Zi?= =?utf-8?B?K25TNUFIbGcxTVZNNjdQbndDZ3c1bWZsY2pxK1cxY21ER3RRZGpmYUJTN09a?= =?utf-8?B?RFhMbEFHL05CcTJGcGZlcUNEL3REQmdoUGw1Q3FNWHFnaW9rUS9sRUk4N1ZK?= =?utf-8?B?by93bzJaTDYyckk0OW1KU1BTelJsQjgwSnZlazBsZCtTVzM3QStlZFU2RHdj?= =?utf-8?B?MTlibVh6V1JSSGhoNzRYOTgzVzY4bnpvT1ozTE5PUTQrMnMvSWxkWTJQV2Rp?= =?utf-8?B?ei9nWE1nT3kzY204MlAvVld3U29qdWExN0NkM3J5Z0ZEN0x4NXBlb1VMSUUy?= =?utf-8?B?QTN1WEE1NG9jOWVCU3NiMzVSU28vYjF4Q3RKSXJnNWZHb2dPdTMyMnB2RDRB?= =?utf-8?B?K1BwcmNCSmdsKzU5WUZkcVdpWnNhanF3K29vb1hlTUJjUlFPYytPUHVSalJk?= =?utf-8?B?N0wxOHRMVVJEaFpuK1NIa255WkZsbkZLdUpYUWhuaEIwNjUxNGxaR3Fjb0p5?= =?utf-8?B?U1FUeU11c1lDbUdqU3ovTGd6ZktVTDJCT2xUYkhneHJ2VDVwSFhZbEh3Zjkr?= =?utf-8?B?bEVGU2lvNDRQOFJqYnlVUVpiUHV5T2wxRm9lT1JGUmZuMUN3WlIxOXgxOG9U?= =?utf-8?B?TzQwSW5OMjcvM01HeWUrRVRyckRrQTFCUjVqVktNT2ZDWXF3d2JxNkhZeWFG?= =?utf-8?B?bVFWNzhIUERPUTVLSk5hYnZ3aTBSL2dxcEcxRWhKOU9Hd1BJdW1VaU1Ld24w?= =?utf-8?B?bGJoOVkxZS8xZFRuemdlUGZXZnhsanJTNHQyOEVGSkIybjI2QkZTNzNjZ0tq?= =?utf-8?B?TXpvYjRrVDJXWFBmaWNhME5BR2QzOW4ranAveituNTAxSGdEQlhOa3AvSnFQ?= =?utf-8?B?OWx5a3ZaTDNWR1NnUk95QWtVVlBMQkZoNHYwcWdSV1J0aGdTc1UvbDN6L3Z1?= =?utf-8?B?aUtQREZGK1hEV3FSRWlCenc0OUFSVDI5VkpmUytVaHFTRUFtWVdKOFo2aHhP?= =?utf-8?B?NWo1eWJ4aElkWjV1VUNrRTB6NnlxK21wVmV0VXZoU2c3dzAxMjdaU2NIYnNr?= =?utf-8?B?cEkrWFNMb3A2YjJqUUZZbHRpZDlOaFpvVDUxUm0zTWwxMzNFT1FjREJhbDFa?= =?utf-8?B?QXRRZzdxdkV4M3hTK1EwTkR3N2NjZSt0UkkvNWRIMVNOayt5YmdYZUxNWDRY?= =?utf-8?B?UjR3K2ZVejZWWjViTEhYbWNKdzZIQlpSS0RDY0QzLzd3OVZ5VUxGWGdhVGxp?= =?utf-8?B?emNBZUt1VTBabnN3R0ZIbCtnckJIbng5eHhPeVhZckxVaERzSVUrWXRreWEx?= =?utf-8?B?Rml1OWsxMnlDY05DZnZlL0FVQ0ttM2VQUmI3NmpCM21LREFBSEF2TXdNSFRH?= =?utf-8?B?MDRDQitPblQwcTF2MU5RU3Rjc3V5VXpLcnpxa3I4Y1RwSk1KUGdFbWx5WW5y?= =?utf-8?B?WmV2c0xPQm5NWEU1Wmd3dUgrMU1Dc254cVp3cWdsNFNac2FqZWtiR0RDUE1y?= =?utf-8?B?VU5tYXM3VUdMUUxEdVZ2ZHhoSkRTNEN4SjdLbFFrOFhVaEpJTUgrWnFENXFm?= =?utf-8?B?SzBlQ3JkbENNbVVvUTd1ZTZmYS9GWlZXUmYyS2R5N3k5eHZTSjdRZEk4RnU4?= =?utf-8?B?TXZnM01WeDN1RWF6TjRoVnZuUmx0UW04b21tL3QzZ2NkV0xtK2ZNU0x2UHZ5?= =?utf-8?B?Y2NYUFdjUzBmeFhmWjdCRHpkQTYvakdjSEx5NGNTb2VjYmsrUElOS2oxcVpa?= =?utf-8?Q?po2suMkIRScolKaM63RpbpG/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>om>;
> 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>om>; Asad
> >>> Sajjad Ahmed <asadsa@ifi.uio.no>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>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