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

[Bob Briscoe <[e-mail]>]

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]>
> *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 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?
>
> [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 , 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 Briscoehttp://bobbriscoe.net/

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