Re: [tsvwg] L4S and MPLS

[Bob Briscoe <[e-mail]>]

Uma,

On 06/05/2020 01:18, Uma Chunduri wrote:
> Bob,
>
>
> A draft is needed for handling this in legacy nodes

[BB] That's already implicit in any ECN approach - legacy nodes that 
don't support ECN will drop if congested, and drop is always recognized 
by end-systems as potential congestion.

RFC5129 took the view that it would be feasible for an operator to 
invest in ECN support for all the nodes around the boundary of an MPLS 
domain, which made it feasible to only burn 2 TC codepoints.

If full boundary support were not feasible, then 3 TC codepoints minimum 
would need to be burned for ECN (Not-ECN-capable, ECN-capable and 
Congestion-Experienced). I don't think anything has changed over the 
years that would make any operator want to burn 3 codepoints for ECN. 
So, I don't think anything new could be said about legacy support.

> but  also reducing section 9 options in 5129.

[BB] Yes, the world has moved on since then. But that's only an 
informational section anyway.

It would make sense to writing up one or perhaps two practical ways that 
today's MPLS could support ECN marking. All presuming that anyone thinks 
an LSR might become a bottleneck.


> For the new functionality, if a new label is pushed, current L-LSP 
> option of label per PSC can be done better.

[BB] Ah, perhaps here you have been thinking of feeding back the 
congestion signals solely edge-to-edge across the MPLS domain (like the 
[SHAYMAN] reference in RFC5129? Rather than (or perhaps as well as) 
propagating to the onward IP header and the ultimate destination for 
feeding back to the original source to get it to control the load.

Donald Eastlake and I have written up an approach like that here (but 
for the network services header (NSH) used in service function chaining 
(SFC)): https://tools.ietf.org/html/draft-ietf-sfc-nsh-ecn-support-02


>
> In-line [Uma]:
>
> Thank you for your response.
>
> --
> Uma C.
>
> On Wed, Apr 29, 2020 at 5:28 AM Bob Briscoe <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>         Uma,
>
>
>         Further to your query about L4S for MPLS, RFC5129 was written
>         before two distinct ECT codepoints were being considered, for
>         L4S.
>
>
>         Altho a network might be designed so that interior LSRs do not
>         bottleneck (e.g. some sort of Clos topology), in other network
>         designs, they might sometimes be a bottleneck.
>
> [Uma]: Not much in CLOS topologies or DC underlays. But in general 
> where ever LDP label is used bottlenecks can be avoided.  Right, not 
> sure if ECN/CE  marking is needed in TE cases (where overall link 
> utilization is designed to be  lower, in general).

[BB] So, will there be any interest in supporting ECN in MPLS anyway?

>
>         Then I can suggest two ways to handle the two distinct ECT
>         codepoints. They both devolve the work t  a) the ingress, b)
>         the egress where an MPLS header is respectively first pushed
>         over an IP header or finally popped from an IP header. This
>         would be in keeping with the general approach in RFC5129 of
>         devolving ECT checking to the nodes around the boundary.
>
>
>         a) Ingress
>
>
>         The two ECT codepoints are effectively 2 different AQM
>         classifiers, so I would suggest mapping them to two different
>         labels at the ingress. See
>         https://tools.ietf.org/html/rfc5129#section-6
>
>         Then the label selects the AQM behaviour.
>
> [Uma]; I see 2 cases here. An ingress node aware of L4S input signal. 
> Then yes,  a new label can be pushed and handled accordingly at 
> internal nodes.  But, the case where a non-L4S aware node treats this 
> to eventually mark CE is more important. Both cases  need to be 
> described properly in a draft for sure.

[BB] See my earlier point about burning TC codepoints. To burn no more 
than 2 TC codepoints, an MPLS domain cannot support ECN at all until all 
boundary nodes support ECN.

>
>         b) Egress
>
>
>         Map to only one label at ingress and have only one (linear)
>         L4S-ECN AQM behaviour on interior LSRs (generating the more
>         frequent ECN marking typical of L4S). Then when an egress LSR
>         pops the last label and finds an ECN field in an IP header:
>
>          1. if the inner is ECT(1), it passes on the ECN mark to the
>             inner IP packet verbatim
>
>          1. if the inner is ECT(0) or Not-ECT, it runs a simple
>             algorithm to thin the signals down to the square of their
>             frequency of arrival (requires one variable of per-LSP state).
>
> [Uma]: Sounds reasonable but I am sure you might see some 
> resistance w.r.t  per-LSP state. But this might be ok, as this is on 
> egress and we have examples with binding-SIDs in SR world.
>
>         Without thinking too hard about this, the "simple algorithm"
>         could be:
>
>          per LSP at egress, run each arriving ECN mark (i.e. C = 0 or
>         1) through a per-packet EWMA:
>
>
>             p += (C - p) >> g_shift;
>
>             if (rand() > p && rand() > p) {    // two random
>         comparisons squares the probability
>
>                    if (ECT0) mark;
>
>                    else drop;
>
>             }
>
>
>         where ">>" is a bit-shift and g_shift is the (constant) gain
>         chosen for the EWMA.
>
>
>         Longer term (or even short term) it wouldn't necessarily need
>         to support ECT0. Then the algo would simplify to:
>
>
>             p += (C - p) >> g_shift;
>
>             if (rand() > p && rand() > p) // two random comparisons
>         squares the probability
>
>                 drop;
>
> [Uma]: Thx for the info and the reference below.
>
>         I thought up the idea of two comparisons with random numbers
>         while in BT, and BT decided to publish without patenting it.
>         That publication has since been cited widely within the global
>         patent system, so it has official recognition. Therefore no
>         IPR declaration would be needed if we wrote these points up as
>         an extension to RFC5129 for L4S.
>
> [Uma]: Needed to update both 5129 and 5462  too. Not only capturing 
> this but also to simplify  5129 options with accumulated deployment 
> experience of what is not working (last, where I saw this whole thing  
> is very badly handled in various implementations).

I can't see why 5462 would need to be updated. We're not proposing to 
change the terminology of anything - no need.

Altho I agree that section 9 of 5129 is outdated, it's only 
informational not normative, so an additional RFC giving more up to date 
info would be useful, but I'm not sure it would need to formally update 
RFC5129. However, that's for WG to decide, not us.

Cheers


Bob

>
>         Cheers
>
>
>
>
>         Bob
>
>
>         PS. There's a broadly similar but inside-out approach written
>         up for adding L4S support to ECN support in TRILL:
>
>         https://tools.ietf.org/html/draft-ietf-trill-ecn-support-07#appendix-A
>
>         This has been sitting in the RFC-Editor queue for 2 years now,
>         waiting on the L4S decision in tsvwg.
>
>
>
>
>     -- 
>     ________________________________________________________________
>     Bob Briscoehttp://bobbriscoe.net/
>

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