Re: [tsvwg] Prague requirements survey

Sebastian Moeller <moeller0@gmx.de> Sun, 18 April 2021 09:55 UTC

Return-Path: <moeller0@gmx.de>
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 DE1503A0CFF for <tsvwg@ietfa.amsl.com>; Sun, 18 Apr 2021 02:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level:
X-Spam-Status: No, score=-1.668 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, RCVD_IN_MSPIKE_H3=-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 DLiBRaPmHXfi for <tsvwg@ietfa.amsl.com>; Sun, 18 Apr 2021 02:55:04 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 7132A3A0CFE for <tsvwg@ietf.org>; Sun, 18 Apr 2021 02:55:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1618739697; bh=zytFXbmyUncNgdBrUqI6jyFJKh5c4OWBWfM1ud/gjB0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=RFE7bfbnEAIlyMni81Ia4Lb03ObWCXgQhGWuI/ViC5ynaTH+toarM95pl/ozYo8VT RrlXzjPB8jlQ5WM7tPXYrDW8y8JS+fZczv4k8DBkxmYV4hdHnakGpgjMNZdI/PlPdD MVp1lwXeEKyUbkAqbFw+xU+7XjeqDwLljtBqshXM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.42.229] ([77.6.14.20]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MhU9j-1m3qNu0Kwt-00ebsk; Sun, 18 Apr 2021 11:54:57 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <DB7101BA-839C-44E2-B76E-C04F7963B5E5@apple.com>
Date: Sun, 18 Apr 2021 11:54:55 +0200
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FA2FA12-7D72-4F3F-B4C0-8005175C3EBD@gmx.de>
References: <AM8PR07MB7476A907FDD0A49ADBD7CA7EB9BD0@AM8PR07MB7476.eurprd07.prod.outlook.com> <SN2PR00MB017475FC0E8C13754E531E17B6B69@SN2PR00MB0174.namprd00.prod.outlook.com> <AM8PR07MB7476FAE559719D241375A816B9B19@AM8PR07MB7476.eurprd07.prod.outlook.com> <HE1PR0701MB22999C8C05ECA3D995FA7FFEC28F9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <AM8PR07MB7476E0EB3FC368D3C69A5466B98F9@AM8PR07MB7476.eurprd07.prod.outlook.com> <DBBPR07MB7481E1026CDE30D494856F15B9989@DBBPR07MB7481.eurprd07.prod.outlook.com> <AM8PR07MB7476FAEF53518DBFE457AC62B9949@AM8PR07MB7476.eurprd07.prod.outlook.com> <AM8PR07MB747629F14C5AEC5B47F40F56B94C9@AM8PR07MB7476.eurprd07.prod.outlook.com> <92C476A6-3E60-498B-A088-EF24E4B077AC@gmx.de> <83EC2DB8-C42F-4B1D-80C0-F01C2D393A9F@apple.com> <BB1A6362-FB51-471A-BF50-18C882C303E5@gmx.de> <DB7101BA-839C-44E2-B76E-C04F7963B5E5@apple.com>
To: Vidhi Goel <vidhi_goel@apple.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:lW3u8PoVOIFE6I1muc/438+rqe0RQj3NRSHioKOoo9GiZ8b6y/u bWWcuXvHbwgpIuAGyy7CD1nEqIS7PKBspNE77GT46BOxQDbwXvp9M7X9B7IzT5lQ9glt4JS sCptSlE3Agb7Hwb5/b0V/WhfyrO2Fu6N2fv/Yi9hnJl7onveCJEaJeJ+PCNwKH0hRSLOZbR 1N91g54XUpf1eyKK3PY0A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Fem4pe3gMB0=:j06oD2gFvSImTjp167ZIqp hqMYEH9EemN+SkhdakDBOEOZMn5DsEzyv4v/euXDYnfUDF3wmXYprtGYhbLlFx/2+JA062ksk sEhDqIsJWsOR/bkBUkkWUCWH7ekWfYaxwN1pkwfemz8GjD/PlSw8+sCbgAE455r2Ytyx+OUXo E3iXwIyXBqWU4UJjsvReO1p0JF3jfrBvqjHJGILT+R4NOviaEpk4x0mUB0Bqwu/+j/ERbQoGA C7evrxC0Rg2yBKss1DGwD1DgmZo9Mb94jfhyXhOtpYFvkmb+4vrhMnhBSxm+xMUPp/G3VRjgp PL6IgDn1vfybpcK1XKPIKYRnbAyUzjR2wfeiEa7/4t2vnEbMQ5GFoI2I1NijP71OnivsTO7b1 wDaBb0l4N595on1eC8xkjBtRTeQYkNu5PfcbPG1G3NPbosBePjCT+tlQbiRMmNfhMsyYtToME a12MCb0wIizzZfW1oFOQ2iTTGdheOz6efXpNXkxfeqySZpDrWoHMnf8yIJWARbi2AbXw94Z1T sHhLnqaIa82wWcrBsszD8wftw8xCFhcwEz7iOQNGORkf/s8dDE3tvEQDfqXii8acxqeDnx/Bw qudJz7Z37iQaIAJxNnCBZ747MNwdF8kHi4kVGib+MlGW7Z/ORsvZR46tRdC9Bg8u3dFGrazK+ +IA+9xbcqW2TGQTAaH9gSSF3iJnQYKdFdx532kzDfODnie7bwau4pyeiFLKaDHifYC/gpf2vB 6++NHNRTDZO67OxNmQtJCV4O5Ph+D/m9Q966bpPqd2b1FJJPKEBtgg4/8iWFSEOAejF6YV32I Xr0LhSOK+wfR0siCqwTTpE7pqadfW7vNi3n0ebP6DkNekEWZb6HSe+1mhtbwhBha5IFtvJukE GP9ifDc5BwWUGZQkZW1Wv63IPptPw08bDx6FiZPsXQc6f+3AxM2UcFRFlnAGqtEpg2bB8NSji NxCO+5xcaBAvU+n3azoSv3ArXKNAU01Clg2kKMFjE9Ccz/ySFURfApaEPrwEy2dh7r15CkPeL Ai/KkRlWeTabY6JSCzd6fr33YoLQW/sQu0qKYGX1seQgo1lRvgeiu4PvvDKqTdFqpFoYRnOgY bS+5JFQ3M2JqT7xfhh7Vrc+jh63C/u50rDdatON94+suSkNi7po69MfnmhVVVSuk22E52QTTK Y6j09VmsgasXWzs7RlOvJsUgJ6Nm6Yy74xgI8F+RAPud5HZcjTPO7CNtVyzPynBqurCjUxghy w5ix4Tp/0avNi6g0NF6AdpFmAHdeUfz+J0DnTyapnbIuHWMv987vJPo6CZY+ZxNF+1nl9fr0x puj1WzS1yeVL/4AUKfbsS06pn4wtXg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/GlRtTmY4UQvjpanf_jjKywLz6gc>
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 <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: Sun, 18 Apr 2021 09:55:10 -0000

Hi Vidhi,

thank you for response.

Question: Does this discussion actually change your/apple position in regards to the TCP Prague requirements? (I assume not*, but it would be helpful to make that explicit for the sake of further discussions)


*) Because reducing RTT bias is a worthy goal and "playing dumb" as TCP Prague does is at least a theoretical viable way forward, albeit an IMHO unattractive one.


> On Apr 18, 2021, at 04:48, Vidhi Goel <vidhi_goel@apple.com> wrote:
> 
> Hi Sebastian,
> 
>>> I think the simple proposal in Linux (which you already know) is a good starting point. A
>> 
>> 	Are we talking about the same Linux proposal here ((https://github.com/L4STeam/linux/commit/a2ef76f8da1c9d1b13fa941f55607f3e60d4112e)? Where TCP Prague is instructed to basically behave like ("pretend") there was a fixed lower bound RTT when growing the congestion window? IMHO that is not a good starting point for fixing RTT-bias, given that that over the internet RTTs easily range from low single to low triple digit ms. Unless we are prepared to set, say 100 ms as our lower bound RTT this approach will not work for the internet, but once we do that we are giving up one of the advantages that high frequency congestion signaling is promising, faster reactions to congestion signals. 
>> 
>> 	I want to note that TCP Prague by default only tries to equalize RTTs up to 25 ms, which indicates that not even its developers consider it as a generic solution (or they believe that 25ms is a "magic" RTT on the internet). I also note that the root-cause for adding that feature to TCP Prague, was/is the fact that the dual queue coupled AQM failed to properly share capacity between its two queues at low RTTs. This failure is rationalized as being an effect of RTT-bias caused by the difference in queueing delay between the two queues (~1ms fir the LL queue, ~20ms for the classic queue) and the proposed solution is to make TCP Prague not grow its congestion window faster than a 25 ms RTT flow. In other words this is not meaningfully addressing RTT-bias, but is fixing a deficiency in L4S's reference AQM*.
> 
> Yes, we are talking about the same proposal.
> At the time I read the Linux Prague proposal, I didn’t realize the rationale behind it and now I understand it better with your reasoning. I agree that we should not fix RTT bias which is purely created by the L4S dual queue.

	[SM] +1; as a side note figure 6 (https://abload.de/img/thegoodthebadandthewinpjmx.png) of Høiland-Jørgensen, Toke, Per Hurtig, and Anna Brunstrom. ‘The Good, the Bad and the WiFi: Modern AQMs in a Residential Setting’. Computer Networks 89 (4 October 2015): 90–106. https://doi.org/10.1016/j.comnet.2015.07.014. (https://www.sciencedirect.com/science/article/pii/S1389128615002479) shows the RTT fairness of different bottleneck management solutions. L4S dual queue coupled AQM is not unusual in making RTT-unfairness worse than the reference FIFO (see the ared, pie, and codel columns), but IMHO it does so even stronger than the traditional AQMs. Also note how AQMs can actually do equal or better than FIFO (sfq and fq_codel, as well as the pure FQ scheduler without AQM, fq_nocodel).
	In other words there are AQMs that can ameliorate RTT-bias, it is just that L4S's dual queue coupled AQM is not among them.
All of this is in addition to the fact that the dual queue coupled AQM at its core is a stricht 1:16 (classic:L4S) scheduler where the unfairness between the two queues is only limited to 1:16, with a bunch of clever heuristics to not cause this situation all too often. But it was clear from the beginning, that extremely shoer RTTs would not be covered by those heuristics. And instead of say fixing the issue by mandating a less extreme priority split (say 1:4) L4S opted to mandate protocols to fix up the short comings of the AQM.


> 
>>> s a community, we might come up with more heuristics / tunable parameters to handle edge cases.
>> 
>> 	Sorry, for the last decades people have worked on RTT-bias and no generic solution based solely on end-point actions has been found. I am not saying that this is impossible, but it it is quite unlikely that this is easy enough for the community to come up with a solution. And TCP Pragure is IMHO not a promising contender for a generic solution.
>> 	IMHO, the problem is that the issue is not caused by the endpoints in the first place, but by the interaction of control loops of different "fidelity"/reaction times in bottleneck buffers. This can easily be seen in that a properly configured TCP flow can approach bottleneck capacity when run as the sole flow over a bottleneck, but will be suppressed if competing with TCP flows of shorter RTT in the same bottleneck. It hence seems clear that management of the bottleneck is at least as important to counter RTT-bias as the endpoints's control loops. The L4S approach of relegating the issue solely to the endpoints/protocols to fix, instead of also making the AQM part of the solution strikes me as short-sighted especially in the light of deployment of an AQM being one of the core pillars of the L4S design.
> The problem of RTT-unfairness arises from different ACK clocking speeds based on RTT. If the propagation delay is different for two flows, then there is nothing that AQM can do.

	[SM] That is essentially what I tried to call "reaction time" above, but also see the examples referenced above showing how AQM can actually do something to make things better. Really, since the problem occurs by the interaction in the bottlenecks buffers an AQM is in a very good position to help, and that even without requiring cooperation of protocols! As a further example how AQM can actually help, have a look at https://camo.githubusercontent.com/0ca81a2fabe48e8fce0f98f8b8347c79d27340684fe0791a3ee6685cf4cdb02e/687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d6368617274732f727474666169725f63635f71646973635f31306d735f3136306d732e737667 the last 4 pairs of bars show an approximate fairness AQM in action, compare that to the first 4 pairs, with the dual queue coupled AQM. The L4S solution is clearly deficient compared to the state of the art, heck if you compare the pair 1 (2 cubic flows in L4S classic queue) and pair 5 (2 cubic flows in a FIFO) you see that L4S' AQM is considerably worse than the status quo in the internet the unmanaged FIFO.
	The same plot also shows why TCP Prague is not ready for internet scale deployment, as it fares quite badly if it has to compete with CUBIC in a bottleneck (pairs 6 and 7).


> OTOH, if the propagation delay is same for two flows, and it is really the buffering (queuing) delay that is causing RTT unfairness, then I agree with you that we should solve this problem at the bottleneck.

	[SM] Yes! Cleaning up an AQM's mess should be made a burden for protocols.


> I believe you are concerned about the latter scenario and yes in this case, we should not try to solve the RTT bias at the endpoint as that could be counter productive to what we are trying to achieve with scalable congestion controllers.

	[SM] Exactly. BTW, I agree that making protocols less RTT-unfair is a worthy goal we should strive for, but it is not an easy problem to solve (judged by how long we know about RTT-bias and how little progress we made so far in tackling it in protocols).

Best Regards
	Sebastian


> 
> Thanks,
> Vidhi
> 
>> On Apr 16, 2021, at 3:45 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> Hi Vidhi,
>> 
>> 
>>> On Apr 16, 2021, at 23:21, Vidhi Goel <vidhi_goel@apple.com> wrote:
>>> 
>>> Hi Sebastian,
>>> 
>>>> 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.
>>> 
>>> I think the simple proposal in Linux (which you already know) is a good starting point. A
>> 
>> 	Are we talking about the same Linux proposal here ((https://github.com/L4STeam/linux/commit/a2ef76f8da1c9d1b13fa941f55607f3e60d4112e)? Where TCP Prague is instructed to basically behave like ("pretend") there was a fixed lower bound RTT when growing the congestion window? IMHO that is not a good starting point for fixing RTT-bias, given that that over the internet RTTs easily range from low single to low triple digit ms. Unless we are prepared to set, say 100 ms as our lower bound RTT this approach will not work for the internet, but once we do that we are giving up one of the advantages that high frequency congestion signaling is promising, faster reactions to congestion signals. 
>> 
>> 	I want to note that TCP Prague by default only tries to equalize RTTs up to 25 ms, which indicates that not even its developers consider it as a generic solution (or they believe that 25ms is a "magic" RTT on the internet). I also note that the root-cause for adding that feature to TCP Prague, was/is the fact that the dual queue coupled AQM failed to properly share capacity between its two queues at low RTTs. This failure is rationalized as being an effect of RTT-bias caused by the difference in queueing delay between the two queues (~1ms fir the LL queue, ~20ms for the classic queue) and the proposed solution is to make TCP Prague not grow its congestion window faster than a 25 ms RTT flow. In other words this is not meaningfully addressing RTT-bias, but is fixing a deficiency in L4S's reference AQM*.
>> 
>>> s a community, we might come up with more heuristics / tunable parameters to handle edge cases.
>> 
>> 	Sorry, for the last decades people have worked on RTT-bias and no generic solution based solely on end-point actions has been found. I am not saying that this is impossible, but it it is quite unlikely that this is easy enough for the community to come up with a solution. And TCP Pragure is IMHO not a promising contender for a generic solution.
>> 	IMHO, the problem is that the issue is not caused by the endpoints in the first place, but by the interaction of control loops of different "fidelity"/reaction times in bottleneck buffers. This can easily be seen in that a properly configured TCP flow can approach bottleneck capacity when run as the sole flow over a bottleneck, but will be suppressed if competing with TCP flows of shorter RTT in the same bottleneck. It hence seems clear that management of the bottleneck is at least as important to counter RTT-bias as the endpoints's control loops. The L4S approach of relegating the issue solely to the endpoints/protocols to fix, instead of also making the AQM part of the solution strikes me as short-sighted especially in the light of deployment of an AQM being one of the core pillars of the L4S design.
>> 
>>> https://l4steam.github.io/PragueReqs/Linux_TCP_Prague_L4S_requirements_Compliance_and_Objections.pdf
>> 
>> Best Regards
>> 	Sebastian
>> 
>> *) And doing so before actual deployment, at a point in time when that AQM could actually still be fixed for good.
>> 
>> 
>>> 
>>> Thanks,
>>> Vidhi
>>> 
>>>> On Apr 16, 2021, at 7:16 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>> 
>>>> 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:<page1image4260772480.png>		
>>>> 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-requirements-compliance).
>>>>> 
>>>>> I believe it is strongly in line with the previous survey 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 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: “a 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”. 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) <koen.de_schepper@nokia-bell-labs.com>om>; 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 “MUST document” 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’t 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>om>; 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 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 reasonable, valid and feasible?
>>>>> 
>>>>> Interesting observation (related to the performance optimization topic 1) that 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 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>om>; 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/master/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_Compliance_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.
>>>> 
>>> 
>> 
>