Subject: Re: [Ieprep] AF for Elastic Traffic

From: Fred Baker <[email-masked]>
Date: Mon, 29 Apr 2002 16:32:41 -0700

At 05:28 PM 4/29/2002 -0500, Beard, Cory wrote:
>What other ways could a service provider provide an acceptable ieprep 
>solution for web browsing (or other types of elastic applications that 
>involve user interaction) without using AF?  Overprovisioning is one, as 
>long as they can show that the overprovisioning will persist even in high 
>traffic conditions after a disaster.  Anything else? None readily come to 
>mind for me.
>
>Do we have a clear dividing line when it comes to supporting interactive 
>elastic traffic?  Either a provider heavily overprovisions and does not 
>turn on diff-serv, or they use AF?

The fundamental assertion being made in this context is that it is possible 
for there to be so much traffic that any level of overprovisioning can be 
overwhelmed, and at that point one has to decide what one will do. That is, 
I think, a true statement; the question is what is feasible, or is a 
realistic response to a credible threat.

Personally, I think service provider overprovisioning is more than adequate 
in the cores of their networks. Some service providers say, for example, 
that they have deployed a network would is ~2% utilized; many and perhaps 
most say that their interfaces average something on the order of 10% 
utilization. They all tell us that in recent examples of "Internet under 
crisis", this level of overprovisioning has been more than adequate. So I 
don't expect the service providers to increase their level of 
overprovisioning based on the outputs of this working group.

Where I routinely have service providers asking me questions relates to 
their handling of traffic they don't feel obligated to. For example, last 
week I visited a (nameless) ISP that says that it finds a lot of Morpheus 
servers among its clients; a couple of years ago, another ISP spoke with me 
about people originating real-time video. Now, such ISPs SLAs to their 
customers is that they can only originate some specific rate, and (unless 
they pay for such a service) they are not supposed to run servers. A PC 
running a Morpheus server is acting as a server, and BTW the home is 
unaware of that service. So they find themselves running various 
technologies, including classifiers that will identify and eliminate 
Morpheus traffic from their networks. But this requires them to be agile - 
if Morpheus won't work, will Gnutella?. So I advise them to meter the 
traffic originated by a customer, and mark it AFx1 or AFx2 depending on 
whether it is too fast or not, and when it gets to a point that costs the 
ISP money, drop the "excess" traffic.

The interesting issue here is that deciding to turn that on is non-trivial. 
You want it to be happening all the time, even if nothing is getting 
dropped, so that when the need arises it simply cuts in.

I will argue that the same is true for emergency use. The places where you 
are most likely to see problems is at network access interfaces. There, you 
want to have traffic marked. If the traffic normally needs no help, fine; 
if it at some point suddenly needs support, the service is there, all you 
have to do is play with the numbers to make it work. By all means, 
overprovision, but do so in a manner that you can support from a business 
perspective.

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