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

[Colin Perkins <[e-mail]>]

Bob,

I don’t regard draft-ietf-avtcore-cc-feedback-message as a direct update to RFC 6679, since there’s a lot of material in RFC 6679 about signalling and testing path properties that isn’t in the draft. The draft could provide an alternative way of conveying ECN feedback, however. We need to clarify this in a future version of the draft.

Colin




> On 15 Nov 2018, at 15:07, Bob Briscoe <[e-mail]> wrote:
> 
> Magnus or Colin,
> 
> See my Q2 below, which Ingemar says one of you can answer better than he.
> 
> Bob
> 
> On 11/11/2018 20:28, Ingemar Johansson S wrote:
>> 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]> <mailto:[e-mail]> 
>> Sent: den 11 november 2018 02:13
>> To: Ingemar Johansson S <[e-mail]> <mailto:[e-mail]>
>> Cc: [e-mail] <mailto:[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 <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 <[e-mail]> <mailto:[e-mail]> 
>> Sent: den 9 november 2018 11:40
>> To: Ingemar Johansson S <[e-mail]> <mailto:[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 <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 <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 <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 <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 <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 <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 [RFC5681 <https://tools.ietf.org/html/rfc5681>] (see Appendix A.1.4 <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#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]
>> [e-mail] <mailto:[e-mail]>
>> www.ericsson.com <x-msg://6/www.ericsson.com>
>>  
>>       Things are never so bad they 
>>               can't be made worse
>>                  Humphrey Bogart
>> ==================================
>>  
>>  
>> From: Bob Briscoe <[e-mail]> <mailto:[e-mail]> 
>> Sent: den 8 november 2018 05:55
>> To: Ingemar Johansson S <[e-mail]> <mailto:[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/ <http://bobbriscoe.net/>
>> 
>> 
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>
>> 
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>


-- 
Colin Perkins
https://csperkins.org/