From: Jung, Jin (jin.jung@lmco.com)
Date: Fri Oct 17 2003 - 21:39:39 GMT-3
Wow Very nicely done,, Brian,,,
Just add one more thing for Vazman,,
I have found that video of IP adds about 40k to 80k overhead on top of
normal 384k,,
When I was testing Streaming video using IPTV, total packet for video over
IP was more like 420k to 460k.
SO when you are configuring LLQ, keep this in mind and give enough bandwidth
to video of IP packets.
If you can that is...
Jin jung...
CCIE 12368
-----Original Message-----
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: Friday, October 17, 2003 8:18 PM
To: 'Kleberg, Jason'; ccielab@groupstudy.com
Subject: RE: Videoconferencing over IP
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