Hi Jonathan,
> On Dec 23, 2016, at 10:53, Jonathan Morton <[email protected]> wrote:
>
>>> As far as Diffserv is concerned, I explicitly assume that the standard
>>> RFC-defined DSCPs and PHBs are in use, which obviates any concerns about
>>> Diffserv policy boundaries.
>>
>> ??? This comes close to ignoring reality. The RFCs are less important
>> than what people actually send down the internet.
>
> What is actually sent down the Internet right now is mostly best-effort only
> - the default CS0 codepoint. My inbound shaper currently shows 96GB
> best-effort, 46MB CS1 and 4.3MB “low latency”.
>
> This is called the “chicken and egg” problem; applications mostly ignore
> Diffserv’s existence because it has no effect in most environments, and CPE
> ignores Diffserv’s existence because little traffic is observed using it.
>
> To solve the chicken-and-egg problem, you have to break that vicious cycle.
> It turns out to be easier to do that on the network side, creating an
> environment where DSCPs *do* have effects which applications might find
> useful.
You seem to completely ignore that given DSCP-domains the DSCP markings
are not considered to be immutable property of the sender but are used as a
scratch space for intermediate transport domains. Any scheme that does not
account for that will never reach end2end reliability of DSCP-coded intent.
Your chicken and egg phrasing of the challenge completely ignores this, and
that is what I only half-jokingly called ignoring reality...
>
>> coming up with a completely different system (preferable randomized for each
>> home network) will make gaming the DSCPs much harder
>
> With all due respect, that is the single most boneheaded idea I’ve come
> across on this list. If the effect of applying a given DSCP is
> unpredictable, and may even be opposite to the desired behaviour - or,
> equivalently, if the correct DSCP to achieve a given behaviour is
> unpredictable - then Diffserv will *never* be used by mainstream users and
> applications.
Exactly, Diffserv will ever only make sense inside a DSCP-domain and
inside one the code point to priority mapping can be completely arbitrary as it
can not be assumed to make sense in other settings. Anything else is a) open to
be gamed by sufficiently motivated application writers and will b) need to
survive the re-mapping ISPs might/will do during transit. I know there are
proposals to split the 6bit Diffserv field into two sets of 3bits, one for
signaling end2end intend and three for the current domain's re-mapping of that
intent (or lack thereof). But you knew that.
Also calling essentially randomization to avoid attacks boneheaded seems a bit
strong, it is not that this idea is without precedence (see KASLR, even though
6bits are not much to work with).
>
>>> Cake does *not* assume that DSCPs are trustworthy. It respects them as
>>> given, but employs straightforward countermeasures against misuse (eg.
>>> higher “priority” applies only up to some fraction of capacity),
>>
>> But doesn’t that automatically mean that an attacker can degrade
>> performance of a well configured high priority tier (with appropriate access
>> control) by overloading that band, which will affect the priority of the
>> whole band, no? That might not be the worst alternative, but it certainly is
>> not side-effect free.
>
> If an attacker wants to cause side-effects like that, he’ll always be able to
> do so - unless he’s filtered at source. As a more direct counterpoint, if we
> weren’t using Diffserv at all, the very same attack would degrade performance
> for all traffic, not just the subset with equivalent DSCPs.
Well then the damage would be shared instead of allowing an attacker to
selective degrade the higher priority data, but I see your point, the malicious
actor will cause problems diffserv or not and it is debatable which problem is
actually worse. But I also note that it is generally advised to re-map CS7 on
ingress to basically take the remote offenders capability away to affect the
network management traffic.
>
> Therefore, I have chosen to focus on incentivising legitimate traffic in
> appropriate directions.
>
>>> So, if Cake gets deployed widely, an incentive for applications to
>>> correctly mark their traffic will emerge.
>>
>> For which value of “correct” exactly?
>
> RFC-compliant, obviously.
This is the other half to my "ignoring reality” claim, if you put RFC
over observable data you are in for interesting challenges.
>
> There are a few very well-established DSCPs which mean “minimise latency”
> (TOS4, EF) or “yield priority” (CS1). The default configuration recognises
> those and treats them accordingly.
Which sounds fine with the caveat that those can not be trusted on
ingress without checking them first. Or put differently the internet is no
overarching dscp-domain.
>
>>> But almost no program uses CS1 to label its data as lower priority
>
> See chicken-and-egg argument above. There are signs that CS1 is in fact
> being used in its modern sense; indeed, while downloading the latest Star
> Citizen test version the other day, 46MB of data ended up in CS1. Star
> Citizen uses libtorrent, as I suspect do several other prominent games, so
> adding CS1 support there would probably increase coverage quite quickly.
The fact that torrent applications have not jumped upon the CS1 marking
idea (even though they typically do try to be good scavengers/netizens), should
give us pause to think. IMHO the reason is that torrents want to be robust
against ISP interference and hence using simple identifiers like using CS1
marking seems a hard sell to the torrent community. But that basically
diminishes the potential usefulness of the CS1 marking.
>
>>> Cake also assumes in general that the number of flows on the link at any
>>> given instant is not too large - a few hundred is acceptable.
>>
>> I assume there is a build time parameter that will cater to a specific
>> set of flows, would recompiling with a higher value for that constant allow
>> to taylor cake for environments with a larger number of concurrent flows?
>
> There is a compile-time constant in the code which could, in principle, be
> exposed to the kernel configuration system. Increasing the queue count from
> 1K to 32K would allow “several hundred” to be replaced with “about ten
> thousand”. That’s still not backbone-grade, but might be useful for a very
> small ISP to manage its backhaul, such as an apartment complex FTTP
> installation or a village initiative.
Ah, this sounds great, if the average flow use will increase in the
future cake can be made to cope better by a simple edit and recompile.
Best Regards
Sebastian
>
> - Jonathan Morton
>
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
