From nobody Fri Apr 16 07:16:31 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 B27B43A2793 for ; Fri, 16 Apr 2021 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mDtpPWacPFsh for ; Fri, 16 Apr 2021 07:16:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 7575F3A2792 for ; Fri, 16 Apr 2021 07:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1618582579; bh=1VUhfEnYwXQP9xcXjR4DDlqk2+YqiaGZopKM/Bpb3m8=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=kziccAKKyafvOyw8LU5BI2oRXZvKs+dOGB2AB8LRoKmqNH2oznxy9mXZkxhsUtwA0 wyAHoZOSu9/etCAZUJOelxLRYjPDOBcoqDuHvSSzslvEDdYYIG+x2rLtajHrd/vlEK IHU9sXF39U+me9S4rB1r1W4VSdmouKO5Cme6gess= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.250.105] ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MTiU3-1l5j020TGP-00U0xd; Fri, 16 Apr 2021 16:16:19 +0200 From: Sebastian Moeller Message-Id: <92C476A6-3E60-498B-A088-EF24E4B077AC@gmx.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_16D795CF-ED0F-4927-BC90-917D45455622" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 16 Apr 2021 16:16:17 +0200 In-Reply-To: Cc: tsvwg IETF list To: "De Schepper, Koen (Nokia - BE/Antwerp)" References: X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:zKwf4/bSARUGJioREoiZFBL9XxRN8S/y7EFKXZg6gif0qUFRISm mJvTCb7S1EhmBlXCh3RAfXJuXLGw+jW2WUYkmRwFRozic9tshbeLlHZfCzLJEik4d9V3GPd 3enBKKR7lggeAbwGGvesypcPJT+AWy/M3kUyvfLfa/06PkNC3LraaPRovkkzbhf9TI3QzDL yn4iodkf/HhWXhndcmMfw== X-UI-Out-Filterresults: notjunk:1;V03:K0:NTtGjPDb/Y8=:WWWvLaI49yKIiiuklgaOii GZQ5bnohpFnjNjJLnAEqWDrbf896xOPnaBANFLEE7afgLr3BqqpK6UnKZhHJzqEo/y/qgUWQb 90M5G7Of4OhrLxUX9hdUDIgiJ64cJMOGjIwPpoNr397tB4MeT4WxuC0pJoxBJ76ehrjIyxuFG TPTYLtPhBSZUSmRrlvlt6FV+uaK/S7R/YrVNedfMhauGD6B9Gli2mFxGmXrSKLy3ZPEffvev/ JHIIp86ZTudAETmuPciUxEm+GPAiZvM+4HN2h2szoiZRDHphjnOAULzaozkl00i7Tnm3wNEoW /y4nqWbgTIVOHpdSrCYv98MycpuMCVM3sZL97QgrA96kyxaBempU/fm7cFaXs4o2hbaAbgA3M orvQS+JMET3W38Et1ONrZJVUuTLCvplgps6q6zccE6oqMa/3Nc7WfGdmQHCff4xpR9I1v4RcQ lZjkBJri29PCn6HTkS3GyhOjZskoHgFJ0dFsFStrMm1sg0C7K2V2R8+RxfyUfQYA5KnZH99YQ 9RO0S9/2Xb92BznUtTwm4MHUneO6/1pYuQJm/NXo/fjdCPZJNyoXw4Nz9PCfCu+7G5caYMBj3 shyXHw2AZlbeZN4lz2+ap9Gsu+GoLxASsIVH0nd0ZpF26uL+zPdOOJZLQviByjcwJcEHAxTfM iARex3jA0XVUHU6C5Ku1BMgbAky1rD6iScHMdWm+J30E0DWdvbvRrerehSJRGYMligfu35XCq 5tPZu358iXmf2PKe5QwDh6k3gunL8Bv9t0NLiLrTv2UgFmkzjG79Y5BCfLGHaEm5q3npqmwac cpxqzttpyt4+cpwT7cB2s3D7wBPf+BoCNfMCwJSDxKCg41h/ByaONzceDJqkKAL3p8IAGp8rm 6q+NXp2l275vG1avPjYrTgSNrdV4+NO2N7Ffdy0Tr6bvI7wRYi/CD2hJUhkCAxgBbUo86gBvb sZ4KbTW0/KvFSDzgkHgDYERtukxRVuV5oq6GtyCESvaL6MQtCVm4rRNdcbbtJTI9cdSKYjT8P 8QZRfsJk+oXJNAUw2OPbQYbaBnCY8GVdCUFfQ4vmhendw6cg0xlFwttv5fAeKsny9SGpRY9DY 6fsGKP9GD3t2oiS6+mzmkgxAIFtInkCoYqflNtDrJQrNb7GFEhwMVmJ8u8XcUZjkQ//CRtRbj Vnqczdab9o/c5lffQFx4oeETgF0fhVe0A83nFcmno/VEV79pYXTNhi+pBZpUKfOPtOYHw= 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 14:16:29 -0000 --Apple-Mail=_16D795CF-ED0F-4927-BC90-917D45455622 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Koen, Thanks,. Here is a question for Apple though: "5. Reduce RTT dependence (A1.5) Section 4.3: A scalable congestion control MUST eliminate RTT bias as = much as possible in the range between the minimum likely RTT and typical = RTTs expected in the intended deployment scenario. Apple's comment: =09 Again, agreed with the rationale behind this and the MUST compliance. = This might be easy to implement as well based on heuristics but will = require thorough testing." If this is easy to implement, could you please propose a description of = such a solution to the mailing list please? As far as I can tell RT- = bias has been a topic of research for decades and still no general = solution has beed presented, so I am quite interested to learn more = about this comment. Even if the response is something like "for the = expected range of RTTs from 1ms to 20 ms" a solution like TCP Pragues, = pretend all RTTs are 20ms" I am quite interested in apple's thoughts. Best Regards Sebastian > On Apr 16, 2021, at 14:52, De Schepper, Koen (Nokia - BE/Antwerp) = wrote: >=20 > Hi all, > =20 > 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 = onhttps://github.com/L4STeam/l4steam.github.io#prague-requirements-complia= nce). > =20 > I believe it is strongly in line with the previous survey conclusions = as presented in last tsvwg. One main additional feedback was on =E2=80=9C7= . Measuring Reordering Tolerance in Time Units=E2=80=9D. There was = disagreement that using time only and not packet count is a foolproof = solution. As far as I understand the objection is to the current wording = that a time based mechanism is the only/sufficient way to assure this. > =20 > The objective of this requirement is to allow a certain level of = reordering for L4S traffic (actually avoid delaying packets in the = network to guarantee correct order of packet 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 implementations. The requirement could be expressed as something = like: =E2=80=9Ca scalable congestion control SHOULD be resilient to = reordering over an (adaptive) (time?) interval, which scales with / = adapts 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=E2=80=9D. Let=E2=80=99s further discuss here on the list what = could be for all parties an acceptable wording. > =20 > Thanks, > Koen. > =20 > =20 > From: De Schepper, Koen (Nokia - BE/Antwerp)=20 > 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 > =20 > Hi all, > =20 > 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 > =20 > The only strong objections were against the =E2=80=9CMUST document=E2=80= =9D requirements, which will be removed from the next version of the = draft. Some clarifications were asked and (will be) added. > For 2 requirements a big consensus was that they should be developed = and evolved as needed during the experiment. > All other requirements had already implementations and if not, were = seen feasible/realizable and were planned to be implemented. > =20 > We will present an overview during the meeting. > =20 > Regards, > Koen. > =20 > From: tsvwg On Behalf 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 > =20 > Hi all, > =20 > We have received several surveys privately, for which I tried to get = the approval for sharing those on the overview page: l4steam.github.io | = L4S-related experiments and companion website > =20 > Thanks to NVIDIA for sharing their view and feedback for their = GeforceNow congestion control. Their feedback was added to the above = overview about a week ago. As we didn=E2=80=99t get the explicit = approval for the others, we will share and present a consolidated view = of all feedback received later and during the meeting. > =20 > Note: pdf versions are now also available on the above page for easier = reading. > =20 > Koen. > =20 > =20 > From: tsvwg On Behalf 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 > =20 > Hi Ingemar, > =20 > 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). > =20 > I didn=E2=80=99t see any issues or objections mentioned to the current = requirements as specified in the draft. Does this mean you think they = are all reasonable, valid and feasible? > =20 > Interesting observation (related to the performance optimization topic = 1) that for the control packets =E2=80=9CRTCP is likely not using = ECT(1)=E2=80=9D. Why is this not likely? I assume this will impact the = performance? Do we need to recommend the use of ECT(1) on RTCP packets = in the draft? > =20 > Thanks, > Koen. > =20 > From: Ingemar Johansson S =20 > 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 > =20 > Hi > Please find attached (hopefully) a Prague requirements survey applied = to SCReAM (RFC8298 std + running code) > =20 > Regards > Ingemar > =20 > From: tsvwg On Behalf Of De Schepper, Koen = (Nokia - BE/Antwerp) > Sent: den 6 februari 2021 23:20 > To: tsvwg IETF list > Subject: [tsvwg] Prague requirements survey > =20 > Hi all, > =20 > To get a better understanding on the level of consensus on the Prague = requirements, we prepared an overview document listing the 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 control, you can describe the status of = your ongoing development 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 feasible). In the last column you can put any = description/limitations/remarks/explanations related to evaluations, = implementations 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. > =20 > The document can be found on following link: = https://raw.githubusercontent.com/L4STeam/l4steam.github.io/master/PragueR= eqs/Prague_requirements_Compliance_and_Objections_template.docx > =20 > As an example I filled it for the Linux TCP-Prague implementation on = following link: = https://l4steam.github.io/PragueReqs/Prague_requirements_Compliance_and_Ob= jections_Linux_TCP-Prague.docx > =20 > Please send your filled document to the list (Not sure if an = attachment will work, so I assume you also need to store it somewhere = and send a link to it, or send to me directly). > =20 > We hope to collect many answers, understanding the position of the = different (potential) implementers and come faster to consensus. > =20 > Thanks, > Koen. --Apple-Mail=_16D795CF-ED0F-4927-BC90-917D45455622 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_D19D6453-B875-4C1E-A2DF-53C90A727C64" --Apple-Mail=_D19D6453-B875-4C1E-A2DF-53C90A727C64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Koen,

Thanks,.

Here is a question for = Apple though:

"5. Reduce = RTT dependence (A1.5)
Section 4.3: A = scalable congestion control MUST eliminate RTT bias = as much as possible in the range between the minimum likely = RTT and typical RTTs expected in the intended deployment = scenario.
Apple's comment:3D"page1image4260772480" = =
Again, agreed with the rationale behind this = and the MUST compliance. This might be easy = to implement as well based on heuristics but will require = thorough testing."


If this is easy to = implement, could you please propose a description of such a solution to = the mailing list please? As far as I can tell RT- bias has been a topic = of research for decades and still no general solution has beed = presented, so I am quite interested to learn more about this comment. = Even if the response is something like "for the expected range of RTTs = from 1ms to 20 ms" a solution like TCP Pragues, pretend all RTTs are = 20ms" I am quite interested in apple's thoughts.

Best Regards
= Sebastian





On Apr = 16, 2021, at 14:52, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> wrote:

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 onhttps://github.com/L4STeam/l4steam.github.io#prague-requirement= s-compliance).
 
I believe it is = strongly in line with the previous survey conclusions as presented in = last tsvwg. One main additional feedback was on =E2=80=9C7. Measuring = Reordering Tolerance in Time Units=E2=80=9D. There was disagreement = that using time only and not packet count is a foolproof = solution. As far as I understand the objection is to the current = wording that a time based mechanism is the only/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 guarantee correct = order of packet 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 implementations. The requirement could be expressed as = something like: =E2=80=9Ca scalable congestion control SHOULD  be = resilient to reordering over an (adaptive) (time?) interval, which = scales with / adapts 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=E2=80=9D. Let=E2=80=99s 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@nokia-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_consol= idated.pdf
 
The only strong objections = were against the =E2=80=9CMUST document=E2=80=9D requirements, which = will be removed from the next version of the draft. Some clarifications = were asked and (will be) added.
For 2 requirements a = big consensus was that they should be developed and evolved as needed = during the experiment.
All other requirements had already = implementations and 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 which I tried = to get the approval for sharing those on the overview = page: l4steam.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 above overview about = a week ago. As we didn=E2=80=99t get the explicit approval 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 above 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 = <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 we= b page (and will do so for others).
 
I = didn=E2=80=99t see any issues or objections mentioned 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 =E2=80=9CRTCP is = likely not using ECT(1)=E2=80=9D. Why is this not likely? I assume this = will impact the 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> 
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>
Cc: Ingemar Johansson S = <ingemar.s.johansson@ericsson.com>
Subject: RE: = Prague requirements survey
 
Hi
Please find attached (hopefully) a Prague requirements 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 consensus on = the Prague requirements, we prepared an overview document listing the = 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 control, you can = describe the status of your ongoing development 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 feasible). In = the last column you can put any = description/limitations/remarks/explanations related to evaluations, = implementations 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/mas= ter/PragueReqs/Prague_requirements_Compliance_and_Objections_template.docx=
 
As an example I filled it for the = Linux TCP-Prague implementation on following = link: https://l4steam.github.io/PragueReqs/Prague_requirements_Compli= ance_and_Objections_Linux_TCP-Prague.docx
 
Please send your filled document to the list (Not sure if an = attachment will 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 different (potential) implementers and come faster to = consensus.
 
Thanks,
Koen.

= --Apple-Mail=_D19D6453-B875-4C1E-A2DF-53C90A727C64 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=page1image4260772480.png Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0666; name="page1image4260772480.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAACcAAAABCAYAAABdVrceAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAQ LwAAEC8BdXumlAAAABRJREFUCB1jZEk6UMUwCMGfe/+7AASLBQU44EUmAAAAAElFTkSuQmCC --Apple-Mail=_D19D6453-B875-4C1E-A2DF-53C90A727C64-- --Apple-Mail=_16D795CF-ED0F-4927-BC90-917D45455622--