Subject: Re: [Ieprep] any commercial usage for "emergency QoS"?

From: Scott Bradner <[email-masked]>
Date: Wed, 27 Nov 2002 07:42:04 -0500 (EST)

some additional info on the diffserv (TOS) marking question

some routers can be used to do the following
	1/ change DSCP on packets entering ports from non-trusted
	   customers (or customers who have not purchased a 
	   speciifc service) to 000000

	2/ on ports connected to "trusted" customers
	   selectively change the DSCP on an incoming packet
	   e.g. reset code points 111000, 110000 and 101000 to 000000
		(these are the codepoints used for routing and 
		management in some ISPs)
	   and change all DSCP values not part of the service ofering
	   to 000000 but do not change (or map to non-zero values)
	   the DSCPs which are part of a service offering

	3/ rate limit traffic, on a per-DSCP per-customer basis
	   for traffic from trusted customers who have purchased
	   a different-than-best-effort service

It appears to me that the DOS opportunities are reduced in such designs

i.e. the router tools to do useful things are present

but, the fact that some routers can support such a system does not,
by itself, show that such a system could be easily operated or that it
is totally safe - the operations systems to control the router
configs might be more fun to use than I'd want to have and in
the simple case, the different-than-best-effort traffic has
to be small enough so that no convergence of such traffic 
will overload the smallest backbone link (since the above
scenario does not include doing destination-specific rate 
control it is not possible to know what internal paths the
traffic will take.

making this scenario work in a multi ISP environment would also
be "fun"

Scott
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: David Meyer <[email-masked]>
Date: Wed, 27 Nov 2002 08:29:34 -0800

>> It appears to me that the DOS opportunities are reduced in such designs

	s/are/might be

>> i.e. the router tools to do useful things are present

	The problem is really equivalent to ingress filtering for
	customers, but there is no really good analogy there for
	peers. That is (in part) where the problem really resides
	(at scale).  

>> control it is not possible to know what internal paths the

	Again, the problem is that while all of this mechanism
	exists (along with quite a bit more), you can do none of
	this in the core of your network if you expect to (i). be
	able to operate it, and (ii). expect to be able to scale
	it.  

>> making this scenario work in a multi ISP environment would also

	Oh, yes, that too. Global coordination/conservation ToS
	bits? Have you tcpdumped on your local LAN lately? What
	bits does scp set, for example (rhetorical...
	% tcpdump | grep -i tos)?  

	BTW, what do I do if I have a customer who wants her ToS
	bits preserved across peerings? Do I need a service that
	is "ToS-bit invariant" now? Do I need another SLA that
	states that I won't touch fields X,Y and Z in a
	customer's IP header? What if I encapsulate the packet?
	You can see that this is going to quickly spiral out of
	the tractability space. 

	Dave

---

From: Scott Bradner <[email-masked]>
Date: Wed, 27 Nov 2002 11:34:32 -0500 (EST)

dmm sez:

yup - multi-ISP cases are not usefully covered

dmm also sez:
	Again, the problem is that while all of this mechanism
	exists (along with quite a bit more), you can do none of
	this in the core of your network if you expect to (i). be
	able to operate it, and (ii). expect to be able to scale it.  

I think there is a real issue here and it would be good to know if
anyone has tried anything like this

dmm goes on to say:

educate the customer? (and don't sign the SLA)

Scott