From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Fri Oct 17 2003 - 21:17:48 GMT-3
Jason,
To thoroughly understand QoS we first need to define two terms,
the output queue and the transmit ring. The output queue is a buffer
the router uses to hold a packet while it is waiting to be transmitted.
The time a packet spends in the output queue depends on the depth of the
queue as well as the QoS mechanisms being applied to the output queue.
The transmit ring is the last stop for traffic before it is encapsulated
on the interface. The maximum time a packet sits on the transmit ring
is always constant, and is proportional to the size of the hardware
queue as well as the serialization delay of the interface.
When the router goes to send a packet it checks to see if the
transmit ring is empty. If the transmit ring is empty, the packet is
encapsulated on the wire and sent. When this is the case, the only
delay that the packet endures is the serialization delay. If the
transmit ring is not empty, the packet is placed in the output queue,
and waits to be sent to the transmit ring. Depending on the QoS
mechanism applied, excess delay may be introduced as a packet sits in
the output queue waiting to get onto the transmit ring. Keep in mind
that although these delays are very miniscule in our terms, a few extra
milliseconds of delay can quickly add up on the end to end path for a
packet, and can be crippling for real time applications such as voice
and video.
The serialization delay is a function of the physical clock of
an interface, and dictates how fast the router can actually encapsulate
and send traffic on the line.
Let's assume that we have a full T1 circuit of 24 DS0's. At
64Kbps each of these channels give us an effective bandwidth of 24 *
64Kbps = 1536Kbps (*Note: when speaking in terms of a T1, the effective
bandwidth is 1.536Mbps, *not* 1.544Mbps)
Based on the interface clock, we can now determine how long it
will take to send a particular packet. Let's say that we have an IP
packet which is 1500 bytes. The time it takes us to transmit this
packet is as follows:
1500 bytes | 8 bits
-----------|-------- = 12000 bits
| 1 byte
12000 bits | 1 second
-----------|------------- = 0.0078125 seconds
| 1536000 bits
0.0078125 seconds | 1000 milliseconds
------------------|------------------- = 7.8125 milliseconds
| 1 second
As we can see from the above calculations, it takes about 8ms to
send a 1500 byte packet on a T1 interface.
From you're example, let's say that we have 200Kb of FTP traffic
and 512Kb of video traffic to send out this T1 interface. Together,
these two traffic flows equal 712Kb, which we can easily transmit in
under one second since our interface is clocked at 1536Kbps. Assume
that the FTP traffic arrives in the output queue before the video
traffic.
Since the FTP traffic arrived in the output queue first, all FTP
traffic must be sent before any video traffic can be sent. This FIFO
behavior holds true when there are no QoS mechanisms applied to an
interface. Now let's calculate how long the video traffic will have to
wait before being sent.
First let's convert FTP value into bytes to be consistent:
200000 bits / 8 = 25000 bytes of FTP
Next let's see how long it takes to send the FTP:
7.8125 ms | 25000 bytes
-----------|------------- = 130ms
1500 bytes |
From the above calculation, we can see that video traffic will
have to wait 130ms before it can be sent. For a real time application,
this type of delay is unacceptable. This is where the low latency queue
(LLQ) comes in.
When LLQ is applied, all traffic up to the defined bandwidth in
the LLQ automatically goes to the head of the output queue. Let's take
the above scenario again, but this time let's apply the LLQ to the video
traffic.
The FTP traffic arrives in the output queue first, and the first
packet is sent to the transmit ring. Immediately after the FTP arrives,
the video traffic arrives. Since the FTP packet is already on the
transmit ring, the minimum delay that the video packet must endure is
the serialization delay of the FTP packet. Assuming this packet has the
max size of 1500 bytes, the worst case scenario for the next video
packet to be sent is only ~8ms instead of 130ms.
In addition to this, since there is always a bandwidth cap on
the video traffic in the LLQ, the FTP traffic is guaranteed that it will
not starve.
If you're still reading this, I hope that clears it up a bit.
Two very good books to read on this subject are: "Inside Cisco IOS
Software Architecture" and "Integrating Voice and Data Networks" both
from Cisco Press.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 708-362-1418 (Outside the US and Canada)
> -----Original Message-----
> From: Kleberg, Jason [mailto:JKleberg@glhec.org]
> Sent: Friday, October 17, 2003 5:02 PM
> To: 'Brian McGahan'
> Subject: RE: Videoconferencing over IP
>
> I am by no means doubting you. But if it was a 1.54 link speed and
there
> was 200k ftp, 100k web and 512 video, could queuing still help this?
If I
> have a basic concept wrong I really need to know,, and since you are
the
> uber cisco guy, I figure it should be from you :-)
>
> -----Original Message-----
> From: Brian McGahan
> [mailto:bmcgahan@internetworkexpert.com]
> Sent: Friday, October 17, 2003 4:58 PM
> To: 'Kleberg, Jason'; 'Jung, Jin'; Vazman@aol.com;
> ccielab@groupstudy.com
> Subject: RE: Videoconferencing over IP
>
> Jason,
>
> This is assuming there is literally *no* other
> traffic on the
> line. If the video application is really the *only*
traffic
> on the
> line, then QoS will not help. If that is so it's either
a
> higher layer
> (application) problem or a lower layer (physical)
problem in
> this
> particular case.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Direct: 708-362-1418 (Outside the US and Canada)
>
>
> > -----Original Message-----
> > From: Kleberg, Jason [mailto:JKleberg@glhec.org]
> > Sent: Friday, October 17, 2003 4:47 PM
> > To: 'Brian McGahan'; 'Jung, Jin'; Vazman@aol.com;
> ccielab@groupstudy.com
> > Subject: RE: Videoconferencing over IP
> >
> > Maybe I am missing something very fundamental here,
and if
> I am please
> > forgive my ignorance, but I still don't understand
how
> any type of
> qos
> > will
> > help if there is no congestion? Here is a quote from
the
> cisco qos
> pdf
> > p121,
> >
> > "During periods with light traffic, that is, when no
> congestion
> exists,
> > packets are sent out the interface as
> > soon as they arrive.
> > "
> >
> > How can qos speed change this, that is make it go
faster
> than "as soon
> as
> > they arrive"?
> >
> > Thanks
> > jason
> >
> > -----Original Message-----
> > From: Brian McGahan
> > [mailto:bmcgahan@internetworkexpert.com]
> > Sent: Friday, October 17, 2003 4:28 PM
> > To: 'Kleberg, Jason'; 'Jung, Jin';
> Vazman@aol.com;
> > ccielab@groupstudy.com
> > Subject: RE: Videoconferencing
over
> IP
> >
> > Jason,
> >
> > Priority queues such as the
legacy
> priority-list,
> > the low
> > latency queue (LLQ), and IP RTP priority
are
> constantly
> in
> > effect
> > regardless of a congestion condition.
The
> preferred
> method
> > to solve the
> > aforementioned problem is the LLQ.
> >
> > LLQ guarantees that all packets
in
> the priority
> > queue are
> > dequeued first up to the configured
> bandwidth value.
> When
> > packets in
> > the priority queue exceed the configured
> bandwidth and
> there
> > is not
> > congestion, excess packets are sent but
not
> guaranteed
> low
> > latency.
> > When the configured bandwidth is
exceeded
> and there is
> > congestion,
> > excess packets are dropped. For this
> reason, the LLQ is
> > considered a
> > 'maximum' bandwidth guarantee. This
offers
> a large
> > advantage over the
> > legacy priority queue since your
> non-priority traffic
> cannot
> > be starved
> > of bandwidth.
> >
> > The IP RTP priority queue is
> effectively legacy
> > because you get
> > the same effect by issuing the 'match
> protocol rtp'
> command
> > in a
> > class-map and putting this class into
the
> priority
> queue.
> > Furthermore,
> > you can configure an access-list in
tandem
> which matches
> > ranges of UDP
> > ports.
> >
> > Vazman, try putting the video
> traffic in the LLQ
> as
> > suggested
> > and see if this helps. If not, maybe
there
> is some
> trouble
> > in the
> > provider cloud with your circuit.
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987
> > Direct: 708-362-1418 (Outside the US and
> Canada)
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]
> > On Behalf
> > Of
> > > Kleberg, Jason
> > > Sent: Friday, October 17, 2003 6:33 AM
> > > To: 'Jung, Jin'; 'Vazman@aol.com';
> ccielab@groupstudy.com
> > > Subject: RE: Videoconferencing over IP
> > >
> > > Why LLQ if there is no congestion? I
> think more
> people
> > could help if
> > the
> > > configs were posted. And if possible,
some
> traffic
> > history. IS there
> > a
> > > preferred method of QOS for this?
> > >
> > > thanks
> > > jason
> > >
> > > -----Original Message-----
> > > From: Jung, Jin
[mailto:jin.jung@lmco.com]
> > > Sent: Friday, October 17, 2003 6:25 AM
> > > To: 'Vazman@aol.com';
> ccielab@groupstudy.com
> > > Subject: RE: Videoconferencing over IP
> > >
> > >
> > > You need some sort of QOS enabled on
your
> T1,, I used
> LLQ,
> > which seems
> > to
> > > be
> > > working.
> > >
> > > Also, check you frame per second fps
on
> your Video Con
> > unit, I know
> > some
> > > PictureTel only support 15 fps,, You
need
> to use
> minium 30
> > fps.
> > >
> > > Jin Jung
> > > CCIE#12386
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Vazman@aol.com
> [mailto:Vazman@aol.com]
> > > Sent: Friday, October 17, 2003 2:05 AM
> > > To: ccielab@groupstudy.com
> > > Subject: Videoconferencing over IP
> > >
> > >
> > > Hello,
> > >
> > > Does anyone have any experience with
using
> video
> > conferencing over IP
> > > (point-to-point or FR). We have a T1
> between two sites
> > with a
> > PictureTel
> > > on
> > > each end. There is harldy any other
> traffic on the T1
> but
> > the quality
> > of
> > > the
> > > video is not soo good (jitter etc).
Audio
> has good
> > quality.
> > >
> > > Thanks
> > >
> > >
> >
> >
>
>
This archive was generated by hypermail 2.1.4 : Mon Nov 24 2003 - 07:53:04 GMT-3