Hi Greg,
On 2019-03-20, 13:55, "Greg White" <[email protected]> wrote:
In normal conditions, L4S offers "Maximize Throughput" + "Minimize Loss" +
"Minimize Latency" all at once. It doesn't require an application to have to
make that false choice (hence the name "Low Latency Low Loss Scalable
throughput").
[JH] This is an interesting claim, and I'm eager to see
how well it holds up under scrutiny and deployment.
I guess I'm not sure what exactly "normal" means, but I
would expect that there are a lot of cases that occur
frequently in practice where tradeoffs have to be made
between throughput, loss, and latency.
I'm finding I struggle to nail down exactly what I expect
from scenarios like a short-RTT L4S flow competing with a
long-RTT L4S flow (from transit delay) and with a BBR flow,
and likewise when a short and a long RTT L4S flow are
competing with a bunch of independent slow-start flows,
but if the L4S cases do indeed get a better throughput than
SCE-based approaches under the wide variety of situations
normal internet use can fall into, I think that would
convince me it's optimizing all of them at once, and it's
a mistake to call it focused on the latency use case.
But for now, I hope you'll forgive a little bit of
skepticism... I find this stuff complicated, and it's hard
for me to put high confidence on some of the predictions.
Best regards,
Jake
If an application would prefer to "Minimize Cost", then I suppose it could
adjust its congestion control to be less aggressive (assuming it is congestion
controlled). Also, as you point out the LEPHB could be an option as well.
What section 4.1 in the dualq draft is referring to is a case where the
system needs to protect against unresponsive, overloading flows in the low
latency queue. In that case something has to give (you can't ensure low
latency & low loss to e.g. a 100 Mbps unresponsive flow arriving at a 50 Mbps
bottleneck).
-Greg
On 3/20/19, 2:05 PM, "Bloat on behalf of Jonathan Morton"
<[email protected] on behalf of [email protected]> wrote:
> On 20 Mar, 2019, at 9:39 pm, Gorry Fairhurst <[email protected]>
wrote:
>
> Concerning "Maximize Throughput", if you don't need scalability to
very high rates, then is your requirement met by TCP-like semantics, as in TCP
with SACK/loss or even better TCP with ABE/ECT(0)?
My intention with "Maximise Throughput" is to support the bulk-transfer
applications that TCP is commonly used for today. In Diffserv terminology, you
may consider it equivalent to "Best Effort".
As far as I can see, L4S offers "Maximise Throughput" and "Minimise
Latency" services, but not the other two.
- Jonathan Morton
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
