Re: [tsvwg] Prague requirements survey

[Neal Cardwell <[e-mail]>]

On Fri, Apr 16, 2021 at 8:53 AM De Schepper, Koen (Nokia - BE/Antwerp) <
[e-mail]> 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 on
> https://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 for posting this, Koen and Vidhi.

Regarding Apple's Prague response that you posted:

https://l4steam.github.io/PragueReqs/Apple_L4S_requirements_Compliance_and_Objections.pdf

And specifically regarding the response about a reordering tolerance in
time units:

     Disagree that using time only and not packet count is a
     foolproof solution. What if the time threshold value cause
     slow recovery in case of an actual packet loss event? Would
     it be better to use either packet count or time threshold? We
     currently don't support RACK - so time based loss detection
     wouldn't be possible.

I would agree that detecting losses purely based on a time
threshold value can cause slower recovery in case of an actual
packet loss event. And this can be needless delay if the path
actually has no reordering.

But it may be worth noting that in RACK-TLP loss detection [
https://tools.ietf.org/html/rfc8985 ] if no reordering has been
observed on the connection then the loss detection mechanism will
trigger based on packet count (DupThresh=3 segments SACKed).
RACK-TLP only uses time-based triggering of recovery if
reordering has been observed on the connection. This strikes a
balance between quick loss recovery for paths with no reordering,
and reordering tolerance for paths with reordering. So in effect
RACK-TLP does use the approach urged above ("Would it be better
to use either packet count or time threshold?")

I agree it is worth clarifying in the Prague requirements whether
it is required that loss detection *always* be based on time
units, or whether it is acceptable to use an adaptive approach
like the RACK-TLP approach outlined above (as specified in
RFC8985 and implemented in Linux TCP).

IMHO Koen's suggested alternate text for this requirement is
quite good. Here is a spin on Koen's text that sounds good to me
and explicitly mentions that RACK/RFC8985 qualifies as meeting
this requirement:

     a scalable congestion control SHOULD be resilient to
     reordering over an adaptive time interval that scales with
     throughput and adapts to reordering (as in [RFC8985]), as
     opposed to counting only in fixed units of packets (as in
     the 3 DupACK rule of [RFC5681] and [RFC6675], which is not
     scalable)

best,
neal



> Thanks,
>
> Koen.
>
>
>
>
>
> *From:* De Schepper, Koen (Nokia - BE/Antwerp)
> *Sent:* Sunday, March 7, 2021 1:57 AM
> *To:* De Schepper, Koen (Nokia - BE/Antwerp) <
> [e-mail]>; tsvwg IETF list <[e-mail]>
> *Cc:* Bob Briscoe <[e-mail]>
> *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 <[e-mail]> *On Behalf Of *De Schepper, Koen
> (Nokia - BE/Antwerp)
> *Sent:* Wednesday, March 3, 2021 2:20 PM
> *To:* tsvwg IETF list <[e-mail]>
> *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
> <https://l4steam.github.io/#prague-requirements-compliance>
>
>
>
> 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 <[e-mail]> *On Behalf Of *De Schepper, Koen
> (Nokia - BE/Antwerp)
> *Sent:* Monday, February 8, 2021 2:37 PM
> *To:* Ingemar Johansson S <[e-mail]>; tsvwg IETF
> list <[e-mail]>
> *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 <[e-mail]>
> *Sent:* Monday, February 8, 2021 10:59 AM
> *To:* De Schepper, Koen (Nokia - BE/Antwerp) <
> [e-mail]>; tsvwg IETF list <[e-mail]>
> *Cc:* Ingemar Johansson S <[e-mail]>
> *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 <[e-mail]> *On Behalf Of *De Schepper, Koen
> (Nokia - BE/Antwerp)
> *Sent:* den 6 februari 2021 23:20
> *To:* tsvwg IETF list <[e-mail]>
> *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
> <https://protect2.fireeye.com/v1/url?k=d16bc960-8ef0f066-d16b89fb-86ee86bd5107-080c65bfd839440d&q=1&e=7dbb7494-67c3-4315-88a6-325f32e4e8b1&u=https%3A%2F%2Fraw.githubusercontent.com%2FL4STeam%2Fl4steam.github.io%2Fmaster%2FPragueReqs%2FPrague_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
> <https://protect2.fireeye.com/v1/url?k=f839c5f7-a7a2fcf1-f839856c-86ee86bd5107-29dabadc5d0e673d&q=1&e=7dbb7494-67c3-4315-88a6-325f32e4e8b1&u=https%3A%2F%2Fl4steam.github.io%2FPragueReqs%2FPrague_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.
>