Hi Mikael,
> On Mar 15, 2019, at 19:36, Mikael Abrahamsson <swm...@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: swm...@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
