Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 44, Issue 24

[Jonathan Morton <chromatix99@gmail.com>]

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

> We were on the verge of enabling it on our (the UUNET) end when
Louis Mamakos identified the fundamental show-stopper to doing it.
>
> It gives DOS attacks nuclear weapons.
>
> Simply set the DOS packets to the highest priority and pound away.

I identified this problem when designing cake, and came up with a
solution:  Every request for higher priority (low latency) is also
interpreted as a relinquishment of rights over high bandwidth.

In an early version, this tenet was enforced using hard limits. This worked
as designed, but caused problems for users attempting to tune their
bandwidth setting using best effort traffic, since there was also a least
effort class below that.

In the current version, a bandwidth threshold is used instead. If the
traffic in the class remains below the threshold, then they get the (non
strict) priority requested. If it strays above, the priority is demoted
below other classes instead. In the absence of competing traffic, any class
can use the full available bandwidth, but there's always room for other
classes to start up.

None of this behaviour is specified, suggested or even identified as
desirable in the relevant RFCs. I had to invent it out of whole cloth,
after recognising that Diffserv is simply not specified in a way that can
be practically implemented, or from an implementor's point of view. The old
version of the TOS byte was much clearer in that respect - three bits of
precedence, three or four bits of routing preferences (although the latter
was also poorly specified, it was at least clear what it meant).

Frankly I think IETF dropped the ball there. "Rough consensus and working
code." I find it difficult to believe that they had working code
implementing a complete Diffserv system.

- Jonathan Morton

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