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

[Neal Cardwell <[e-mail]>]

Hi Jake and Bob,

On Thu, May 28, 2020 at 2:15 AM Holland, Jake
<jholland=[e-mail]> wrote:
>
> Hi Neal and Bob,
>
> On 5/12/20, 1:55 PM, "Neal Cardwell" <ncardwell=[e-mail]> wrote:
> On Fri, May 8, 2020 at 6:02 PM Holland, Jake
> <jholland=[e-mail]> wrote:
> >> 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.
>
> I'm confused how this would operate in a way that's compatible with both
> existing hardware and internet traffic, but I can think of 2 possible
> interpretations.  Are you saying that:
>
> (1) For internet traffic, classic markings (ECT(0) and NECT) would be
> segregated to a different path, but L4S traffic (ECT(1) and CE) would be
> sent through an existing marking low-threshold queue as currently
> configured for DCTCP so it could mark the internet L4S traffic without a
> hardware upgrade? Or
>
> (2) The datacenter traffic and the internet traffic would be completely
> segregated, and the existing datacenter switches wouldn't be involved in
> marking the L4S traffic from the internet?
>
> The point being: I don't think the existing switches would be able to
> mark internet traffic as in (1) without segregation, because otherwise
> the classic traffic would back off aggressively to the low-threshold
> signal from the existing queues.
>
> So it sounds to me like this idea is something like dualq but uncoupled,
> with separate devices as the different queues to avoid a hardware upgrade
> in order to use L4S?  (Otherwise, as in (2), I'm not clear on how the
> existing hardware makes a difference.)
>
> Just want to make sure I understand the datacenter angle on this.
> Thanks in advance for clarifying, if you get a chance.
>
> I tried to figure out which of these you meant (or whether it was a 3rd
> option), by re-reading these messages:

I'm thinking of a 3rd approach not listed above:

(3) There is no RFC3168 ECN traffic, because the site does not use
RFC3168 ECN. All TCP/UDP traffic would be allowed to share a queue:
non-ECN public Internet traffic, L4S public Internet traffic, and
low-threshold-ECN internal datacenter traffic. During conditions of
congestion, the switches would mark using shallow-threshold ECN marks,
and thus the non-ECN public Internet traffic would receive a higher
share of bandwidth than L4S or internal traffic in that queue, but
this is deemed acceptable, since public Internet traffic is already
deemed to be highest-priority. In this approach, the L4S traffic is
added into the mix using existing queues in existing datacenter switch
hardware, without introducing new devices, new queues, or dualq.

best,
neal