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

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 9 Nov 2018 08:02:04 +0000

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 ?

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

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.

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

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.

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

Otherwise I don’t have any objections 

Regards

Ingemar Johansson

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

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson Research

Network Protocols & E2E Performance

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 <mailto:[email-masked]> [email-masked]

www.ericsson.com

      Things are never so bad they 

              can't be made worse

                 Humphrey Bogart

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

From: Bob Briscoe <[email-masked]> 
Sent: den 8 november 2018 05:55
To: Ingemar Johansson S <[email-masked]>
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 [email-masked] <mailto:[email-masked]>  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/

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 9 Nov 2018 10:40:16 +0000

Ingemar,

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

On 09/11/2018 08:02, Ingemar Johansson S wrote:
> 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...?

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.

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

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.

>       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!

> 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.

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

Bob

> [email-masked] <mailto:[email-masked]>
>
> www.ericsson.com
>
> *From:*Bob Briscoe <[email-masked]>
> *Sent:* den 8 november 2018 05:55
> *To:* Ingemar Johansson S <[email-masked]>
> *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 [email-masked] <mailto:[email-masked]> 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.
>
>   * 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]
>
> Bob Briscoehttp://bobbriscoe.net/

---

From: Ingemar Johansson S <[email-masked]>
Date: Sat, 10 Nov 2018 21:29:54 +0000

Hi

Please see in line [IJ]

Regards

Ingemar

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

Ingemar,

Hi

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

Section 4.2:

[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:

      rationale).

[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!

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

[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.

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

[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

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

www.ericsson.com

              can't be made worse

                 Humphrey Bogart

 

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

Ingemar,

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 11 Nov 2018 01:12:42 +0000

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:
> *Sent:* den 9 november 2018 11:40
> *Cc:* [email-masked]
> *Subject:* Re: Comments on draft-ietf-tsvwg-ecn-l4s-id-05
>
> Ingemar,
>
>     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…).
>
>
> 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.
>
> --------
>
>
> 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:
>
>     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!
>
>
>     ================
>
>     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.
>
>     [email-masked]
>     <mailto:[email-masked]>
>
>     www.ericsson.com
>
>     *From:*Bob Briscoe <[email-masked]> <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     Pref. before the end of Nov. could you review at least one of the
>     L4S drafts, cc the [email-masked] <mailto:[email-masked]> 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.
>
>         <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]
>     PS. The 3rd primary L4S draft going through now is the
>     architecture, but others are reviewing that.
>
>
>
>
>
>     -- 
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Sun, 11 Nov 2018 20:28:14 +0000

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 <[email-masked]> 
Sent: den 11 november 2018 02:13
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-tsvwg-ecn-l4s-id-05

Ingemar,

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

      the ecn-capable-rtp attribute [RFC6679 <https://tools.ietf.org/html/rfc6679> ].  Therefore, the presence

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.

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

Hi

Please see in line [IJ]

Regards

Ingemar

Cc: [email-masked] <mailto:[email-masked]> 

Ingemar,

Hi

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

Section 4.2:

----------

 

--------

[IJ] Great

[IJ] OK

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

Section 4.3:

      rationale).

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

 

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

Bob

Regards

Ingemar Johansson

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson Research

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

www.ericsson.com

              can't be made worse

                 Humphrey Bogart

 

Ingemar,

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 15 Nov 2018 15:04:10 +0000

Ingemar,

On 11/11/2018 20:28, Ingemar Johansson S wrote:
>     RFC8298 (SCReAM) currently only specifies classic ECN handling,
>     but running code of SCReAM found at
> 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.
>
>

[BB] Your answer still seems to mix feedback (receiver and sender) with 
congestion response (sender).

Here's my question written more clearly:

If both ends already support avtcore-cc-feedback-message, can one end 
unilaterally implement the L4S congestion response (and therefore set 
ECT(1) on outgoing packets)?
Or did you have to enhance the avtcore-cc-feedback-message code (for 
writing feedback at one end and reading it at the other), before one end 
(or both) could add the L4S congestion response?

The stated goal of avtcore-cc-feedback-message is:

    To enable algorithm evolution as well as
    interoperability across designs (e.g., different rate adaptation
    algorithms), it is highly desirable to have generic congestion
    control feedback format.

If you had to enhance the feedback format for L4S, that would imply the 
feedback message is still not generic enough.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 15 Nov 2018 15:07:20 +0000

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.
>
> *Sent:* den 11 november 2018 02:13
> below) still correct. IOW, should I add your text at the end of mine, 
> or should I delete any of mine?:
>
> Q2. I would like to add that avtcore-cc-feedback-message is intended 
> as a standards track update to RFC6679. Should I?
>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>         implemented ECN counters in the draft supports L4S. As of
>         today however only classic ECN handling is described in
>         supports ECN marking that can be used with L4S. RFC8298
>         (SCReAM) currently only specifies classic ECN handling, but
>         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.
>
>     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
>     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:
>
>         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!
>
>
>
>         ================
>
>         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.
>
>     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.
>
>
>
>         ================
>
>         <mailto:[email-masked]>
>         Pref. before the end of Nov. could you review at least one of
>         the L4S drafts, cc the [email-masked] <mailto:[email-masked]>
>         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.
>
>                 sending ECT(1) [thinking particularly from RMCAT and
>                 QUIC perspectives]

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 16 Nov 2018 06:45:49 +0000

Hi Bob

Please see inline, marked [IJ2]

/Ingemar

From: Bob Briscoe <[email-masked]>
Sent: den 15 november 2018 16:04
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; Magnus Westerlund <[email-masked]>; 
[email-masked]' <[email-masked]>
Subject: Re: Comments on draft-ietf-tsvwg-ecn-l4s-id-05

Ingemar,

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?

[IJ2] RFC8298 does only specify classic ECN back-off 
https://tools.ietf.org/html/rfc8298#page-17 . The RFC8298 does not mention L4S 
at all and therefore it does not distinguish between ECT(0) and ECT(1).

[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.

[IJ2] Yes, possibly , feedback is not specified in RFC8298, there is however a 
list of requirements https://tools.ietf.org/html/rfc8298#page-28

If both ends already support avtcore-cc-feedback-message, can one end 
unilaterally implement the L4S congestion response (and therefore set ECT(1) 
on outgoing packets)?

[IJ2] Yes, that is possible as avtcore-cc-feedback-message  indicates the ECN 
bits for each received packet.

Or did you have to enhance the avtcore-cc-feedback-message code (for writing 
feedback at one end and reading it at the other), before one end (or both) 
could add the L4S congestion response?

[IJ2] No

[IJ2] No, enhancement of the avtcore-cc-feedback-message  is not necessary, 
the only thing that is required is that the sender is aware that it sets 
ECT(1) and applies a scalable congestion control.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 16 Nov 2018 17:49:39 +0000

Ingemar,

Thanks for clarifying. Understood now.

Bob

On 16/11/2018 06:45, Ingemar Johansson S wrote:
> *Sent:* den 15 november 2018 16:04
> *Cc:* [email-masked]; Magnus Westerlund 
> <[email-masked]>; [email-masked]' <[email-masked]>
>         RFC8298 (SCReAM) currently only specifies classic ECN
>         handling, but running code of SCReAM found at
>     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?
>
>     https://tools.ietf.org/html/rfc8298#page-17 . The RFC8298 does not
>     mention L4S at all and therefore it does not distinguish between
>     ECT(0) and ECT(1).
>
>     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.
>
>
>     rather move this to where we talk about setting the codepoint or
>     the congestion control.
>
>
> [BB] Your answer still seems to mix feedback (receiver and sender) 
> with congestion response (sender).
>
> [IJ2] Yes, possibly , feedback is not specified in RFC8298, there is 
> however a list of requirements 
> https://tools.ietf.org/html/rfc8298#page-28
>
>
>
> [IJ2] Yes, that is possible as avtcore-cc-feedback-message indicates 
> the ECN bits for each received packet.
>
>
> writing feedback at one end and reading it at the other), before one 
> end (or both) could add the L4S congestion response?
>
> [IJ2] No
>
>
>
> If you had to enhance the feedback format for L4S, that would imply 
> the feedback message is still not generic enough.
>
> [IJ2] No, enhancement of the avtcore-cc-feedback-message is not 
> necessary, the only thing that is required is that the sender is aware 
> that it sets ECT(1) and applies a scalable congestion control.
>
>
>
>
> Bob
>
>
> --

---

From: Colin Perkins <[email-masked]>
Date: Tue, 20 Nov 2018 23:36:24 +0000

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 <[email-masked]> wrote:
> 
> Magnus or Colin,
> 
>> From: Bob Briscoe <[email-masked]> <mailto:[email-masked]> 
>> To: Ingemar Johansson S <[email-masked]> <mailto:[email-masked]>
>> 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.
>> From: Bob Briscoe <[email-masked]> <mailto:[email-masked]> 
>> To: Ingemar Johansson S <[email-masked]> <mailto:[email-masked]>
>> 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.
>>  
>> 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.
>> 
>> 
>>  
>> --------
>> 
>>       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).
>> www.ericsson.com <x-msg://6/www.ericsson.com>
>>  
>> From: Bob Briscoe <[email-masked]> <mailto:[email-masked]> 
>> To: Ingemar Johansson S <[email-masked]> <mailto:[email-masked]>
>> 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]
>> 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/

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 28 Nov 2018 15:44:06 +0100

Hi Bob,

I finally found the time to closely read the l4s-arch draft.

The architecture document can be read to concern itself more with 
streaming-type loads, as those examples are very prominently mentioned.

For the uninitiated, a short paragraph discussing the interaction of 
streaming flows with burstly flows might be good.

There is some discussion around this later in the document (sections 
6.2, 8.2) though. Also, I consider the explicit mentioning of 
heterogenous data centers in the applicability section to be very valuable.

Editorial: I believe the canonical name for DCTCP is Data Center TCP 
(sec 2, point 3) although that may run against your british english 
instinct :) (Centre is used consistently throughout the document; I 
assume people are more likely to search for data center though)

Link in Mathis09 is unreachable; found a copy at 
https://www.gdt.id.au/~gdt/presentations/2010-07-06-questnet-tcp/reference-materials/papers/mathis-relentless-congestion-control.pdf

Top of page 14, two nested opening brackets in the first paragraph

Para 8.1, comma instead of dot (before ", In turn,")

s/best efforts/best effort/ (traffic)

Best regards,
   Richard