Is anyone actually USING IP QoS?
alan at globalcenter.net
Mon May 17 08:25:19 UTC 1999
> I'm particularly interested to know if the famed replacement
> of ATM QoS features (basic stuff, like prioritization,
> traffic policing and traffic shaping, sustained and peak
> rates) has happened in a native IP network (ie POS or IP
> over PtP circuits), particularly one that runs multiple
> services (like some real-time stuff like voice, video,
> streaming, and some non-real-time stuff).
Most all IP networks run 'multiple services'. We run IP networks,
we don't pay alot of attention to what's in the packets.
In my network, I use NetMeeting for video and real-time
collaboration, and several customers use our IP backbone for VOIP
transit. Additionally, we do VOIP testing within engineering and
with our telco brethren.
The question is what levels of service, what different levels
of service does the IP network offer.
Today, so far as I know, no IP network offers different levels
of service based on the customers choice.
Soon, many will.
See, it's not about setting different QOS on different traffic
It's about setting relative or objective QOS on different services
or products, in exchange for offering value or collecting revenue
from the customer.
> There have been a lot of announcements and rumors about this
> kind of stuff (like Enron Communications PureIP network,
> Convergent's fully-Cisco [possibly L3] network, Level3's
> IP-only network, etc),
Enron may be building a pure IP network, but Level3 is not
running one at this time.
Add to that list DIGEX, QWEST, WILLIAMS, FGC, and others...
> The presentations I've seen about QoS implementations have
> all seemed to contain major sections about how the networks
> had to work around problems or scale back the implementation
> because of resource limitations (CPU, memory, etc).
Primarily CPU and Queue Management.
> seen anyone implement RSVP on a wide scale,
Several have, but not for customer use, for backbone
traffic engineering and end-point-pair constrained routing.
> due to similar
> types of problems. Sounds like QoS is marketing material,
> not the stuff networks are built on. Is that still the case?
I don't think so. We use TOS fields and WRED to implement
early field trials of QOS. Set at entrance, arbitrate within
network and at egress.
We've used this to help solve many engineering problems, but not
to sell different services to customers.
You see, customers don't like knowing that there is congestion in
the network. And lately w/ big pipes we haven't had much
congestion, so there's very little 'lack of resources' to
allocate to folks.
Now, inter-provider QOS is a big deal, but it's going to a
generation behind the VPN / backbone QOS introduction.
> How the heck are people able to deploy native-IP networks
> with these kinds of limitations/problems with QoS? Or did I
> miss something about QoS recently?
I think what most people miss here is the assumption that
they will be able to dynamically construct source-destination
paths with granular QOS.
You won't have the tools to build your own private idaho
on a minute by minute basis.
IP networks are not about that, yet.
Instead, what people can expect in the next 3-18 months are
variable levels of service, wherein a user may subscribe to 1 of 8
QOS levels, or 4 QOS levels, with in-and-out of profile classes.
So, the typical example we use is:
Gold - premium
Silver - high quality
Bronze - best effort
Latency - no delay
To achieve Latency class, the routers must have multiple queues
and be able to schedule between them.
So, 'RT' [real time] applications are not readily available on most
IP networks, unless the RT applications can tolerate some
latency, which most can.
To achieve G,S,B, you just need a relative prioritization, like
Now, for more practical matters, the tools, and horsepower [cpu,
ram] exist in some router vendor products to set TOS bits on
entry, and arbitrate relative priority with WRED within the
Yes, it takes big new cards [1 year old], but it absolutely can be
Another issue that many folks look at is if you do an objective
src-dest pair path with a given quality of service, or if you
arbitrate based on the what is admitted to the communal network.
Kind of the ATM v. FR debate. Which is used more today? And when
folks use ATM, do they do anything nifty with it, or just run ABR,
which is really fast FR.
MPLS is a large component of this.
Consider Frame Relay. Frame Relay does 3 simple things:
* classifies traffic by DLCI/Source pairs
* source-routes traffic through an abstracted path
* marks and reacts to frames as in profile or out
of profile [DE bit set].
With MPLS and TOS, we can mimic Frame Relay down to the wire.
How long do you think it will be before IP networks are carrying
Frame Relay PVCs?
Or better yet, selling Frame Relay Like services over native IP using
But they don't yet. Because there's more to the game than just
having the tools. Some bugs have to be worked out. Limitations
have to be learned. Systems have to be built to support new
paradigms. Marketing folks have to find ways to integrate the
products into the existing pool. Sales and ops folks have to be
But that doesn't take too long :-)
More information about the NANOG