Is anyone actually USING IP QoS?

Alan Hannan alan at globalcenter.net
Mon May 17 08:25:19 UTC 1999


  Howdy,

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

  Yes.

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

  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.

> Haven't
> 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
  WRED.

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

  Yes, it takes big new cards [1 year old], but it absolutely can be
  done.

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

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

  But that doesn't take too long :-)

  -alan





More information about the NANOG mailing list