On Sat, Sep 17, 2016 at 2:11 PM, <dpr...@reed.com> wrote: > The assumption that each flow on a path has a minimum, stable RTT fails in > wireless and multi path networks.
Yep. But we're getting somewhere serious on having stabler RTTs for wifi, and achieving airtime fairness. http://blog.cerowrt.org/flent/crypto_fq_bug/airtime_plot.png > > > > However, it's worth remembering two things: buffering above a certain level > is never an improvement, which BBR recognizes by breaking things up into separate bandwidth and RTT analysis phases. >and flows through any shared router come and go quite frequently on the real >Internet. Very much why I remain an advocate of fq on the routers is that your congestion algorithm for your particular flow gets more independent of the other flows, and ~0 latency and jitter for sparse flows is meaningful. > Thus RTT on a single flow is not a reasonable measure of congestion. ECN > marking is far better and packet drops are required for bounding time to > recover after congestion failure. Aww, give the code a chance, it's only been public for a day! I haven't even got it to compile yet! I think it is a *vast* improvement over cubic, and possibly the first delay sensitive tcp that can compete effectively with it. I'm dying to test it thoroughly, but have a whole bunch other patches for wifi in my queue. > > The authors suffer from typical naivete by thinking all flows are for file > transfer and that file transfer throughput is the right basic perspective, > rather than end to end latency/jitter due to sharing, and fair sharing > stability. While I agree *strongly* that lots of short flows is how the internet mostly operates, (I used to cite a paper on this a lot) a huge number of bulk flows exist that has been messing up the short flows. I think the number was something 70% of internet traffic has become netflix-like. *anything* e2e that can reduce the negative impact of the big fat flows on everything else is a win. > > > > -----Original Message----- > From: "Jonathan Morton" <chromati...@gmail.com> > Sent: Sat, Sep 17, 2016 at 4:11 pm > To: "Maciej Soltysiak" <mac...@soltysiak.com> > Cc: "Maciej Soltysiak" <mac...@soltysiak.com>, > "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net> > Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP > innet-next > > >> On 17 Sep, 2016, at 21:34, Maciej Soltysiak wrote: >> >> Cake and fq_codel work on all packets and aim to signal packet loss early to >> network stacks by dropping; BBR works on TCP and aims to prevent packet loss. > > By dropping, *or* by ECN marking. The latter avoids packet loss. > > - Jonathan Morton > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
