Re: [tsvwg] Prague requirements survey

[Bob Briscoe <[e-mail]>]

Ingemar, - see inline [BB2]

On 23/02/2021 08:45, Ingemar Johansson S wrote:
>
> Hi Bob
>
> Please see inline [IJ2]
>
> *From:* Bob Briscoe <[e-mail]>
> *Sent:* den 22 februari 2021 21:35
> *To:* Ingemar Johansson S <[e-mail]>; De 
> Schepper, Koen (Nokia - BE/Antwerp) 
> <[e-mail]>; tsvwg IETF list <[e-mail]>
> *Subject:* Re: [tsvwg] Prague requirements survey
>
> 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]>
>     <mailto:[e-mail]>
>     *Sent:* den 8 februari 2021 14:37
>     *To:* Ingemar Johansson S <[e-mail]>
>     <mailto:[e-mail]>; tsvwg IETF list
>     <[e-mail]> <mailto:[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?
>
> [IJ2] Yes. It would of course be possible to set ECT(1) on RTCP/UDP/IP 
> packets and determine how large share of these packets that are 
> marked. The problem is then that there is not (currently) any RTCP 
> feedback(on feedback) format to carry that information back to the 
> RTCP sender (==streaming client) to make some rate control of the RTCP 
> feedback possible.
> The RTCP bandwidth is indeed limited, the rule of thumb is that it 
> should be less than 5% of the RTP media bitrate scaled down by the 
> number of receivers. SCReAM is just one receiver and the RTCP bitrate 
> is roughly 2% of the medial bitrate.
>

[BB2] Maybe what I said above didn't make sense, so I'll try saying it a 
different way...
Imagine this bidirectional scenario where X and Y are sending r-t data 
to each other:

1a. X --RTP--> Y
1b. X <-RTCP-- Y
2a. X <--RTP-- Y
2b. X --RTCP-> Y

Why can't Y use the proportion of ECN on the arriving RTP stream (1a) to 
infer the likely ECN on RTCP stream 2b? and
Why can't X use the proportion of ECN on the arriving RTP stream (2a) to 
infer the likely ECN on RTCP stream 1b?
you
Then I thought maybe one can't be sure that 1a and 2b are actually 
traversing the same path.
Similarly for 1b and 2a.


Bob


>
> 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 Briscoehttp://bobbriscoe.net/  <https://protect2.fireeye.com/v1/url?k=9e93ec25-c108d525-9e93acbe-86fc6812c361-6ce26fbc5b7d3fe4&q=1&e=9dde995b-c278-4be1-a612-c70ef0067fc2&u=http%3A%2F%2Fbobbriscoe.net%2F>

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