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

[Vint Cerf]

where does BBR fit into all this?

v


On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake <jholland at akamai.com> wrote:

> On 2019-03-15, 11:37, "Mikael Abrahamsson" <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
> 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/ecn-sane/attachments/20190316/5936db7a/attachment.html>