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").
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"
<bloat-boun...@lists.bufferbloat.net on behalf of chromati...@gmail.com> wrote:
> On 20 Mar, 2019, at 9:39 pm, Gorry Fairhurst <go...@erg.abdn.ac.uk> 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
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
