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

[Bob Briscoe <[e-mail]>]

Ingemar,

Thanks for clarifying. Understood now.


Bob

On 16/11/2018 06:45, Ingemar Johansson S wrote:
>
> Hi Bob
>
> Please see inline, marked [IJ2]
>
> /Ingemar
>
> *From:*Bob Briscoe <[e-mail]>
> *Sent:* den 15 november 2018 16:04
> *To:* Ingemar Johansson S <[e-mail]>
> *Cc:* [e-mail]; Magnus Westerlund 
> <[e-mail]>; '[e-mail]' <[e-mail]>
> *Subject:* Re: Comments on draft-ietf-tsvwg-ecn-l4s-id-05
>
> Ingemar,
>
> On 11/11/2018 20:28, Ingemar Johansson S wrote:
>
>     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?
>
>     [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.
>
>
> [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
>
>
>
> 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)?
>
> [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
>
>
>
> 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.
>
> [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
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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