<p dir="ltr">> We were on the verge of enabling it on our (the UUNET) end when<br>
Louis Mamakos identified the fundamental show-stopper to doing it.<br>
><br>
> It gives DOS attacks nuclear weapons.<br>
><br>
> Simply set the DOS packets to the highest priority and pound away.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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).</p>
<p dir="ltr">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.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>