[Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[David P. Reed]

Vint -
 
BBR is the end-to-end control logic that adjusts the source rate to match the share of the bolttleneck link it should use.
 
It depends on getting reliable current congestion information via packet drops and/or ECN.
 
So the proposal by these guys (not the cable guys) is an attempt to improve the quality of the congestion signal inserted by the router with the bottleneck outbound link.
 
THe cable guys are trying to get a "private" field in the IP header for their own use.
 
 
-----Original Message-----
From: "Vint Cerf" <vint at google.com>
Sent: Saturday, March 16, 2019 5:57pm
To: "Holland, Jake" <jholland at akamai.com>
Cc: "Mikael Abrahamsson" <swmike at swm.pp.se>, "David P. Reed" <dpreed at deepplum.com>, "ecn-sane at lists.bufferbloat.net" <ecn-sane at lists.bufferbloat.net>, "bloat" <bloat at lists.bufferbloat.net>
Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104



where does BBR fit into all this?
v


On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake <[ jholland at akamai.com ]( mailto:jholland at akamai.com )> wrote:On 2019-03-15, 11:37, "Mikael Abrahamsson" <[ swmike at swm.pp.se ]( mailto:swmike at 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-sane at lists.bufferbloat.net ]( mailto:Ecn-sane at lists.bufferbloat.net )
[ https://lists.bufferbloat.net/listinfo/ecn-sane ]( https://lists.bufferbloat.net/listinfo/ecn-sane )
-- 


New postal address:
Google

1875 Explorer Street, 10th Floor
Reston, VA 20190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20190317/03850596/attachment-0002.html>