Re: A few questions

["Phil Wang" <pywang@nortelnetworks.com>]

Hi Muneyb,

It could be funny and crazy that the Olympics makes Sydney. -:)

Basically, I think that it's possible and feasible that your network is
built using the Accelar boxes in place of the Linux ones. For the
Diffserv, you need to use Passport/Accelar 8600 routers (as the core
router). Accelar 1100B provides a few packet forwarding priority levels
but have no Diffserv concept. You can capture and drop packets on both
Accelars. Another issue is that ORE and JFWD is currently available for
Accelar 1100B and shortly for Accelar 8600 (we'are waiting for the 8600
JVM delivery). JFWD is going to provide a Diffserv mapping soon.

Also see below comments. 

> 
> Hi Folks,
> 
> Reporting from the Olympic city, your programmable network correspondent.
> 
> I am going to try an experiment on my Accelar Programmable network
> testbed. I will first attempt to explain what I am going to try and
> propose a procedure to do it, I would like your feedback as a sanity check
> in case I am assuming the wrong things about the accelar's capability.
> 
> My network looks like this, it already exists, however all the routers are
> linux based, and I have successfully experimented this scenario on my
> pure linux testbed.
> 
>                 Smartbits
>                    |
>                    |
>                    V
>  ----------    -----------    ----------   -----------   ----------
>  |  VOD   |    |         |    |        |   |         |   | VOD    |
>  | Server |--->| Ingress |--->| Core   |-->| Egress  |-->| Client |
>  |        |    | Router  |    | Router |   | Router  |   |        |
>  ----------    -----------    ----------   -----------   ----------
>                    ^
>                    |
>                    |
>                 Voice
> 
> The Video On Demand is an MPEG-2 adaptive hierarchically coded application
> written in-house, it has different versions UDP based, TCP based, over
> IP or over ATM, incorporated with RTP and RTCP.
> 
> For this experiment I am using the UDP based version over IP. Basically
> there are 3 streams B frames, P frames and I frames running on three
> different UDP ports. Under conditions of congestion created by say voice
> traffic which is of very high priority, the B frames that are of least
> importance are to be dropped automatically by the Ingress router
> (this being the part of SLA that the customer has agreed to). As trivial
> as that.
> 
> My Linux Implementation
> -----------------------
> 
> 1/ In the core router, I have a complete diffserv enabled mechanism i.e a
> Expedited Forwarding + Assured Forwarding + Best Effort capable router. It
> is implemented using Class Based Queuing with set of traffic control
> filters and different queue mechanisms.
> 
> The queue structures are
> 
> *EF packets going through a short FIFO queue
> *AF packets going through four GRED queues ( accounting for the four AF
> classes). Each GRED queue in turn is equipped with 3 RED queues to provide
> for the 3 Drop Precedences.
> *Best effort packets go through a RED queue.
> 
> The voice traffic is targeted for EF.
> The VOD traffic is ideal for AF.
> I have background traffic generators (Smartbits) to congest the network.
> 
> 2/ I have traffic control filters on the Ingress router. They have
> forwarding rules set for the 3 UDP ports. I also have a program, wrapped
> around libpcap which captures and analyses all the RTCP packets flowing
> back from the client to the server. This program monitors the Frame Loss
> Percentage being reported by RTCP for B, P and I frames. When the frame
> loss exceeds unacceptable levels (which arise due to congestion) then the
> filters on that stream are changed automatically to drop all the packets
> of that particular stream.
> 
> With the above setup, I start the VOD application, then some background
> traffic. There are no losses, all my traffic gets through. Now I slowly
> ramp up my voice like traffic which has a significant allotment of
> bandwidth to have an effect on the VOD and completely stop any background
> traffic. As losses in the B Frames are encountered (as they are very big
> in size, Refer MPEG RFC), my program writes in the new filters which drops
> all the packets of the B frame stream.
> 
> Therefore the network has reacted to congestion based on the SLA with the
> customer.
> 
> Using the Accelars
> ------------------
> 
> 1/ Ideally
> 
> In my network I would like to replace all my linux routers with
> accelars.
> 
> Procedure
> I intend to write an oplet that uses JFWD in the ingress router
> to write the traffic filters. It also uses JCapture to capture the RTCP
> packets. When the frame loss percentage exceeds unacceptable levels then
> JFWD will write in the appropriate traffic-filters whose Action will be to
> drop the packets.
> 
> Q1. Is this the right way to proceed?
Most likely. Do the ingress and egress routers need the Diffserv
support?

> 
> Q2. (To Rob Duncan) Are JFWD and JCapture ready for use? You mentioned in
> a previous mail that you are testing a new release of JFWD?
True.

> 
> 2/ Practically
> 
> We have only 2 Accelar 1100B's. From my experience, it has only 2 queues
> and priority can be enabled by Port, VLAN, Mac address, IP Flow, Ip
> filters, etc. So I might have to just consider Voice and VOD applications.
> 
> As I can't have so many queues I will have to use the accelar only at the
> Ingress for now.
> 
> Q3. Can my procedure, as mention above, possible on an Accelar at the
> Ingress?
I think so.

> 
> I understand that the 8600 has 8 queues (from an old email conversation
> with Doug Moeller).
> 
> Q4. Will I be able to replace my Core router with the 8600 ?
Could be. You can learn more about 8600 from the document links of the
download page (http://www.openetlab.org/download).

> 
> Q4a. How do configure my Diffserv capable router with the following queues
> 
> (repeated here from above for convenience)
> 
> CBQ based schedulers with
> 
> *EF packets going through a short FIFO queue
> *AF packets going through four GRED queues ( accounting for the four AF
> classes). Each GRED queue in turn is equipped with 3 RED queues to provide
> for the 3 Drop Precedences.
> *Best effort packets go through a RED queue.
> 
> Q4b. Or their equivalent mechanisms?
> 
> I understand that you have WRR mechanisms for scheduling, but are their
> RED like queues (not relative priority queues).
> 
> I am basically looking for parameters like these, which I use in my Linux
> implementation.
> 
> limit - actual physical size of the queue.
> min   - Minimum threshold in Kilobytes.
> max   - Maximum threshold in Kilobytes.
> 
> where,
> min < max < limit
> 
> (probability)
> |      /(1)   /(2)               /(3)
> |     /     /              /
> |    /    /          /
> |   /   /       /
> |  /  /     /
> | / /   /
> --------|------------------------|------------>
>         (min for eg.3)           (max for eg.3)
> 
> I will try to give examples from the above crude graph :-)
> 
> 1. limit 20KB min 5KB max 10KB, slope indicates small delay through the
> queue however drops will happen earlier than the other cases
> 
> 2. limit 30KB min 8KB max 24KB,
> 
> 3. limit 100KB min 15KB max 75KB
> 
> Delay through the queue goes up cases 1-->3. However drops will happen
> earlier in case 1 than in case 2, in case 2 before case 3.
> 
> >From my understanding of the AF RFC, RED is quite key for its
> implementation (please refer Diffserv mailing list and Diffserv
> Implementation mailing list that I co-host with Brian Carpenter).
I do not have so much details about setting up these queues and/or
dropping mechanisms. A Nortel Networks internal document provides info
about them without detail configurations. I will take care this and give
you an answer asap. I hope that other people give more inputs about
this.

Cheers,
Phil

> 
> Any answers to my questions would be appreciated.
> 
> Cheers
> Muneyb.
> _________________________________________________________
> Muneyb Minhazuddin - Telecommunications Research Engineer
> CSIRO Telecommunication and Industrial Physics
> Sydney, NSW, Australia.
> 
> Phone no. : 61 2 9372 4113
> FAX       : 61 2 9372 4490
> e-mail    : mminhazu@tip.csiro.au
> Home Page : http://www-networks.tip.csiro.au/~mminhazu
> ---------------------------------------------------------