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

["Holland, Jake" <[e-mail]>]

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:
https://mailarchive.ietf.org/arch/msg/tsvwg/Io3UlijUMEtjwyyxEwFSFBFpqIQ/
https://mailarchive.ietf.org/arch/msg/tsvwg/IWZNcqQCAwjX7AQT-QGJpLAqeEQ/
https://mailarchive.ietf.org/arch/msg/tsvwg/ZdNy965gDsqdqXz94rpENWaogwM/
https://mailarchive.ietf.org/arch/msg/tsvwg/1MlFf36hNSMqzG40uYGn-CpsqcY/

And it looked like you were thinking option (1) as far as I could tell,
but you didn't seem to have any mention of the need for segregating the
L4S vs. classic traffic from the internet, so I'm worried there might
have been a misunderstanding in the explanation you got from Bob.

As far as I could tell from Bob's response so far, he is claiming that
datacenter switches WOULD need to upgrade hardware to have dualq support
in order to participate in marking L4S traffic from the internet, unless
maybe they were marking ONLY L4S traffic, though it was a little hard to
be sure:
https://mailarchive.ietf.org/arch/msg/tsvwg/1cU3g2KfBFiWOAJZnUOKybeOrGk/

Or Bob, maybe you have some clarifying remarks on this point?  It's
possible I'm misunderstanding something.

(I'm granting the significance of the tunnel issues you mentioned in
the last referenced message (thanks for including your tunneling
protocol list and analysis), and asking just for your position on whether
existing switches can participate in marking mixed internet traffic
without segregating the L4S traffic.)

Best regards,
Jake