where does BBR fit into all this? v
On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake <jholl...@akamai.com> wrote: > On 2019-03-15, 11:37, "Mikael Abrahamsson" <swm...@swm.pp.se> wrote: > L4S has a much better possibility of actually getting deployment into > the > wider Internet packet-moving equipment than anything being talked > about > here. Same with PIE as opposed to FQ_CODEL. I know it's might not be > as > good, but it fits better into actual silicon and it's being proposed > by > people who actually have better channels into the people setting hard > requirements. > > I suggest you consider joining them instead of opposing them. > > > Hi Mikael, > > I agree it makes sense that fq_anything has issues when you're talking > about the OLT/CMTS/BNG/etc., and I believe it when you tell me PIE > makes better sense there. > > But fq_x makes great sense and provides real value for the uplink in a > home, small office, coffee shop, etc. (if you run the final rate limit > on the home side of the access link.) I'm thinking maybe there's a > disconnect here driven by the different use cases for where AQMs can go. > > The thing is, each of these is the most likely congestion point at > different times, and it's worthwhile for each of them to be able to > AQM (and mark packets) under congestion. > > One of the several things that bothers me with L4S is that I've seen > precious little concern over interfering with the ability for another > different AQM in-path to mark packets, and because it changes the > semantics of CE, you can't have both working at the same time unless > they both do L4S. > > SCE needs a lot of details filled in, but it's so much cleaner that it > seems to me there's reasonably obvious answers to all (or almost all) of > those detail questions, and because the semantics are so much cleaner, > it's much easier to tell it's non-harmful. > > <aside regarding="non-harmful"> > The point you raised in another thread about reordering is mostly > well-taken, and a good counterpoint to the claim "non-harmful relative > to L4S". > > To me it seems sad and dumb that switches ended up trying to make > ordering guarantees at cost of switching performance, because if it's > useful to put ordering in the switch, then it must be equally useful to > put it in the receiver's NIC or OS. > > So why isn't it in all the receivers' NIC or OS (where it would render > the switch's ordering efforts moot) instead of in all the switches? > > I'm guessing the answer is a competition trap for the switch vendors, > plus "with ordering goes faster than without, when you benchmark the > switch with typical load and current (non-RACK) receivers". > > If that's the case, it seems like the drive for a competitive advantage > caused deployment of a packet ordering workaround in the wrong network > location(s), out of a pure misalignment of incentives. > > RACK rates to fix that in the end, but a lot of damage is already done, > and the L4S approach gives switches a flag that can double as proof that > RACK is there on the receiver, so they can stop trying to order those > packets. > > So point granted, I understand and agree there's a cost to abandoning > that advantage. > </aside> > > But as you also said so well in another thread, this is important. ("The > last unicorn", IIRC.) How much does it matter if there's a feature that > has value today, but only until RACK is widely deployed? If you were > convinced RACK would roll out everywhere within 3 years and SCE would > produce better results than L4S over the following 15 years, would that > change your mind? > > It would for me, and that's why I'd like to see SCE explored before > making a call. I think at its core, it provides the same thing L4S does > (a high-fidelity explicit congestion signal for the sender), but with > much cleaner semantics that can be incrementally added to congestion > controls that people are already using. > > Granted, it still remains to be seen whether SCE in practice can match > the results of L4S, and L4S was here first. But it seems to me L4S comes > with some problems that have not yet been examined, and that are nicely > dodged by a SCE-based approach. > > If L4S really is as good as they seem to think, I could imagine getting > behind it, but I don't think that's proven yet. I'm not certain, but > all the comparative analyses I remember seeing have been from more or > less the same team, and I'm not convinced they don't have some > misaligned incentives of their own. > > I understand a lot of work has gone into L4S, but this move to jump it > from interesting experiment to de-facto standard without a more critical > review that digs deeper into some of the potential deployment problems > has me concerned. > > If it really does turn out to be good enough to be permanent, I'm not > opposed to it, but I'm just not convinced that it's non-harmful, and my > default position is that the cleaner solution is going to be better in > the long run, if they can do the same job. > > It's not that I want it to be a fight, but I do want to end up with the > best solution we can get. We only have the one internet. > > Just my 2c. > > -Jake > > > _______________________________________________ > Ecn-sane mailing list > ecn-s...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane > -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat