Re: [tsvwg] Prague requirements survey

[Bob Briscoe <[e-mail]>]

Ingemar,

On 10/02/2021 09:09, Ingemar Johansson S wrote:
>
> Hi
>
> Please see inline
>
> /Ingemar
>
> *From:* De Schepper, Koen (Nokia - BE/Antwerp) 
> <[e-mail]>
> *Sent:* den 8 februari 2021 14:37
> *To:* Ingemar Johansson S <[e-mail]>; tsvwg 
> IETF list <[e-mail]>
> *Subject:* RE: Prague requirements survey
>
> Hi Ingemar,
>
> Thanks for your contributions. I linked your doc to the 
> https://l4steam.github.io/#prague-requirements-compliance 
> <https://protect2.fireeye.com/v1/url?k=ae271499-f1bc2db2-ae275402-866038973a15-a6d18987ee63d9e2&q=1&e=4b98878d-2d51-48b6-9518-92696e72501d&u=https%3A%2F%2Fl4steam.github.io%2F%23prague-requirements-compliance> 
> web page (and will do so for others).
>
> [IJ] OK, great!
>
> 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?
>
> [IJ] There is a slight possibility that I misunderstood parts of the 
> layout. Even though SCReAM is only partially compliant in many cases I 
> believe that requirements are reasonable.
>
> 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?
>
> [IJ] Upon first glance I don’t see that it is beneficial that RTCP 
> packets are ECT(1). But of course there is a possibility that RTCP 
> packets go into a queue with higher latency and that may affect 
> performance. So… perhaps it is reasonable that RTCP packets are ECT(1) 
> too, but these are then to be regarded as non queue building as it can 
> be hard to rate control RTCP.
>

[BB] My knowledge is outdated, but RTCP used to be rate controlled in 
multicast to prevent implosion (that was in the early days on shared 
multicast, not single source). Are you saying all rate control 
mechanisms have been removed? Is the problem that there's no feedback 
channel for congestion indications on feedback? In 2-way RTP at least, 
couldn't you infer the congestion of RTCP datagrams from the ECN on data 
running alongside it? Or might they be disjoint paths?

Incidentally, the attitude being taken to ECT on TCP Pure ACKs in AccECN 
is in the AccECN draft. Basically, the info is now there for Ack CC if 
needed, but no need to use it currently.


Bob

> Thanks,
>
> Koen.
>
> *From:* Ingemar Johansson S <[e-mail] 
> <mailto:[e-mail]>>
> *Sent:* Monday, February 8, 2021 10:59 AM
> *To:* De Schepper, Koen (Nokia - BE/Antwerp) 
> <[e-mail] 
> <mailto:[e-mail]>>; tsvwg IETF list 
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* Ingemar Johansson S <[e-mail] 
> <mailto:[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] <mailto:[e-mail]>> 
> *On Behalf Of *De Schepper, Koen (Nokia - BE/Antwerp)
> *Sent:* den 6 februari 2021 23:20
> *To:* tsvwg IETF list <[e-mail] <mailto:[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.
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/