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

From: "Black, David" <[email-masked]>
Date: Thu, 2 Jul 2015 00:32:40 +0000

<WG chair hat OFF>

> - work on a scavenger class standard needs to be done in a
>   separate draft.

And here's what that draft might encompass ...

  Beyond that, I'd support a (hopefully short) draft that
	- updates RFC 3662 to change the recommended DSCP for the LE PHB
		from CS1 to 000010,
	- recognizes and allows for continued use of CS1 where deployed, and
	- updates other RFCs (e.g., 4592, 5127) accordingly as needed.

As Brian pointed out, this would need to be a standards track draft with
a downref to RFC 3662 in order to allocate that DSCP.

Writing the draft is straightforward by comparison to figuring out whether
this is what we should do, as indicated by the other messages in this
thread on operator/operational considerations.

This item is on the draft tsvwg agenda for Prague as a discussion topic - I
plan to bring slides and only write the -00 draft after I've survived that
discussion ;-).

</WG chair hat OFF>

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, June 29, 2015 4:51 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tsvwg] draft diffserv-intercon: Handling of a scavenger class /
> CS1
> 
> 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:[email-masked]]
> Gesendet: Montag, 29. Juni 2015 09:38
> An: Geib, Rüdiger
> Cc: [email-masked]
> Betreff: Re: AW: AW: AW: [tsvwg] draft diffserv-intercon: Handling of a
> scavenger class / CS1
> 
> On Mon, 29 Jun 2015, [email-masked] 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: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Jul 2015 09:17:45 +0200 (CEST)

On Thu, 2 Jul 2015, Black, David wrote:

> This item is on the draft tsvwg agenda for Prague as a discussion topic 
> - I plan to bring slides and only write the -00 draft after I've 
> survived that discussion ;-).

I have just now sent an email to the nanog (North America Network 
Operators Group) mailing list, asking for feedback and input to raise 
awareness that this is being discussed. I will sum up the resulting (if 
any) discussion ahead of the upcoming IETF meeting. If there is no 
discussion, then we know that there is little interest :)

Any resulting discussion can be followed on 
http://mailman.nanog.org/pipermail/nanog/2015-July/thread.html#77040 or by 
subscription to the nanog mailing list (it's open to anybody).

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 02 Jul 2015 16:41:40 +0200

Hi Mikael,

Am 29.06.2015 um 09:37 schrieb Mikael Abrahamsson:
> 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.

Normally, RFC 4594 (https://datatracker.ietf.org/doc/rfc4594/)
defines many of such aspects, however, mainly conceptually, not
by concrete network gear and focusing on a single DS domain.

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

RFC 3662 (https://datatracker.ietf.org/doc/rfc3662/) normally gives
enough hints how to implement a lower effort (LE) PDB. A simple priority
scheduler and two queues are sufficient to support LE and BE
(Best-effort). The good thing is that you don't need any traffic
conditioning
mechanisms in place, thus not much configuration required, except for
the queue, scheduling and DSCP classifier.

> 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 basic concept of DiffServ is intentionally held very flexible and
every operator may do his own things. However, if the implementations
are very different, services may become inconsistent across different
DS domains, i.e., within a DS region. Therefore, recommendations for
some of those behaviors would be good.

> 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?"

DiffServ depends very much on the correct operation of the boundary
nodes, i.e., they represent a trust boundary. For example, EF requires
admission control prior use and if this is missing, but EF traffic
enters a DS domain, violations of SLAs may follow.

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

Yes, because DS boundary nodes are located at the trust boundaries and
thus need to enforce a provider's policies. If two DS domains trust each
others markings (and thus policing at their respective boundaries), then
there is no need for bleaching/remarking to other PHBs.

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

The very good thing about Lower Effort traffic is that it does no
harm to ordinary BE traffic. That was one of its design goals. So
letting in LE traffic is "always safe", no requirement for bleaching.
More precisely, LE traffic from domain A may affect LE traffic within
domain B while traversing it, but it will never cause harm to BE traffic
carried in domain B. Moreover, LE traffic is also quite well suited to
fill up any protection/overprovisioned capacity.
The currently problem is the ambiguity of using CS1 as DSCP for LE.
If CS1 is handled as in RFC 2474, it may adversely affect BE traffic,
if CS1 is handled as in RFC 3662 there shouldn't be any problem.

Regards,
 Roland

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 02 Jul 2015 17:02:03 +0200

Hi,

>> - work on a scavenger class standard needs to be done in a

...and as one of the original RFC 3662 authors I'd be happy to work on
it, too.

Regards,
 Roland

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 17 Jul 2015 11:28:36 +0200 (CEST)

On Thu, 2 Jul 2015, Mikael Abrahamsson wrote:

> http://mailman.nanog.org/pipermail/nanog/2015-July/thread.html#77040 or 
> by subscription to the nanog mailing list (it's open to anybody).

There were very few public email, I received a few email offlist that 
voiced the concurring opinion that 000xxx was probably the most likely 
codepoint to be incrementally deployable.

However, my take is that not a lot of people are interested in this, but 
the few people that replied were also of the opinion that accepting 
anything outside of 000xxx from "The Internet" is a bad idea if one runs 
QoS internally.

So I don't see a huge amount of interest in this, but if we present a 
draft and propose something a bit more concrete, this might change.

---

From: "Black, David" <[email-masked]>
Date: Sun, 19 Jul 2015 21:01:35 +0000

Mikael - thanks for doing this; the information, including level
of interest, is useful.

There's a scavenger class item on the TSVWG Thu agenda - the
purpose is to discuss whether this ought to be done (or not).

Thanks,
--David

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Friday, July 17, 2015 5:29 AM
> To: Black, David
> Cc: [email-masked]