Is anyone actually USING IP QoS?

John Leong johnleong at research.bell-labs.com
Mon May 17 22:55:34 UTC 1999



One big problem with QoS is that most application programmer have no
clue as to how to specify QoS related parameters.  A few years ago, when
I put on my application programmer's hat [pretending I had an MPEG-1
stream to pump out] and looked at the ATM UNI 3.0 specification, I found
that (a) I could not really understand the meaning of roughly 1/4 of the
parameters and (b) for many of the parameters I understood, I was not at
all sure what  were the appropriate values to use.

In general, most of the multi-media stuff uses some sort of compression
algorithm.  Unless one have a good understanding of the nitty gritty of
the algorithm, one would be somewhat hard pressed to set values. For
pre-generated pre-compressed material, one can at least run the material
once and monitor its network characteristic.  However, translating those
characteristic to jitter control parameters is still non-trivial.  With
real time compression, the challenge is much trickier.

So, if the application programmers have a hard time specifying QoS
......

Non application based QoS may be more practical.  Hence if I pay for a
3Mbps service from my ISP, I want to ensure that I can get 3Mbps from my
end of the pipe to any edge of the ISPs backbone.  I will be a bit
annoyed if the 3Mbps is only between my end of the pipe to a totally
over subscribed and under provisioned POP!  If my ISP have a real
meaningful SLA with me, I suspect they will being doing real traffic
engineering in their access and backbone routers to support the
contracted QoS.  That could be relatively straight forward as long as
the QoS parameters are not too funky (definitely no mention of jitter).

Another related type of QoS that is more practical and likely to be done
is relative QoS in the form of if I have a 3Mbps pipe to the ISP, the
CEO is going to get preferential service to the mail room clerk etc.
Such QoS does not seem to be too complex to do at the CPE edge router,
again, as long as one does not try to get too fancy and as long as it is
relative.

Regards,
John Leong

--
---------------------------------------------------------
Bell Labs Research       johnleong at research.bell-labs.com
4995 Patrick Henry Dr.                  Tel: 408-567-4459
Santa Clara, CA 95054                   Fax: 408-567-4448






More information about the NANOG mailing list