I'm new to the list so I'll do a little intro. I'm a consulting engineer
for cisco stationed in Minneapolis. Larry Dunn and I both report to the
Chief Technology Officer, Judy Estrin. In the last year, I've spent quite a
lot of my time on video/multimedia issues which of course leads one into QOS
queuing issues. Most of this work has been in the context of enterprises
rather than I2 activities so this project gave me my first opportunity to
work with the distributed queuing features of the 11.1CC or, as it's
affectionately called, the ISP geek code train.
So, now some background on the test environment. I'm using a 7500 router
with VIP based fast ethernet and ATM interfaces talking through a 1010 ATM
switch to an RSP7000 which has a VIP based ATM interface and non-VIP fast
ethernet interfaces. So in text diagram format we have:
fast E----7507----1010----RSP7000----Fast E---Indy
| | | |
Indy | | |
| | |
ethernet--- ---Ultra --------Fast E
For traffic I've got various IP/TV sourced H.261 video streams and via the
fast ethernets on either side, bi-directional 4Mb MPEG2 flows. The 7505 has
another ATM interface on which I'm using a Sun Ultra for traffic generation.
The sun is targeting two IP address, one on each of the RSP7000's fast
ethernet addresses and is sending about 120 Mbps.
The fast ethernet interfaces on either side connect to LANE ELAN's on which
there are two SGI Indigos viewing the various H.261 streams.
So the steady state transfer from 7507 to RSP 7000 is around 120 Mb and the
MPEG and H.261 flows are understandably lossy. I'm using classical IP
between the two routers on the main interfaces, distributed weighted fair
queuing, distributed weighted random early discard and, of course,
distributed Cisco Express Forwarding.
To correct the loss in the video, I turned on committed access rate to mark
the MPEG flow with some non-zero precedence. I further found that I had to
use CAR to limit the precedence zero traffic to 80 Mbps or I took too many
interface drops. Once this was done, the MPEG video stabilized and shows no
loss. I then proceeded to turn on CAR for the H.261 flows and likewise
stabilized them. Router utilization on the RSP700) was around 5% with VIP
utilization on the ATM interface on both systems around 65%. The 7507 was
at a higher utilization, around 50%, because I was using a non-VIP interface
to bring in the Ultra traffic. In an earlier revision of the topology, I
was using a VIP ATM interface with sub-interfaces and main processor
utilization was only 5% and the VIP was around 70-80%.
Things learned:
1. CAR and the weighted queuing *can* protect multimedia flows in the face
of hostile traffic.
2. Sub-interfaces are not only not supported, the code simply will not
tolerate them at all. The VIP's were stable when only the main interface
was used. When sub-interface's were defined, the VIP was *very* unstable.
3. VIP-50 is recommended for OC-3 rates and this experience seems to
confirm that. I will attempt to acquire a VIP-50 and see if I can get the
controlled bandwidth rate higher than the low 80's.
4. Given the low central processor utilization, it appears that we can
source an OC-3 worth of traffic out of every slot since all the work is
being done on the VIP's.
So, that's it for now. Unfortunately, my father died yesterday so I'm going
to be out of pocket for the rest of the week. I will continue this work
next week but the bottomline is that this project looks *very* doable.
later,
Charles.
-- Charles Ganzhorn Email: ganzhorn@cisco.com Consulting Engineer cisco Systems Riverview Office Tower, Suite 200 8009 34th Avenue South Phone: 612-851-8310 Bloomington, MN 55425 FAX: 612-851-8311