* Re: [Ecn-sane] Questions about TSVWG call
2020-04-30 17:28 [Ecn-sane] Questions about TSVWG call Rich Brown
@ 2020-04-30 17:55 ` Jonathan Morton
0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Morton @ 2020-04-30 17:55 UTC (permalink / raw)
To: Rich Brown; +Cc: ecn-sane
> On 30 Apr, 2020, at 8:28 pm, Rich Brown <richb.hanover@gmail.com> wrote:
>
> I have been a bystander in these discussions, and could only listen in to part of the TSVWG conference call. But here are a couple questions that come to mind from what (I think) I heard...
>
> 1) Has anyone run RRUL tests on L4S gear? What would be involved setting up such a test? Why hasn't it already been done?
I'm pretty sure the L4S team hasn't. We're doing some runs now ourselves. As for why, it might show up something inconvenient that doesn't look good for their marketing.
> 2) If I understand correctly, the L4S proposal is to use the ECT(1) bit as an input to the routing algorithm. If it's set, the router can assume that it's latency-sensitive traffic and use special routing rules/queues/etc. How does L4S guard against DoS/cheating? Has such a proposal been implemented and tested?
It's a fair question. A "queue protection algorithm" is supposedly a MUST in the L4S spec, but we haven't seen a working implementation yet, and it rather undermines their claims that L4S doesn't require L4 header inspection. I happen to think the real danger lies the other way, that with 1/p responses to CE legitimised, someone will alter a sender to be classed into the "classic" queue instead, squeezing out other traffic. Y'know, like DCTCP does.
Because SCE doesn't rely on a classifier, no such danger exists for us. We use a different method to ensure SCE traffic coexists nicely with conventional traffic.
> 3) The L4S proposal is designed to decrease latency. Can there be a successful L4S deployment in the face of the millions of current CPE that have no notion of latency control?
In a drop-tail queue, L4S is supposed to respond to lost packets with MD, and reserve the 1/p response solely for (at least) ECN enabled networks. We found that functionality had not been very well tested, though they fixed the bug we found pretty quickly. The major concern is with L4S' deployment into an Internet equipped with conventional AQMs and exhibiting significant jitter on real paths.
SCE works fine on any existing deployed network, with conventional behaviour as long as SCE signals are absent. When the bottleneck is also SCE enabled, all flows passing through it benefit from the associated FQ or AF management, and SCE flows additionally get the benefits of high-fidelity congestion control.
> 4) I have a personal bias toward helping people with dreadfully slow ISP service. (My home can only get 7mbps/768kbps DSL; others in my town only get 3mbps/500kbps service.) Does L4S help for slow links like these?
Our testing has found that the "classic detection heuristic", intended to deal with existing AQM deployments, is triggered on slow links such as that (our example was at 5Mbps) even if they are L4S equipped, so no, there is no benefit from L4S there.
I think we can demonstrate SCE achieving better results here. The goal for us is to achieve 100% link utilisation without incurring excess latency, and without breaking stuff that's already in use.
L4S tries to cut queue delay so low that, at anything less than 25Mbps, it takes longer to deliver a single packet. So they can't reliably operate on ADSL at all.
- Jonathan Morton
^ permalink raw reply [flat|nested] 2+ messages in thread