Re: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1

[<[e-mail]>]

Hi Mikael,

ok, understood, I'm relaxed.

The relation of Diffserv intercon to scavenger is

- if there is a scavenger class, how should Diffserv intercon handle it 
  (will add text about a 000 xx0 DSCP)? Otherwise Diffserv Intercon 
  says, bleaching may occur for any unexpected DSCP.

- work on a scavenger class standard needs to be done in a 
  separate draft. That's WG consensus and Gorry Fairhurst said during 
  the last meeting:
  "Scavenger support document been discussed before, if there is 
  renewed interest, then we should take it up again. 
  As an individual contributor, I would be interested. 
  If you are also interested in this topic, please talk to the 
  WG chairs."

- operational issues may be relevant for a bleaching discussion. 
  A bleaching standard is out of scope of Diffserv Intercon (thats 
  WG consensus). I think to recall interest in work on bleaching 
  by others too.

Then I'm happy to meet you in Prague. 

Regards,

Ruediger 

-----Ursprüngliche Nachricht-----
Von: Mikael Abrahamsson [mailto:[e-mail]] 
Gesendet: Montag, 29. Juni 2015 09:38
An: Geib, Rüdiger
Cc: [e-mail]
Betreff: Re: AW: AW: AW: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1

On Mon, 29 Jun 2015, [e-mail] wrote:

> I repeat that I've talked with my RIPE/NANOG colleagues to get 
> feedback
> - they came back only with one or two names with whom to discuss QoS 
> interconnection. And I never got any useful response (positive or
> negative) from those.

This is the problem, that's not how to do this, the way to do this is to announce an idea on the nanog mailing list and see who might be interested.

As far as I read your document, it has nothing in it about how to incrementally get an Internet-wide scavenger class operationally deployed over time. To me it reads more like a document for business VPN Carriers-Carrier services style interconnect/interworking. It has no operational advice at all in it on how to deal with DDoS, how to configure access equipment, how to set up queuing strategies on different kinds of equipment, listing what equipment might do what, etc.

I suggested how to actually make this incrementally and widely deployable across the world, and that is to aim for a 000xxx style scavenger class. 
This seems to not work for some reason that is unclear to me, your document doesn't seem to be operational at all, it doesn't propose something that is operationally deployable on the wider Internet, so that's why I think we would need another document for this purpose. If that is not a goal we can agree on, then there is no need to write one.

So just to sum up: I'm sure your document is fine for what it intends to do, it just doesn't answer any of the concerns an IP network engineer/architect might have about implementing this on an Internet peering link where there is little or no control over what traffic will pass or what this traffic might do to the rest of their network. It suggests a way to do something with no operational analysis or risk mitigation at all.

The first thing that will pop into any good IP architects head nowadays will be "oh, what happens to my network when I get 200 gigabits/s of 64 byte packets marked EF from that 5 million strong DDoS-drone network all across the world, aimed for my customer base?"

The answer to that is "I'll bleach DSCP it because that's the only way to handle it". So in order to get a scavenger class actually deployable, you have to come up with something that means they can relax the bleaching a little bit by some operators, but their infrastructure would still treat the traffic the same. You also have to take into account that a lot of core IP network equipment can't do DSCP mapping very well. This kind of functionality makes equipment more expensive and thus less likely to exist widely.

--
Mikael Abrahamsson email: [e-mail]