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

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

Hi

Regarding the relation between RFC6679 and avtcore-cc-feedback-message, I believe it is best to ask also Magnus and Colin for their opinion, my understanding is that avtcore-cc-feedback-message is not meant as an update to RFC6679, even though it can actually be interpreted as such, but I am open for the possibility that there are other opinions here.

 

Please see more inline below [IJ]

 

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

 

Ingemar,

Thank you for explaining this. More questions:

Q1. Is everything I have said about RFC6679 ECN negotiation (copied below) still correct. IOW, should I add your text at the end of mine, or should I delete any of mine?:

   RTP over UDP:  A prerequisite for scalable congestion control is for
      both (all) ends of one media-level hop to signal ECN support using
      the ecn-capable-rtp attribute [RFC6679 <https://tools.ietf.org/html/rfc6679> ].  Therefore, the presence
      of ECT(1) implies that both (all) ends of that hop support ECN.
      However, the converse does not apply, so each end of a media-level
      hop can independently choose not to use a scalable congestion
      control, even if both ends support ECN.



Q2. I would like to add that avtcore-cc-feedback-message is intended as a standards track update to RFC6679. Should I?

I am wary of saying this when it is not in the header block. However, it's a chartered standards track draft and the text below clearly says it is updates RFC6679:

   A number of RTCP eXtended Report (XR) blocks have previously been
   defined to report details of packet loss, arrival times [RFC3611 <https://tools.ietf.org/html/rfc3611> ],
   delay [RFC6843 <https://tools.ietf.org/html/rfc6843> ], and ECN marking [RFC6679 <https://tools.ietf.org/html/rfc6679> ].  It is possible to
   combine several such XR blocks to report the detailed loss, arrival
   time, and ECN marking marking information needed for effective
   sender-based congestion control.  However, the result has high
   overhead both in terms of bandwidth and complexity, due to the need
   to stack multiple reports.
 
   Considering these issues, we believe it appropriate to design a new
   RTCP feedback mechanism to convey information for sender based
   congestion control algorithms.  The new congestion control feedback
   RTCP packet described in Section 3 <https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02#section-3>  provides such a mechanism.


Q3. When you say the following:

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.

are you saying RFC8298 only specifies classic ECN feedback? Or are you now talking about the L4S sender setting ECT(1) and using scalable (L4S) congestion control? Or both?

[IJ] RFC8298 does only specify the behavior assuming classic ECN feedback (ECT(0) set). The running code has an additional L4S mode that implements a scalable reaction to congestion. It is possible that this can added to an updated RFC8298 when/if it is updated from experimental to standards track.


If you are solely talking about the sender behaviour here, I would rather move this to where we talk about setting the codepoint or the congestion control.



Bob




On 10/11/2018 21:29, Ingemar Johansson S wrote:

Hi

 

Please see in line [IJ]

 

Regards

Ingemar

 

From: Bob Briscoe  <mailto:[e-mail]> <[e-mail]> 
Sent: den 9 november 2018 11:40
To: Ingemar Johansson S  <mailto:[e-mail]> <[e-mail]>
Cc: [e-mail] <mailto:[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/





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