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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Mikael,


> On Mar 15, 2019, at 19:36, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> On Fri, 15 Mar 2019, David P. Reed wrote:
> 
>> So if the responsible network engineers in the carriers cannot agree on anything, IETF is wasting its time.
> 
> The IETF has already said that anything diffserv is domain-internal only. I have joined the effort of the LE PHB and see if we can get some kind of agreement and transparancy for a PHB that is aimed at customer access only and "drop most of me and my pals at any sign of customer access line congestion", and see if that can be agreed on.

	+1

> 
> Having a "lower-than-best-effort" diffserve codepoint might work, because it means worse treatment, not preferential treatment.
> 
> The problem with having DSCP CPs that indicate preferential treatment is typically a ddos magnet.

	Hence splitting it up, three for the current transport domain to do with as it sees fit and 3 for signaling intent; this very much does not give a guarantee that any intermediate hop will follow the intent, but only make it possible for the endpoints to transmit intent. This IMHO is completely compatible with a LE PHB and transports honoring that request. 

> See my emails on this topic on (this? other?) mailing lists where I try to create a three class buffering system saying "LE gets 5%, BE and 'everything-else' gets to split the difference".

	We can haggle over the numbers but that seems a) sane and b) underspecified...

> 
> I even got pushback on this here, and then we're not even close to people running large ISP networks who see ddos attacks happen hourly.
> 
> Saying L4S should "just use diffserv" is as constructive to say "go away and pound a rock" or "we want that bit pattern so.. screw you".

	But just nodding expertly when they go and claim an unrelated bit in the IP header for their separation l4s vs legacy (as if l4s would be the end all of network design), and then having resorting to modifying so-far not-deployed-at the edge DCTCP (instead of modifying well-deployed TCP) because they already spent the one bit usable to extend ECN for less binary congestion signaling in a backward-compatible fashion... I might be wording things to strongly here, but that is the general gist.

> 
> L4S has a much better possibility of actually getting deployment into the wider Internet packet-moving equipment than anything being talked about here.

	That is not a high bar to clear though...

> Same with PIE as opposed to FQ_CODEL. I know it's might not be as good,

	Debatable, and from my perspective this is the reason to talk about it at all.

> but it fits better into actual silicon

	Does it?

> and it's being proposed by people who actually have better channels into the people setting hard requirements.

	That would be great if the proposal would throw end-user like me a bone instead of treating me as the product. It would also help if the architectural RFC would not be so breathlessly over-hyping/over-promising... But they really need end-points to switch over to a neutered DCTCP before things start to make sense, so they actually need to convince end-users and so far they are doing a terrible job IMHO. But what do I know...

> 
> I suggest you consider joining them instead of opposing them.

	Join where? it pretty much looks like a "fait accompli" as they do seem way past the design stages and seem pretty much crystallized in what they see the path forward. 

Best Regards
	Sebastian

> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se