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

[Bob Briscoe <[e-mail]>]

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 inSection 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?

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]>
> *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/screamhas 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
>
>           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:
>
>           o the prerequisites a transport must comply with before
>             sending ECT(1) [thinking particularly from RMCAT and QUIC
>             perspectives]
>           o 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 Briscoehttp://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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