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

[Bob Briscoe <[e-mail]>]

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

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.

> ================
>
> 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]>
> *Sent:* den 8 november 2018 05:55
> *To:* Ingemar Johansson S <[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 Briscoe                               http://bobbriscoe.net/