Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"

[Tal Mizrahi <[e-mail]>]

Hi Bob,

Many thanks for the clarification.

Cheers,
Tal.

On Tue, Jan 22, 2019 at 2:05 AM Bob Briscoe <[e-mail]> wrote:

> Tal,
>
> I've conferred with my co-authors, and I can confirm that there is no need
> for a separate L4S mode, as incorrectly described around Table 2 in
> draft-02. It was actually me who wrote the incorrect text and table in the
> first place - my co-authors are wholly innocent, cos I'm the one developing
> the L4S experiment (L4S = Low Latency Low Loss Scalable throughput)! So
> thanks for asking how the two approaches interoperate, which made me notice
> this.
>
> The answer to your question is that L4S doesn't need any change to how
> congestion signals are propagated. L4S is purely a different AQM algorithm
> at network nodes and a different response algorithm at the source. As far
> as encap and decap are concerned, the tunnelling behaviours specified in
> RFC6040 and followed in the sfc-nsh-ecn draft inherently work for L4S just
> as well as for standard RFC3168 ECN. That's all the SFC WG needs to know.
>
> However, if you want to know a little more about how L4S works, the source
> distinguishes its packets by setting them to ECT(1), which an L4S node
> classifies into a distinct L4S queue. Any network node that doesn't support
> L4S will just handle these packets as if ECT(0) and ECT(1) mean the same
> (as required by the original ECN spec [RFC3168]). And the source has to
> detect such behaviour and respond accordingly
> [draft-ietf-tsvwg-ecn-l4s-id].
>
> We will be correcting the text as follows:
>
> CURRENT:
>
>    Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
>    set it to ECT(0), in order to indicate that the NSH encapsulation is
>    an ECN-Capable Transport. It MAY instead be set to ECT(1) if the NSH
>    domain supports the experimental L4S capability [RFC8311 <https://tools.ietf.org/html/rfc8311>], [ecnL4S <https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02#ref-ecnL4S>].
> ...
>
>             +-----------------+-------------------------------+
>             | Incoming Header |Departing NSH and Outer Headers|
>             | (also equal to  +---------------+---------------+
>             | departing Inner |  Classic ECN  |    L4S ECN    |
>             |     Header)     |     Mode      |     Mode      |
>             +-----------------+---------------+---------------+
>             |    Not-ECT      |   ECT(0)      |    ECT(1)     |
>             |     ECT(0)      |   ECT(0)      |    ECT(0)     |
>             |     ECT(1)      |   ECT(1)      |    ECT(1)     |
>             |       CE        |     CE        |      CE       |
>             +-----------------+---------------+---------------+
>
> PROPOSED:
>
>    Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
>    set it to ECT(0). This indicates that, even though the end-to-end
>    transport is not ECN-capable, the egress and ingress of the SFC
>    domain are acting as an ECN-capable transport. This approach will
>    inherently support all known variants of ECN, including the
>    experimental L4S capability [RFC8311 <https://tools.ietf.org/html/rfc8311>], [ecnL4S <https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02#ref-ecnL4S>].
> ...
>
>             +-----------------+---------------+
>             | Incoming Header |Departing NSH  |
>             | (also equal to  |& Outer Headers|
>             | departing Inner |               |
>             |     Header)     |               |
>             +-----------------+---------------+
>             |    Not-ECT      |   ECT(0)      |
>             |     ECT(0)      |   ECT(0)      |
>             |     ECT(1)      |   ECT(1)      |
>             |       CE        |     CE        |
>             +-----------------+---------------+
>
>
>
> On 15/01/2019 22:53, Bob Briscoe wrote:
>
> - "It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311], [ecnL4S]."
>   This sentence is confusing from an implementer's perspective. Does the "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a combination of both.
>
> I agree we need to clarify that.
>
> Let me get back to you on this one. I have to admit that I can't remember
> why we catered for L4S in the way written around table 2. I've checked
> back, and I actually wrote this part myself, but it looks wrong to me,
> which would be embarrassing. However, I need to check with my co-authors to
> confirm that.
>
> Whatever, thanks for picking this up.
>
>
> Bob
>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>