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

[Bob Briscoe <[e-mail]>]

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/