Cell Relay Archive

[albert.e.manfredi@boeing.com]

Hi Ruth, I'll add to what Praveen already said, trying to address
individually each of your questions.

In article <35694183.72ED@enternet.com.au>,
  rpm@enternet.com.au wrote:
>
> Hi,
>
>  I was wondering if you could help me.  I have a few questions about
> QOS, such as
>      What are the problems the existing Internet causes for these media
> types?
>      How does QOS help alleviate these problems?

I assume you're asking here what is it that Internet is doing that might be
helped by some stricter quality of service criteria?

The Internet now is mainly used for transferring non-time-critical data. For
example, to send ASCII characters over a digital link, you don't really care
precisely how much gap might exist between characters. You'll still end up
with words eventually, within reasonable time limits.

In fact, TCP connections do time out in a minute or so, so even the Internet
has some implicit QoS requirements, but they are very loose and free compared
to what other types of signal transfers need.

So if anything but data transfer is to be conducted over the Internet, new
mechanisms will have to be added. Or a different type of underlying network
would have to be used. Some people believe that all you really need is gobs
of excess capacity in that underlying network, and all problems with QoS
become moot.

>      What are the main QOS implementations?

I'd say clearly the "main" QoS implementation is the telephone. Telephones
must provide very tight tolerances in the transfer of audio samples to permit
for intelligible digital to analog conversion, and must do so without
incurring overall latencies greater than some 150 milliseconds, max. Anything
greater than that makes interactive communications very uncomfortable. So
what I'm saying is that merely buffering a bunch of voice packets arriving at
random and long intervals won't cut it. If you measure the packet delays in
Internet packets sent cross country or around the world, you will find plenty
of examples where latencies often or always exceed 150 msec.

>      What alternative solutions exist that don't rely on QOS
> mechanisms?"

Buffering of data is the main mechanism. If packet arrivals are haphazard, as
they typically are over the Internet, then one can create a large bucket to
receive these packets, and then carefully let the packets out of the bucket
at the steady rate one requires. But this is obviously not a perfect
solution. For one, it creates delay because it depends on having enough in
that bucket so that you can span those crazy arrival inconsistencies. For
another, sooner or later that bucket will either overflow (if you have a
particularly long period of fast arrivals) or it will empty out and leave you
high and dry (if there's a long period when packets didn't arrive).

Another avenue is to establish reserved paths within the existing Internet,
by introducing special routers for this purpose. But this solution is really
nothing more than trying to make the packet-switched Internet into a
circuit-based structure as the telephone network is. This would be RSVP, the
Reservation Protocol.

Another approach is to streamline the way Internet packets are routed. Again,
sort of a hybrid between Internet and telephone schemes, this "IP switching"
solution uses the first packet of a connection to find the route, but then it
labels each subsequent packet of the connection so that (a) the same route
will be used for the entire session, and (b) the routers along the way will
use only a small number of bits to decide where to route the incoming
packets. This would be MPLS (Multi Protocol Label Switching).

> Can you possibly direct me to some answers either available on the
> interent or just from your knowledge.

Using a search engine, you can find documetns describing both RSVP and MPLS
at the IETF web site.

Bert
manfredi@arl.bna.boeing.com

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading