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

[Neal Cardwell <[e-mail]>]

Hi Roland,

Please see some thoughts in-line below...

On Fri, May 8, 2020 at 1:12 PM Roland Bless <[e-mail]> wrote:
>
> Hi Neal and all,
>
> see inline.
>
> On 08.05.20 at 17:19 Neal Cardwell wrote:
> > As part of the discussion around the consensus call on ECT(1), I
> > wanted to post my personal rationale for supporting ECT(1) as an
> > input/classification signal, along the lines of the L4S proposals.
> >
> > This is my personal opinion; I'm not speaking for any company or
> > institution.
> >
> > Many of these points will echo the excellent points that were made at
> > the TSVWG interim on April 27, by Greg White, Bob Briscoe, Jana
> > Iyengar, Stuart Cheshire, and Andrew McGregor; I agree with all of the
> > points they made. But for the sake of discussion and debate I wanted
> > to amplify what they said and enumerate the particular considerations
> > that are most compelling to me.
>
> I had the feeling that this was more a discussion around L4S vs. SCE
> proposals and not about the
> ECT(1) codepoint in question. Several arguments were along the lines of
> "L4S is more advanced
> and needs to be finished as it already took too long". I don't think
> that this is a good argument as
> the L4S proposal could also use ECT(1) as output and use a DSCP as
> classifier. See below.

I think it's overly optimistic to think that DSCP could be used as an
end-to-end classifier for a new congestion control class across the
public Internet. Rewriting DSCP bits at ingress into an AS is a
ubiquitous mechanism, and such an undertaking would require hundreds
or thousands of ASes to rearrange their custom internal DSCP/QoS
architecture in compatible ways. And there is a combinatorial
explosion if an AS needs to deal with each of its existing DSCP/QoS
levels needing to support both the new congestion control class and
classic congestion controls. This doesn't seem like a realistic path
to me.

> > - Much of the installed base of switch hardware around the world can
> > already be configured to signal shallow-threshold congestion with
> > DCTCP/L4S-style CE marks. Many have CE-marking mechanisms baked into
> > hardware, and would need to be replaced in order to deploy SCE.
> The question is: could they easily support using ECT(1) instead of CE
> for the shallow-threshold marking?

I suspect that in most high-speed switches and routers, the
functionality to use CE for ECN markings is etched into ASIC hardware,
and could not be changed.

> Supporting L4S's dual queue and classification by ECT(1) would IMHO
> require even more extensive hardware changes.

Yes. But dual-queue is not a required component of L4S inside a
datacenter. So the existing installed base of datacenter switches
would not need to be changed at all to participate in L4S. Those
switches are designed to mark any ECT(0) or ECT(1) packets with CE
when the queue passes a shallow threshold. That works for their
current use case, and it works for L4S. No changes would be needed, to
hardware or firmware.

> > - 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'm not sure about this one. L4S could be affected equally or do you
> think that CE is handled differently? I wasn't able to find a quick
> answer by looking at
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-13

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.)

> > - To get low latency in the public Internet, we need multiple queues.
> > With SCE AFAICT there's not yet a compelling story about how to
> > classify traffic to maintain a low-delay queue and  a classic queue,
> > since there is no ECN code point to identify the low-delay traffic.
> > AFAICT with SCE you likely must either (a) have a single high-delay
> > queue with a jumble of Reno, CUBIC, classic RFC 3168, and
> > SCE-respecting RFC 3168 senders, (b)  use fair queuing (tricky in
> > hardware), (c) use DSCP to classify (academically pure but unrealistic
> > across multiple ASes in the public Internet), (d) use a dual-queue
> > system that heuristically classifies all flows into the low-delay
> > queue by default but kicks them out using a queue-protection algorithm.
>
> I agree here and queue separation would also be essential for SCE. But
> using a DSCP for classification would
> be the more extensible solution as ECT(1) wouldn't always mean to use
> the L4S queue semantics. Instead both
> solutions could use the ECT(1) mark with nearly the same congestion
> signal semantics. Moreover, both solutions have
> problems with "misbehaving" flows in the wrong queue.

As mentioned above, I think using DSCP for congestion control
classification, while theoretically clean and extensible, is not a
realistic/feasible option.

Best regards,
neal