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

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

[Mike O'Dell]

Sigh.....

The most sophisticated QoS mechanism ever deployed in any
material manner is the one which was ATM's raison d'etre.

And ya know what? IT WASN'T USED! 
well, it was used a little - to give real-time video the goose
over IP traffic in certain USG networks, but that was only TWO
classes of service. 

I was at the meeting where DiffServ was invented and it was *NEVER*
imagined for an instant that only a very small number of the bit
patterns made any sense at all. Why? Because the ability to make
the network behave differently is profoundly limited.

However, at UUNET we decided that for most customers, the customer
tail was the fundamental source of congestion. Hence, if we honored
Diffmarks in the customer direction on the tails, the customer's
site border router could honor them in the ISP direction and
we'd find out quickly how much good it really does. We understood
that it only worked on-net, but it was relatively easy to try.

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.
The Diffserve model doesn't include any fairness guarantees,
certainly the router implementations at the time didn't provide them
and it isn't clear how that should work depending on how one
interprets the Diffmarks.

Note that if the ISP network is large, ingress source address
filters don't do any good. There's plenty of room to have a botnet
able to crush things all of it "on net".

The fundamental problem with doing anything to police traffic in
the customer-bound direction is that it requires imputing the
desire of the customer to receive each and every packet.

I haven't heard of any scheme for the requisite mind-reading
which is implementable and doesn't contain the seeds of 
its own destruction by adversarial manipulation. 
	  
So I have serious heartburn with Diffserv fundamentally.
The notion that there could ever be that many different
viable QoS flavors is, in my opinion, completely *absurd*.

So, if you wanna try to do it in the ISP-bound direction,
    Party on, dudes! 

But don't expect much from the effort.

    Harumph
    -mo

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

[Jonathan Morton]

[-- 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 --]

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

[Mikael Abrahamsson]

On Sun, 19 Jul 2015, Jonathan Morton wrote:

> 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.

I had an idea of using DSCP 000xx0 and have a BE+, BE and BE-. BE+ would 
be scheduled to send packets twice as often as BE, and BE- would be 1/10th 
of (BE+ BE).

I keep getting pushback from the DSCP authors that he BE- idea wouldn't be 
a problem (and they agree that it makes sense for a scavenger class), but 
that my idea of BE+ should be something else, for instance AFxy. I don't 
believe anything that isn't 000xxx will ever get widely deployed for 
Internet use, and there should be no strict priority but just a slight 
preference for scheduling packets with the BE+ code point, exactly to make 
DDOS less of an impact.

What is your opinion on this concept?

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

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

[Jonathan Morton]

> On 20 Jul, 2015, at 10:17, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> On Sun, 19 Jul 2015, Jonathan Morton wrote:
> 
>> 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.
> 
> I had an idea of using DSCP 000xx0 and have a BE+, BE and BE-. BE+ would be scheduled to send packets twice as often as BE, and BE- would be 1/10th of (BE+ BE).
> 
> I keep getting pushback from the DSCP authors that he BE- idea wouldn't be a problem (and they agree that it makes sense for a scavenger class), but that my idea of BE+ should be something else, for instance AFxy. I don't believe anything that isn't 000xxx will ever get widely deployed for Internet use, and there should be no strict priority but just a slight preference for scheduling packets with the BE+ code point, exactly to make DDOS less of an impact.
> 
> What is your opinion on this concept?

I could add support for, say, DSCP 000110 mapping to the Background class with one line of code in Cake; that would give it the same treatment as CS1 currently gets.  The legacy TOS codepoints 000001 and 000100 (Low Delay and High Reliability) already map to the Video class; I’ve deliberately left 000010 (High Throughput) in the Best Effort class.

In effect, that would give very similar behaviour to what you suggest.  Assuming the link is saturated with all three classes of traffic, three-quarters of the bandwidth would be dedicated to the Video class, three-quarters of the remainder would be Best Effort, and just one-sixteenth would be Background.

Additionally, there is already *some* traffic routinely using CS6 (eg. NTP) and EF codepoints, which I think are relatively well-established as “low throughput, low latency” indicators.  Those both go in the Voice class in Cake, which is thresholded at one-quarter of the link.  If all four classes are saturating the link, that would just reduce the Video class’s share to one-half instead of three-quarters, leaving the remaining two classes alone.

More generally, using unconditional strict priority for anything is a Very Bad Idea - as noted, it’s just too easy to abuse.

 - Jonathan Morton

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

[Mike O'Dell]

I can tell you with perfect knowledge that there was
*nothing* close to an implementation when DiffServ
was hatched. It was an exercise of "lay claim to some
bits that can encode a simple model and pray for rain".

     -mo