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 1:11 PM Jeremy Harris <[e-mail]> wrote:
>
> On 08/05/2020 16:19, Neal Cardwell wrote:
> > - SCE is basically an extension of RFC3168 ECN: senders mark their packets
> > ECT(0), and respond to CE like RFC 3168 says they should, by halving cwnd.
> > This would not work well for large sites with a substantial installed base
> > of shallow-threshold (DCTCP-style) ECN: if these sites marked their traffic
> > with ECT(0) to try to use SCE, their local switches configured for
> > shallow-threshold ECN would make CE marks at low queue occupancies, which
> > would cause large RFC3681-style reductions in cwnd, which would cause
> > underutilization. To the best of my knowledge this applies to several large
> > Internet services.
>
> Wait, that doesn't match my understanding.  In such an example site
> using SCE I would expect ECT(0) marking only at "large" queue
> occupancies (and resulting in cwnd halving when seen), but more
> prevalently ECT(1) marking at "small" queue occupancies - resulting
> in some smaller percentage (than 50) decrease in cwnd when seen.

Sorry if my scenario was not clearly expressed. In the scenario I'm
talking about here, there is a substantial installed base of
shallow-threshold (DCTCP-style) ECN switches in the datacenter in
which a server/sender sits. Those switches have hardware that only
knows how to mark with CE marks, and the ECN marking thresholds are
set to be shallow, because that's what allows nice, low latency for
DCTCP-style algorithms, so that's how they've been running for years.
(And the switch hardware is unable to mark with ECT(1) as a congestion
signal.)

If a server/sender in such a context attempts to participate in an SCE
conversation with a client/receiver on the public Internet, there is
the likelihood that shallow queues in the local datacenter bottlenecks
will result in the local switches making CE marks that will be
reflected by the receiver and interpreted as requiring a maximum-sized
cwnd cut (50% for Reno, 30% for CUBIC). That would cause poor
throughput.

That's the basic concern for this scenario.

best,
neal