Re: [tsvwg] Comments on draft-ietf-tsvwg-ecn-l4s-id-05

[Ingemar Johansson S <[e-mail]>]

Hi

 

Please see in line [IJ]

 

Regards

Ingemar

 

From: Bob Briscoe <[e-mail]> 
Sent: den 9 november 2018 11:40
To: Ingemar Johansson S <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments on draft-ietf-tsvwg-ecn-l4s-id-05

 

Ingemar,

Thank you for the rapid and thorough review. Inline...

On 09/11/2018 08:02, Ingemar Johansson S wrote:

Hi

 

I have read through draft-ietf-tsvwg-ecn-l4s-id-05 and here are a few comments: 

 

=================

Section 4.2:

 

QUIC : QUIC has ECN support from v1. This is described in https://tools.ietf.org/html/draft-ietf-quic-transport-16 , the implemented ECN counters in the draft supports L4S. As of today however only classic ECN handling is described in https://tools.ietf.org/html/draft-ietf-quic-recovery-16. 

 

RMCAT : The generic feedback format draft https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02 supports ECN marking that can be used with L4S. RFC8298 (SCReAM) currently only specifies classic ECN handling, but running code of SCReAM found at https://github.com/EricssonResearch/scream has a working L4S implementation.

 

In both examples above, L4S support is almost there, I am not however sure if that is good enough to be included in the L4S ID draft ?

[BB]: Reading the avtcore draft (which I wasn't aware of until now), it seems the intent is to update RFC6679 although it doesn't say that in the header block. What should I say in place of what I have said about RTP over UDP? I'm not sufficiently involved in avt / rmcat to know whether it's politically correct to say that the new avtcore draft deprecates RFC6679's approach, or should I refer to them both, or...?

[IJ] RFC6679 was devised when neither WebRTC, nor RMCAT was chartered, it is referred to in 3GPP Spec TS26.114 but besides this I don’t believe that it is used more widely. It is actually possible to create useful feedback for SCReAM using RFC6679 and other XR RTCP packets but the current AVT core draft is devised to make interoperability between different RMCAT congestion control algorithms (SCReAM, NADA…).


If you have the time to provide text, or an outline of text that would replace what I've said about 6679 that would help.

[IJ] OK, a first try, please feel free and edit all the Swedish grammar and spelling 😊

----------

RMCAT : A generic feedback format is currently being specified in AVTCORE WG (https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02). The feedback format specifies timestamp indications as well as a two bit ECN echo for each received RTP packet. The high detail in the feedback enables the use of the generic feedback for scalable congestion control. While the congestion control algorithms specify classic ECN based backoff, none of these currently specify L4S. However, a running code implementation of RFC8298 found at https://github.com/EricssonResearch/scream has an L4S mode.



 

--------


I'll certainly add QUIC feedback to the list as well - thank you for catching those two. 

[IJ] Great



It doesn't matter that their status is not solid yet - each item in the list is at a different level of maturity, and it just says what the current maturity is (so I will add an informational pointer to the L4S SCREAM code). I know RFCs are meant to be timeless, but Experimental RFCs are inherently not.

[IJ] OK






================

Section 4.3:

This one caught my attention “A scalable congestion control MUST react to ECN marking from a

      non-L4S but ECN-capable bottleneck in a way that will coexist with

      a TCP Reno congestion control [ <https://tools.ietf.org/html/rfc5681> RFC5681] (see  <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#appendix-A.1.4> Appendix A.1.4 for

      rationale).

After reading the appendix I do agree with the intention, it can however be a challenge to realize this but you have perhaps a solution to this problem already in the chirped CC ?. Also it is possible that BBR v2 may satisfy this requirement but sofar it is merely speculation.

[BB]: This is the only requirement I have not done any work on (yet). To be honest, I am hoping some other researcher will pick it up - too few of us are doing too much!




================

A.1.6.  Scaling down to fractional congestion windows

Perhaps a silly question. Can packet pacing be exploited for this purpose ? So instead of a sub MSS congestion window you set the pacing rate to a value lower than (MSS*8)/RTT ? The challenge is of course the proper calculation of the pacing rate.

[BB]: Indeed, pacing can be exploited. We have an initial implementation for TCP.
The main challenge was actually the 1 SMSS per RTT increase, which becomes larger than the halving once you get below cwnd = 2 * SMSS. We've currently solved that by making the additive increase into a variable proportional to lg(ssthresh), rather than constant. 

We've not integrated this into the ideas for RTT-independence yet, and still in the early stages of testing, but it seems to work stably.




 

================

 

Otherwise I don’t have any objections 

[BB] Thank you. This is exactly the sort of stuff that I was hoping your review would find. 




Bob




 

Regards

Ingemar Johansson

==================================

Ingemar Johansson  M.Sc. 

Master Researcher

 

Ericsson Research

Network Protocols & E2E Performance

Labratoriegränd 11

971 28, Luleå, Sweden

Phone [phone]

SMS/MMS [phone]

 <mailto:[e-mail]> [e-mail]

www.ericsson.com

 

      Things are never so bad they 

              can't be made worse

                 Humphrey Bogart

==================================

 

 

From: Bob Briscoe  <mailto:[e-mail]> <[e-mail]> 
Sent: den 8 november 2018 05:55
To: Ingemar Johansson S  <mailto:[e-mail]> <[e-mail]>
Subject: L4S Review from mobile and RMCAT viewpoint?

 

Ingemar,

Pref. before the end of Nov. could you review at least one of the L4S drafts, cc the [e-mail] <mailto:[e-mail]>  list? To check we're not precluding anything from an RMCAT or LTE viewpoint.
We've finished the text of all 3 L4S drafts, apart from a couple of very minor ToDo's so it's all stable now.

The chairs will be going to WGLC in Jan, or in mid-Dec if sufficient reviews already then.

*	at least the L4S Identifier draft <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id> , which gives amongst other things:

*	the prerequisites a transport must comply with before sending ECT(1) [thinking particularly from RMCAT and QUIC perspectives]
*	relation with other identifiers (e.g. Diffserv),

*	possibly also the DualQ AQM draft <https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled>  (focus on the short Functional and Management Requirements section, where all the MUSTs are) [from LTE implementation perspective]

Cheers, and thank you in advance


Bob

PS. The 3rd primary L4S draft going through now is the architecture, but others are reviewing that.







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





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