Re: [tsvwg] Neal Cardwell's rationale for supporting ECT(1) as an input/L4S signal

[Neal Cardwell <[e-mail]>]

On Fri, May 8, 2020 at 6:02 PM Holland, Jake
<jholland=[e-mail]> wrote:
>
> Hi Neal,
>
> Thanks for posting this, it’s a helpful explanation.
>
> A couple of points I wanted to respond to:
>
> From: Neal Cardwell <ncardwell=[e-mail]>
..
> I wanted to check to make sure I understand:
> To what extent do you think it's an L4S goal to accommodate the
> existing installed base of switch hardware that’s currently in use
> for DCTCP in datacenters?

I'm not sure if accommodating the existing installed base of switch
hardware was an explicit goal of L4S or not, but it is a nice property
that seems to help greatly in making L4S easier to deploy than it
might otherwise be.

> I thought the existing deployments generally wouldn’t be compliant
> L4S-compatible dualq devices suitable for general internet traffic
> anyway, and would continue to need traffic isolation the way they do
> now.  Is that different from your understanding?

My understanding is that dualq is not a required component of
implementing L4S, and definitely would not be required at every hop or
potential bottleneck along the network path. My understanding is that
there would be sites that don't want to change the qdiscs on their
senders/servers, and don't want to change their datacenter switches,
but would like their connections over the public Internet to be able
to use L4S.

> > - More generally, if there is any problem discovered with the L4S
> >   experiment, either the algorithm or particular implementations,
> >   bottlenecks can easily identify L4S traffic and bleach it into Not-ECT,
> >   and treat it like Reno/CUBIC traffic.
>
> To repeat in what's maybe a better thread for it:
>
> I agree that bleaching is an option where there’s RFC 3168 trouble,
> that’s a good point and thanks for mentioning it.
>
> I’d consider it a poor choice to land there if there's other options,
> because it works against the success of existing or under-way
> deployments of RFC 3168 queues by imposing a new bleaching requirement
> that may not be trivial for all networks with marking queues
>
> It would also be an unfortunate choice to endorse bleaching because it
> would lose much of the potential value in the code point, as David
> recently mentioned.
>
> But I do agree it would work, and that it’s a worthwhile mitigation
> that should be mentioned in the L4S docs if we end up not finding a
> way to support robust 3168 compatibility.

Yes, I agree with all those points; bleaching is very far from ideal.

> > - Encapsulation/decapsulation is a widely prevalent and important
> >   technology today in production networks. With the installed base of
> >   encap/decap mechanisms, it is likely that for many implementations any
> >   SCE marking applied to packets would just get stripped off with the outer
> >   header when decapsulated.
>
> I'd be interested in more information about this.  Is there anything
> publicly known about the deployment footprint of different tunnel
> implementations in the places likely to deploy L4S dualqs, and
> whether they're managed by the same entities who control the queues?
>
> I'm not sure it changes my position much, but it seems at least
> useful to know how big a lift it would be to do a tunnel
> decapsulation change, if that's a necessary piece of a safe
> approach to L4S that can achieve low latency effectively.
>
> (I know Bob gave a long list of tunneling protocols not long ago, but
> it seems like only some of them are likely to be relevant to the L4S
> question, and probably only in a reasonably specific set of
> implementations for at least the early stages...)

As I mentioned with Roland, here my understanding was based on a
description of this issue by Bob Briscoe. I'm not sure what the
original data source is for that issue. (And apologies if I have
misinterpreted the issue.) But perhaps Bob will have time to fill in
more of the details or pointers.

Best regards,
neal