From nobody Fri Apr 16 05:53:06 2021 Return-Path: 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 6DDBF3A24B0 for ; Fri, 16 Apr 2021 05:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=nokia.onmicrosoft.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 PFevmRi2fboe for ; Fri, 16 Apr 2021 05:53:00 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20120.outbound.protection.outlook.com [40.107.2.120]) (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 F27643A24A5 for ; Fri, 16 Apr 2021 05:52:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PGpoKcTENc5dbxbq/8NAIZlLX83c2b0hipKo3t7550nEiXDKmL+SliozHKWX4GiP59MdF1ft+nKK/l4A/dBOvjFMvu8wKmsi7uaglBJT683aZtu+/LAiYtNe6pDZavn1YYgdysODdXLYT0prErElRJRHrneMdaVl9wCKHYvD0CKnO92gvNPsfmb7Nhzkwo1kH2oWmBFAmhqsRA+qeXkQZkZD6rW1K4pmZryDyz8WvYT+OO+CXPP9iMj0Ny+ZnnBWZrpAWInZCHMZ8E6Zue4iPz9Z99WU7QNJw9eXvyFHOhBg1hN1UHiNubydiKK4tlpU+/75TYx/xjGVNSwnydmAsQ== 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=ERxDVMrUmzyNFAAPeJZl6/Z19i72bT61iWia/Tu5jJ4=; b=I/BR26ZsC7+rrmKc5tSYjAnWOXwfluYMSP66m+DRTtRw25J+u0bie6KmXgq60iiyJwO0Z3701ZdPSQ0IgaNDrAFdypugByGl/HjZxlu5HFms5gWTtinbuEDsHJUiQsydz4wJeAfpKBJM5+luu597W88UeYCrOcjoBm9zveksQd8ahkkEMIm+XW3vAJYRlg4/+ZG5tHgGPKEA55bn6FGSXVcT0mLtECFL11VVTs5Qr4QOU1Rg342KXfbeXWSQZSoAvj6CeVwS2AwGTP4xyNwTmM0NxC5jae+sYQd8rebxPz2Q7RSJDr2t848RlYHBxmWX2eXqzFd1ZWdpYuUPvEPjfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ERxDVMrUmzyNFAAPeJZl6/Z19i72bT61iWia/Tu5jJ4=; b=JJnFdJpJIUND56mXBLwizxuRxGaW10mh/Sx1UYqkGTUlxRkqQwgyRJxUv75+hZH/9dreJVzRQYM/VJM1IIXCBqTBxWGeiNFyUSBYAr1wUvB9wkPSHtEqXolHYMJIzr74PY109dFz6h7aKY0ol1v1POgQALanCCK9LwMfjG8sdd0= Received: from AM8PR07MB7476.eurprd07.prod.outlook.com (2603:10a6:20b:24e::12) by AM0PR07MB4002.eurprd07.prod.outlook.com (2603:10a6:208:4c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Fri, 16 Apr 2021 12:52:55 +0000 Received: from AM8PR07MB7476.eurprd07.prod.outlook.com ([fe80::cc5e:1d65:1335:28d3]) by AM8PR07MB7476.eurprd07.prod.outlook.com ([fe80::cc5e:1d65:1335:28d3%5]) with mapi id 15.20.4065.007; Fri, 16 Apr 2021 12:52:55 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: tsvwg IETF list Thread-Topic: Prague requirements survey Thread-Index: AdbzPLYWoHtOCowHQ0uox2aN7ECzHgE/jRFAASKPXuAATuD/IAAGkG8ABHzn8YAAtrJEsAfOm5tA Date: Fri, 16 Apr 2021 12:52:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-02-01T01:38:17Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=54641ce9-3271-496d-b179-8f55632b25ef; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [2a02:1810:1e00:cb00:3d56:c83c:407f:4707] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 364de47e-0dab-4dfc-714d-08d900d68e3e x-ms-traffictypediagnostic: AM0PR07MB4002: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K2M7UVedxAmZ5wcJVJKCNC4wW2YEGlfXjP9Ndo1zYA4lNivq6vZA4cSvpwL9SyH7bW+qyUrtbihPofJKh9bTuXFj13gC2EPv57nMoWCm/1TY3gQH61MvJiHA+bILLiNvQJPW1VutGxGWtnpR0ztfG5eOQ+nXwOHDuFXBwgRZcMfcpWZ7A6IHm52wtyWEjAM2UUDy8hNxIm2+bbm4/KjshhDKvImP47SGer3/AV7zw/A+OjaPGry7GUZk3FiWRPlRuaqA7CyVluPhFXcOX+lH49vN8LaRE0zhja6VTJqCDHKGqicj3yxJzG4MjL3GnWOKuQoiJj2BRJ4QrMk5L+wxlRpQ5iyovJe+jlNVPyUjljbmGVY05EX8oO+D6zaDSXwOSPRka30AuNLBpGaRJSAh6SiXO6zdSs2/IC5QVlFSdvWHw/m/LrDa/OKIpJtA+q/EHL0+9S5Eaou0lgezTMp8bS4H6tZW9hz629mg5eeaxJjmW9A5GV1SoAtu7pHuxjAtax+CTHqVmTvWuLevUXkACwx43Y5l/bLArdA4G+fN583v/d5bDi/mMl+tzZMiRyBmrw+FOkqAWV+1/awIp7hlbHi8WKX0tf6bWW16jVgprGc4wEVvQOpBbQ+BkNhIcC3mWDm4TcOJ2khktEEcNA/HbOUCgjS38fu6bn/jzlPhc68= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB7476.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(122000001)(8936002)(7116003)(966005)(8676002)(83380400001)(5660300002)(38100700002)(64756008)(2906002)(66556008)(66476007)(478600001)(6916009)(9686003)(186003)(52536014)(66446008)(3480700007)(76116006)(6506007)(7696005)(166002)(55016002)(33656002)(86362001)(71200400001)(316002)(4326008)(53546011)(54906003)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?tgUxcd+h7r+gv23M8ZEY1snoYPCGUY9U2dxfYRFYcGo8Zq4RGXASf438aCTE?= =?us-ascii?Q?0oDE2CTkBdrwNztRfpYiRk5wv+YZJU7poxpu+bCoGWv7un/8WprO/mOsGUmL?= =?us-ascii?Q?Dn4GlMOLeDLlAWgxbwhHrv3HbHRka2wnOfgkSayqaGKM/RAH0czJnjJpQYux?= =?us-ascii?Q?BAj3r8nFOGG0iqU5YFo1/QjNYW7DTqJh6tLA92PCf15ICQ4hD66xnbK3aYMG?= =?us-ascii?Q?BDm4uA2XiiT6zbGR0r4fTFt3kn+l1zwMNrldFMYU00jT1tn+ZQhu99j7xkaE?= =?us-ascii?Q?SX8RHbe5P2InuZAzC21TV2NbHz0M7ajrqsftlrMGf+Qa/p+naytCY4VElFhS?= =?us-ascii?Q?y50mOaHE9NI6HVxgcx31Yt31Z7Rkp822zWHgOxj+xfxBen19YmIfprnxr2RB?= =?us-ascii?Q?DxXjGsngzgN93Zfm3134x7BJ9Xya7La5kPIcPapC1dunMeA6EK+qo/ah9VCy?= =?us-ascii?Q?gbXJCAeLJy1IAixfejEkJ5ihOww5YR8nlV/5oBNDRjF9VKqT9aQ8ia+ofAOP?= =?us-ascii?Q?fhRYl77nBQfBOZs1EgsYRRcRoQC9zuE/c95GmcJbZB0JAcMFs0zN36blkbr5?= =?us-ascii?Q?IDvYay4/zN5ykQ9J5V3+6z8ENEPMTF+7rlOGQobqijvi8cZvcymyQTqFp/J9?= =?us-ascii?Q?jm2M7QxIBdddsinol/gH+8gVcypuPyt+Y5YfH5LKxX0tUN2FiycFGdNWDSek?= =?us-ascii?Q?YwpN8oBEbLcPFPFyC24V08Yl6Mwj5fG8BuHFzp2SFfcZipi5/gpsYa3Eb9Tf?= =?us-ascii?Q?Rb1wro8hVBJxZlErbhrHl6LNkOF9pkteE+UHpzpeaSlZ1r5HZgoO+SwQakE+?= =?us-ascii?Q?P3R3iq8ziRFlJbOTYfAa0oqbm3w27+7cw+oS+s2UkqquPOW1xGE8Goi31m+M?= =?us-ascii?Q?Yk2G5TAJD0BQ5CeL4ySQrDADmuzp9o8dsWrG3IsJa/RVcCQkfxue3pDnjS0j?= =?us-ascii?Q?66rfjGisOtkgf0AI/rqMq3bMxRNOheP7NoQ/nuZDt3k90aRrK6oHdt5FugIR?= =?us-ascii?Q?FpBl6J1Cw98bXYZe2QGqHh+IDIgRAF1e4gpW6+8na7Wsb5Qc5tEQ0UIleimP?= =?us-ascii?Q?ttHJFwq+I0qPwDZhbBCjWnGCZyDtBptr1G4f4h/tGcYtZpv2gnDcmCinEJz8?= =?us-ascii?Q?snjdwnRGGZeSw83ZvI2K3bSDz/rgWDzriiCdkLB6OyPsD5sVh3NynVWxst73?= =?us-ascii?Q?hq4Kra2zHnSy9qp52x0VH5w/CFVUW+KGdn6rGNBjPYwuOBwpdvW0hB/3xZRi?= =?us-ascii?Q?prSpVPkVQ+8TmTgqRu9sAWXkE+PM7u4Us3b9QetSX9KQyRzusYQMFPsHRpNS?= =?us-ascii?Q?Kn6LH8nDh5y9T2azTQSkxa/GGfpY2erJiWE2L9HD95MzysmzPsPsjqDtwN14?= =?us-ascii?Q?bdKsCeB8a3LM3UEp7o8EJNSVH89Y?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8PR07MB747629F14C5AEC5B47F40F56B94C9AM8PR07MB7476eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7476.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 364de47e-0dab-4dfc-714d-08d900d68e3e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 12:52:55.8626 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CaWuqlukBwebo+ObdRRjLPD5civOz06hT9z5cxtHEobU4R47aMqdma+aifldfhmlJ0V1StXFyn+cGw0wVNYWx/wE63PxDemS4j8S2WfWB/ULo4exwJfpTUWEn8M9vlBC X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4002 Archived-At: Subject: Re: [tsvwg] Prague requirements survey X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 12:53:06 -0000 --_000_AM8PR07MB747629F14C5AEC5B47F40F56B94C9AM8PR07MB7476eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, An update on the survey is available. We received an additional input from = Apple which we could publicly share (thanks Vidhi for providing this input)= . I also updated the consolidated view v2 (available on https://github.com/= L4STeam/l4steam.github.io#prague-requirements-compliance). I believe it is strongly in line with the previous survey conclusions as pr= esented in last tsvwg. One main additional feedback was on "7. Measuring Re= ordering Tolerance in Time Units". There was disagreement that using time o= nly and not packet count is a foolproof solution. As far as I understand th= e objection is to the current wording that a time based mechanism is the on= ly/sufficient way to assure this. The objective of this requirement is to allow a certain level of reordering= for L4S traffic (actually avoid delaying packets in the network to guarant= ee correct order of packet delivery). I personally could support wording th= at expresses the core of the requirement, and not limit the text to one mec= hanism, which would allow alternative/more robust implementations. The requ= irement could be expressed as something like: "a scalable congestion contro= l SHOULD be resilient to reordering over an (adaptive) (time?) interval, w= hich scales with / adapts to throughput, as opposed to counting only in (fi= xed) units of packets (as in the 3 DupACK rule of RFC 5681 TCP), which is n= ot scalable". Let's further discuss here on the list what could be for all = parties an acceptable wording. Thanks, Koen. From: De Schepper, Koen (Nokia - BE/Antwerp) Sent: Sunday, March 7, 2021 1:57 AM To: De Schepper, Koen (Nokia - BE/Antwerp) ; tsvwg IETF list Cc: Bob Briscoe Subject: RE: Prague requirements survey Hi all, The details of the consolidated view of all feedback received is available = and can be found via following link: https://l4steam.github.io/PragueReqs/P= rague_requirements_consolidated.pdf The only strong objections were against the "MUST document" requirements, w= hich will be removed from the next version of the draft. Some clarification= s were asked and (will be) added. For 2 requirements a big consensus was that they should be developed and ev= olved as needed during the experiment. All other requirements had already implementations and if not, were seen fe= asible/realizable and were planned to be implemented. We will present an overview during the meeting. Regards, Koen. From: tsvwg > On Beha= lf Of De Schepper, Koen (Nokia - BE/Antwerp) Sent: Wednesday, March 3, 2021 2:20 PM To: tsvwg IETF list > Subject: Re: [tsvwg] Prague requirements survey Hi all, We have received several surveys privately, for which I tried to get the ap= proval for sharing those on the overview page: l4steam.github.io | L4S-rela= ted experiments and companion website Thanks to NVIDIA for sharing their view and feedback for their GeforceNow c= ongestion control. Their feedback was added to the above overview about a w= eek ago. As we didn't get the explicit approval for the others, we will sha= re and present a consolidated view of all feedback received later and durin= g the meeting. Note: pdf versions are now also available on the above page for easier read= ing. Koen. From: tsvwg > On Beha= lf Of De Schepper, Koen (Nokia - BE/Antwerp) Sent: Monday, February 8, 2021 2:37 PM To: Ingemar Johansson S >; tsvwg IETF list > Subject: Re: [tsvwg] Prague requirements survey Hi Ingemar, Thanks for your contributions. I linked your doc to the https://l4steam.git= hub.io/#prague-requirements-compliance web page (and will do so for others)= . I didn't see any issues or objections mentioned to the current requirements= as specified in the draft. Does this mean you think they are all reasonabl= e, valid and feasible? Interesting observation (related to the performance optimization topic 1) t= hat for the control packets "RTCP is likely not using ECT(1)". Why is this = not likely? I assume this will impact the performance? Do we need to recomm= end the use of ECT(1) on RTCP packets in the draft? Thanks, Koen. From: Ingemar Johansson S > Sent: Monday, February 8, 2021 10:59 AM To: De Schepper, Koen (Nokia - BE/Antwerp) >; tsvwg IETF list > Cc: Ingemar Johansson S > Subject: RE: Prague requirements survey Hi Please find attached (hopefully) a Prague requirements survey applied to SC= ReAM (RFC8298 std + running code) Regards Ingemar From: tsvwg > On Beha= lf Of De Schepper, Koen (Nokia - BE/Antwerp) Sent: den 6 februari 2021 23:20 To: tsvwg IETF list > Subject: [tsvwg] Prague requirements survey Hi all, To get a better understanding on the level of consensus on the Prague requi= rements, we prepared an overview document listing the L4S-ID draft requirem= ents specific to the CC (wider Prague requirements), as a questionnaire tow= ards potential CC developers. If you are developing or have developed an L4= S congestion control, you can describe the status of your ongoing developme= nt in the second last column. If you cannot share status, or plan-to/would = implement an L4S CC, you can list what you would want to support (see feasi= ble). In the last column you can put any description/limitations/remarks/ex= planations related to evaluations, implementations and/or plans (will imple= ment or will not implement). Any expected or experienced issues and any obj= ections/disagreements to the requirement can be explained and colored appro= priately. The document can be found on following link: https://raw.githubusercontent.= com/L4STeam/l4steam.github.io/master/PragueReqs/Prague_requirements_Complia= nce_and_Objections_template.docx As an example I filled it for the Linux TCP-Prague implementation on follow= ing link: https://l4steam.github.io/PragueReqs/Prague_requirements_Complian= ce_and_Objections_Linux_TCP-Prague.docx Please send your filled document to the list (Not sure if an attachment wil= l work, so I assume you also need to store it somewhere and send a link to = it, or send to me directly). We hope to collect many answers, understanding the position of the differen= t (potential) implementers and come faster to consensus. Thanks, Koen. --_000_AM8PR07MB747629F14C5AEC5B47F40F56B94C9AM8PR07MB7476eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

An update on the survey is available. We received an= additional input from Apple which we could publicly share (thanks Vidhi fo= r providing this input). I also updated the consolidated view v2 (available= on https://github.com/L4STeam/l4steam.github.io#prague-requirements-compliance= ).

 

I believe it is strongly in line with the previous s= urvey conclusions as presented in last tsvwg. One main additional feedback = was on “7. Measuring Reordering Tolerance in Time Units”. There= was disagreement that using time only and not packet count is a foolproof solution. As far a= s I understand the objection is to the current wording that a time based me= chanism is the only/sufficient way to assure this.

 =

The objective of this re= quirement is to allow a certain level of reordering for L4S traffic (actual= ly avoid delaying packets in the network to guarantee correct order of pack= et delivery). I personally could support wording that expresses the core of the requirement, and not limit the text= to one mechanism, which would allow alternative/more robust implementation= s. The requirement could be expressed as something like: “a scalable = congestion control SHOULD  be resilient to reordering over an (adaptive) (time?) interval, which scales with / ada= pts to throughput, as opposed to counting only in (fixed) units of packets = (as in the 3 DupACK rule of RFC 5681 TCP), which is not scalable”. Le= t’s further discuss here on the list what could be for all parties an acceptable wording.

 =

Thanks,

Koen.

 

 

From: De Schepper, Koen (Nokia - BE/Antwerp) =
Sent: Sunday, March 7, 2021 1:57 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@noki= a-bell-labs.com>; tsvwg IETF list <tsvwg@ietf.org>
Cc: Bob Briscoe <ietf@bobbriscoe.net>
Subject: RE: Prague requirements survey

 

Hi all,

 

The details of the consolidated view of all feedback= received is available and can be found via following link: https://l4steam.github.io/PragueReqs/Prague_requirements_consolidated.pdf

 

The only strong objections were against the “M= UST document” requirements, which will be removed from the next versi= on of the draft. Some clarifications were asked and (will be) added.

For 2 requirements a big consensus was that they sho= uld be developed and evolved as needed during the experiment.

All other requirements had already implementations a= nd if not, were seen feasible/realizable and were planned to be implemented= .

 

We will present an overview during the meeting.=

 

Regards,

Koen.

 

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, March 3, 2021 2:20 PM
To: tsvwg IETF list <tsvwg@ietf= .org>
Subject: Re: [tsvwg] Prague requirements survey

 

Hi all,

 

We have received several surveys privately, for whic= h I tried to get the approval for sharing those on the overview page: l4ste= am.github.io | L4S-related experiments and companion website=

 

Thanks to NVIDIA for sharing their view and feedback= for their GeforceNow congestion control. Their feedback was added to the a= bove overview about a week ago. As we didn’t get the explicit approva= l for the others, we will share and present a consolidated view of all feedback received later and during the meeting.=

 

Note: pdf versions are now also available on the abo= ve page for easier reading.

 

Koen.

 

 

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Monday, February 8, 2021 2:37 PM
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; tsvwg IETF list <<= a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org>
Subject: Re: [tsvwg] Prague requirements survey

 

Hi Ingemar,

 

Thanks for your contributions. I linked your doc to = the https://l4steam.github.io/#prague-requirements-compliance web page (and= will do so for others).

 

I didn’t see any issues or objections mentione= d to the current requirements as specified in the draft. Does this mean you= think they are all reasonable, valid and feasible?

 

Interesting observation (related to the performance = optimization topic 1) that for the control packets “RTCP is likely no= t using ECT(1)”. Why is this not likely? I assume this will impact th= e performance? Do we need to recommend the use of ECT(1) on RTCP packets in the draft?

 

Thanks,

Koen.

 

From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com&g= t;
Sent: Monday, February 8, 2021 10:59 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com= >; tsvwg IETF list <tsvwg@ietf.org<= /a>>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: RE: Prague requirements survey

 

Hi

Please find attached (hopefully) a Prague requiremen= ts survey applied to SCReAM (RFC8298 std + running code)

 

Regards
Ingemar

 

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <tsvwg@ietf= .org>
Subject: [tsvwg] Prague requirements survey

 

Hi all,

 

To get a better understanding on the level of consen= sus on the Prague requirements, we prepared an overview document listing th= e L4S-ID draft requirements specific to the CC (wider Prague requirements),= as a questionnaire towards potential CC developers. If you are developing or have developed an L4S congestion c= ontrol, you can describe the status of your ongoing development in the seco= nd last column. If you cannot share status, or plan-to/would implement an L= 4S CC, you can list what you would want to support (see feasible). In the last column you can put any descrip= tion/limitations/remarks/explanations related to evaluations, implementatio= ns and/or plans (will implement or will not implement). Any expected or experienced issues and= any objections/disagreements to the requirement can be explained and= colored appropriately.

 

The document can be found on following link: https://raw.githubusercontent.com/L4STeam/l4steam.github.io/master/PragueRe= qs/Prague_requirements_Compliance_and_Objections_template.docx

 

As an example I filled it for the Linux TCP-Prague i= mplementation on following link: https://l4steam.github.io/PragueReqs/Prague_requirements_Compliance_and_Obj= ections_Linux_TCP-Prague.docx

 

Please send your filled document to the list (Not su= re if an attachment will work, so I assume you also need to store it somewh= ere and send a link to it, or send to me directly).

 

We hope to collect many answers, understanding the p= osition of the different (potential) implementers and come faster to consen= sus.

 

Thanks,

Koen.

--_000_AM8PR07MB747629F14C5AEC5B47F40F56B94C9AM8PR07MB7476eurp_--