Dave, in the thread referenced earlier that led to this change you said:

"The loss of throughput here compared to non-ingress mode is a blocker for
mainlining and for that matter, wedging this into lede."

I'm curious, what would the latency be in Toke's experiment with
non-ingress mode and with the 4 MTU change reverted? The same as for
fq_codel?


On Wed, Apr 18, 2018 at 7:02 PM, Dave Taht <dave.taht@gmail.com> wrote:

> Jonathan:
>
> I think you are wrong. What we care about is keeping packets in flight
> across the network, with a queue length as close to 1 packet as
> possible.
>
> If it breaks ingress mode so be it.
>
>
> On Wed, Apr 18, 2018 at 9:54 AM, Jonathan Morton <chromatix99@gmail.com>
> wrote:
> >> On 18 Apr, 2018, at 7:11 pm, Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
> >>
> >> What you're saying here is that you basically don't believe there are
> >> any applications where a bulk TCP flow would also want low queueing
> >> latency? :)
> >
> > I'm saying that there's a tradeoff between intra-flow induced latency
> and packet loss, and I've chosen 4 MTUs as the operating point.
> >
> > Bear in mind that with high packet loss, the retransmissions take an
> extra RTT to complete in any case, and there's a higher probability of
> incurring an RTO which will *really* hurt your intra-flow latency.
> >
> > This equation is modified with ECN because a high signalling rate
> doesn't result in packet loss or retransmissions, but I'm not presently
> making any decisions based on ECN support, except the obvious one of
> whether to mark or drop.
> >
> >  - Jonathan Morton
> >
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>