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

[Neal Cardwell <[e-mail]>]

On Tue, May 12, 2020 at 4:38 PM Jeremy Harris <[e-mail]> wrote:
>
> On 12/05/2020 21:29, Neal Cardwell wrote:
> > On Fri, May 8, 2020 at 1:54 PM Jonathan Morton <[e-mail]> wrote:
> >> The shallow queues referred to are intended for deployment in tightly
> >> controlled datacentre environments, where the typical path RTT is measured in
> >> microseconds rather than milliseconds. It would not be surprising if a
> >> transport passing through such a queue as part of a typical Internet path of
> >> many milliseconds experienced poor utilisation.
> >
> > I think the issue is that such paths do not currently suffer from
> > throughput problems, but could if they attempt to participate in an
> > SCE conversation.
>
> They would if they tried to participate in a plain 3168 conversation,
> right?  I don't see you can dislike SCE for that.

Yes, they would hit these issues if they tried to participate in a
plain RFC3168 conversation, but I think that's somewhat academic,
since they don't use RFC3168. I think the useful comparison is L4S vs
SCE.

> How does it behave for L4S, without changing the datacentre hardware?

I think for the L4S case, the point is that the sender would mark the
packets as ECT(1), even shallow queues in the datacenter switch would
be marked as CE, the receiver would reflect the CE information, and
the sender would see the CE but would know that the queue might well
be shallow, so would not necessarily cut its cwnd by 50% (Reno) or 30%
(CUBIC), until/unless the CE marks were sustained/prevalent.

Best regards,
neal