[tsvwg] Prague requirements survey

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[tsvwg] Prague requirements survey

De Schepper, Koen (Nokia - BE/Antwerp)

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.

Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Ingemar Johansson S (LU/EAB)

Hi

Please find attached (hopefully) a Prague requirements survey applied to SCReAM (RFC8298 std + running code)

 

Regards
Ingemar

 

From: tsvwg <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <[hidden email]>
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.


Prague requirements Compliance and Objections Scream-20210208.docx (44K) Download Attachment
smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

De Schepper, Koen (Nokia - BE/Antwerp)

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

Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Ingemar Johansson S (LU/EAB)

Hi

Please see inline

/Ingemar

 

From: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>
Sent: den 8 februari 2021 14:37
To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
Subject: RE: 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).

[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.

 

Thanks,

Koen.

 

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


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Bob Briscoe-6
Ingemar,

On 10/02/2021 09:09, Ingemar Johansson S wrote:

Hi

Please see inline

/Ingemar

 

From: De Schepper, Koen (Nokia - BE/Antwerp) [hidden email]
Sent: den 8 februari 2021 14:37
To: Ingemar Johansson S [hidden email]; tsvwg IETF list [hidden email]
Subject: RE: 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).

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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Ingemar Johansson S (LU/EAB)

Hi Bob

Please see inline [IJ2]

 

From: Bob Briscoe <[hidden email]>
Sent: den 22 februari 2021 21:35
To: Ingemar Johansson S <[hidden email]>; De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
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) [hidden email]
Sent: den 8 februari 2021 14:37
To: Ingemar Johansson S [hidden email]; tsvwg IETF list [hidden email]
Subject: RE: 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).

[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.

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



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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Bob Briscoe-4
Ingemar, - see inline [BB2]

On 23/02/2021 08:45, Ingemar Johansson S wrote:

Hi Bob

Please see inline [IJ2]

 

From: Bob Briscoe [hidden email]
Sent: den 22 februari 2021 21:35
To: Ingemar Johansson S [hidden email]; De Schepper, Koen (Nokia - BE/Antwerp) [hidden email]; tsvwg IETF list [hidden email]
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) [hidden email]
Sent: den 8 februari 2021 14:37
To: Ingemar Johansson S [hidden email]; tsvwg IETF list [hidden email]
Subject: RE: 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).

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



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Ingemar Johansson S (LU/EAB)

Hi

 

Inline [IJ3]

/Ingemar

 

From: Bob Briscoe <[hidden email]>
Sent: den 23 februari 2021 17:50
To: Ingemar Johansson S <[hidden email]>; De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Subject: Re: [tsvwg] Prague requirements survey

 

Ingemar, - see inline [BB2]

On 23/02/2021 08:45, Ingemar Johansson S wrote:

Hi Bob

Please see inline [IJ2]

 

From: Bob Briscoe [hidden email]
Sent: den 22 februari 2021 21:35
To: Ingemar Johansson S [hidden email]; De Schepper, Koen (Nokia - BE/Antwerp) [hidden email]; tsvwg IETF list [hidden email]
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) [hidden email]
Sent: den 8 februari 2021 14:37
To: Ingemar Johansson S [hidden email]; tsvwg IETF list [hidden email]
Subject: RE: 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).

[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.

 

[IJ3] RTP and RTCP is quite likely to traverse the same path, the difference may of course be if RTP is L4S capable and RTCP is not, for this reason it can make sense to have RTCP L4S capable as well. And you are right, as they traverse the same path then the RTCP traffic is equally likely to become marked as the RTP traffic. The question I have is how one congestion control RTCP and if it is needed, it is after all a small fraction of the media bitrate. Currently there is no available mechanism for this in the IETF standards that cover RTCP (at least it is unknown to me).




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




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



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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Bob Briscoe-4
Ingemar,
inline [BB3]

On 24/02/2021 16:01, Ingemar Johansson S wrote:

Hi

 

Inline [IJ3]

/Ingemar

 

From: Bob Briscoe [hidden email]
Sent: den 23 februari 2021 17:50
To: Ingemar Johansson S [hidden email]; De Schepper, Koen (Nokia - BE/Antwerp) [hidden email]; tsvwg IETF list [hidden email]
Subject: Re: [tsvwg] Prague requirements survey

 

Ingemar, - see inline [BB2]

On 23/02/2021 08:45, Ingemar Johansson S wrote:

Hi Bob

Please see inline [IJ2]

 

From: Bob Briscoe [hidden email]
Sent: den 22 februari 2021 21:35
To: Ingemar Johansson S [hidden email]; De Schepper, Koen (Nokia - BE/Antwerp) [hidden email]; tsvwg IETF list [hidden email]
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) [hidden email]
Sent: den 8 februari 2021 14:37
To: Ingemar Johansson S [hidden email]; tsvwg IETF list [hidden email]
Subject: RE: 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).

[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.

 

[IJ3] RTP and RTCP is quite likely to traverse the same path, the difference may of course be if RTP is L4S capable and RTCP is not, for this reason it can make sense to have RTCP L4S capable as well. And you are right, as they traverse the same path then the RTCP traffic is equally likely to become marked as the RTP traffic. The question I have is how one congestion control RTCP and if it is needed, it is after all a small fraction of the media bitrate. Currently there is no available mechanism for this in the IETF standards that cover RTCP (at least it is unknown to me).


[BB3] This is OK then, isn't it? I think this means the media receiver can set ECT on RTCP packets, at least for 2-way media sessions. Because:
a) RTCP is a small fraction of the media bit-rate
b) the media receiver can tell if congestion rises
c) Even tho the media receiver currently has no code to regulate the RTCP stream, if congestion persists it will at least reduce its own parallel RTP stream even more to compensate.
d) There's always the fall-back that if RTCP congestion is not cleared, the queue will progress from ECN to drop and naturally thin out enough RTCP datagrams.

If RTCP congestion became a widespread problem in the future, code could be added to slow down the RTCP stream driven by congestion notifications in the parallel RTP media stream. Incremental deployment would be possible (I mean, the congestion info is already there, so each end could deploy unilaterally, without needing additional negotiation at session set up).


Bob

PS. Sry for delayed reply.





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




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



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

De Schepper, Koen (Nokia - BE/Antwerp)
In reply to this post by De Schepper, Koen (Nokia - BE/Antwerp)

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

Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Ingemar Johansson S (LU/EAB)
In reply to this post by Bob Briscoe-4

Hi

Please see below [IJ4]

 

/Ingemar

 

From: Bob Briscoe <[hidden email]>
Sent: den 2 mars 2021 12:04
To: Ingemar Johansson S <[hidden email]>; De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Subject: Re: [tsvwg] Prague requirements survey

 

Ingemar,
inline [BB3]

On 24/02/2021 16:01, Ingemar Johansson S wrote:

Hi

 

Inline [IJ3]

/Ingemar

 

From: Bob Briscoe [hidden email]
Sent: den 23 februari 2021 17:50
To: Ingemar Johansson S [hidden email]; De Schepper, Koen (Nokia - BE/Antwerp) [hidden email]; tsvwg IETF list [hidden email]
Subject: Re: [tsvwg] Prague requirements survey

 

Ingemar, - see inline [BB2]

On 23/02/2021 08:45, Ingemar Johansson S wrote:

Hi Bob

Please see inline [IJ2]

 

From: Bob Briscoe [hidden email]
Sent: den 22 februari 2021 21:35
To: Ingemar Johansson S [hidden email]; De Schepper, Koen (Nokia - BE/Antwerp) [hidden email]; tsvwg IETF list [hidden email]
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) [hidden email]
Sent: den 8 februari 2021 14:37
To: Ingemar Johansson S [hidden email]; tsvwg IETF list [hidden email]
Subject: RE: 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).

[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.

 

[IJ3] RTP and RTCP is quite likely to traverse the same path, the difference may of course be if RTP is L4S capable and RTCP is not, for this reason it can make sense to have RTCP L4S capable as well. And you are right, as they traverse the same path then the RTCP traffic is equally likely to become marked as the RTP traffic. The question I have is how one congestion control RTCP and if it is needed, it is after all a small fraction of the media bitrate. Currently there is no available mechanism for this in the IETF standards that cover RTCP (at least it is unknown to me).


[BB3] This is OK then, isn't it? I think this means the media receiver can set ECT on RTCP packets, at least for 2-way media sessions. Because:
a) RTCP is a small fraction of the media bit-rate
b) the media receiver can tell if congestion rises
c) Even tho the media receiver currently has no code to regulate the RTCP stream, if congestion persists it will at least reduce its own parallel RTP stream even more to compensate.
d) There's always the fall-back that if RTCP congestion is not cleared, the queue will progress from ECN to drop and naturally thin out enough RTCP datagrams.

If RTCP congestion became a widespread problem in the future, code could be added to slow down the RTCP stream driven by congestion notifications in the parallel RTP media stream. Incremental deployment would be possible (I mean, the congestion info is already there, so each end could deploy unilaterally, without needing additional negotiation at session set up).

 

[IJ4] Agree with the statements above. RTCP congestion should become a noticeable problem only for very asymmetric links, and there are possibly solutions for this, similar to the ACK rate negotiation in TCPM. But I guess one need to see evidence that it is really a problem .




Bob

PS. Sry for delayed reply.






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





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




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



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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

De Schepper, Koen (Nokia - BE/Antwerp)
In reply to this post by De Schepper, Koen (Nokia - BE/Antwerp)

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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, March 3, 2021 2:20 PM
To: tsvwg IETF list <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Monday, February 8, 2021 2:37 PM
To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
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 <[hidden email]>
Sent: Monday, February 8, 2021 10:59 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Ingemar Johansson S <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <[hidden email]>
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.

Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Bob Briscoe-4
Koen, tsvwg,

I had updated draft-ietf-tsvwg-ecn-l4s-id with the changes to the Prague Requirements from the more clear-cut results of this survey.
And I included the changes Ingemar suggested and Asad.

I was going to post it when the servers opened this morning.
But then I also updated it for Tom's comprehensive review over the last couple of days.
I've not seen Tom come back on anything.

So I'll post it now, then at least people have a fighting chance of reading the diffs if they want to before Wed's WG session.



Bob

On 07/03/2021 00:57, De Schepper, Koen (Nokia - BE/Antwerp) wrote:

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 [hidden email] On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, March 3, 2021 2:20 PM
To: tsvwg IETF list [hidden email]
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Monday, February 8, 2021 2:37 PM
To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
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 <[hidden email]>
Sent: Monday, February 8, 2021 10:59 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Ingemar Johansson S <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <[hidden email]>
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.


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

De Schepper, Koen (Nokia - BE/Antwerp)
In reply to this post by De Schepper, Koen (Nokia - BE/Antwerp)

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,

Koen.

 

 

From: De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Sunday, March 7, 2021 1:57 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Bob Briscoe <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, March 3, 2021 2:20 PM
To: tsvwg IETF list <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Monday, February 8, 2021 2:37 PM
To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
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 <[hidden email]>
Sent: Monday, February 8, 2021 10:59 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Ingemar Johansson S <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <[hidden email]>
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.

Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Neal Cardwell
On Fri, Apr 16, 2021 at 8:53 AM De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]> 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) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Bob Briscoe <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, March 3, 2021 2:20 PM
To: tsvwg IETF list <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Monday, February 8, 2021 2:37 PM
To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
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 <[hidden email]>
Sent: Monday, February 8, 2021 10:59 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Ingemar Johansson S <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <[hidden email]>
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.

Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Sebastian Moeller
In reply to this post by De Schepper, Koen (Nokia - BE/Antwerp)
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
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) <[hidden email]> 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) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Bob Briscoe <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, March 3, 2021 2:20 PM
To: tsvwg IETF list <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Monday, February 8, 2021 2:37 PM
To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
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 <[hidden email]
Sent: Monday, February 8, 2021 10:59 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Ingemar Johansson S <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <[hidden email]>
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.

Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Vidhi Goel
In reply to this post by Neal Cardwell
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)

Thanks Neal. This wording works for me.

On Apr 16, 2021, at 7:08 AM, Neal Cardwell <[hidden email]> wrote:

On Fri, Apr 16, 2021 at 8:53 AM De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]> 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) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Bob Briscoe <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, March 3, 2021 2:20 PM
To: tsvwg IETF list <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Monday, February 8, 2021 2:37 PM
To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
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 <[hidden email]> 
Sent: Monday, February 8, 2021 10:59 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Ingemar Johansson S <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <[hidden email]>
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.


Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Vidhi Goel
In reply to this post by Sebastian Moeller
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. As a community, we might come up with more heuristics / tunable parameters to handle edge cases.

Thanks,
Vidhi

On Apr 16, 2021, at 7:16 AM, Sebastian Moeller <[hidden email]> 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) <[hidden email]> 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) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Bob Briscoe <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, March 3, 2021 2:20 PM
To: tsvwg IETF list <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Monday, February 8, 2021 2:37 PM
To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
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 <[hidden email]
Sent: Monday, February 8, 2021 10:59 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
Cc: Ingemar Johansson S <[hidden email]>
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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: den 6 februari 2021 23:20
To: tsvwg IETF list <[hidden email]>
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.


Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Sebastian Moeller
Hi Vidhi,


> On Apr 16, 2021, at 23:21, Vidhi Goel <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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) <[hidden email]>; tsvwg IETF list <[hidden email]>
>>> Cc: Bob Briscoe <[hidden email]>
>>> 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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
>>> Sent: Wednesday, March 3, 2021 2:20 PM
>>> To: tsvwg IETF list <[hidden email]>
>>> 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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
>>> Sent: Monday, February 8, 2021 2:37 PM
>>> To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
>>> 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 <[hidden email]>
>>> Sent: Monday, February 8, 2021 10:59 AM
>>> To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
>>> Cc: Ingemar Johansson S <[hidden email]>
>>> 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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
>>> Sent: den 6 februari 2021 23:20
>>> To: tsvwg IETF list <[hidden email]>
>>> 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.
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [tsvwg] Prague requirements survey

Vidhi Goel
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.

>> 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. 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.

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.

Thanks,
Vidhi

> On Apr 16, 2021, at 3:45 PM, Sebastian Moeller <[hidden email]> wrote:
>
> Hi Vidhi,
>
>
>> On Apr 16, 2021, at 23:21, Vidhi Goel <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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) <[hidden email]>; tsvwg IETF list <[hidden email]>
>>>> Cc: Bob Briscoe <[hidden email]>
>>>> 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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
>>>> Sent: Wednesday, March 3, 2021 2:20 PM
>>>> To: tsvwg IETF list <[hidden email]>
>>>> 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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
>>>> Sent: Monday, February 8, 2021 2:37 PM
>>>> To: Ingemar Johansson S <[hidden email]>; tsvwg IETF list <[hidden email]>
>>>> 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 <[hidden email]>
>>>> Sent: Monday, February 8, 2021 10:59 AM
>>>> To: De Schepper, Koen (Nokia - BE/Antwerp) <[hidden email]>; tsvwg IETF list <[hidden email]>
>>>> Cc: Ingemar Johansson S <[hidden email]>
>>>> 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 <[hidden email]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
>>>> Sent: den 6 februari 2021 23:20
>>>> To: tsvwg IETF list <[hidden email]>
>>>> 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.
>>>
>>
>

12