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

[Vint Cerf <vint@google.com>]

[-- Attachment #1: Type: text/plain, Size: 6844 bytes --]

thanks, David - that's the information I was looking for.

v


On Sun, Mar 17, 2019 at 2:07 PM David P. Reed <dpreed@deepplum.com> wrote:

> 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@google.com>
> Sent: Saturday, March 16, 2019 5:57pm
> To: "Holland, Jake" <jholland@akamai.com>
> Cc: "Mikael Abrahamsson" <swmike@swm.pp.se>, "David P. Reed" <
> dpreed@deepplum.com>, "ecn-sane@lists.bufferbloat.net" <
> ecn-sane@lists.bufferbloat.net>, "bloat" <bloat@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@akamai.com> wrote:
>
>> On 2019-03-15, 11:37, "Mikael Abrahamsson" <swmike@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/ecn-sane
>
>
> --
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190
>


-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190

[-- Attachment #2: Type: text/html, Size: 9736 bytes --]