Subject: WG Last Call: New Work Proposal on Benchmarking DiffServ Mechanisms

From: Kevin Dubray <[email-masked]>
Date: Wed, 29 Nov 2000 08:10:38 -0500

BMWG'ers:

A WG Last Call period for the new work proposal presented to the BMWG:      

     Benchmarking Differentiated Services Mechanisms

will be open from 29 Nov until 6 Dec.

If you feel that there is reason that this new work should not be
undertaken by the BMWG, please respond to this list or
[email-masked]. 

=============================================================================
The Benchmarking Differentiated Services Mechanisms Proposal intends to 
address new problems created by differentiated service mechanisms.  These 
problems are not evident when testing with RFC2544 or RFC2889.  The main 
problems we propose to tackle are:

1. Extending current metrics, which assume the absence of congestion, 
to address the issues of DUT behavior during congestion. Metrics like 
Throughput (RFC1242), measure the point just before DS (Differentiated 
Services) has to make a decision on who to forward and who to drop.  
Throughput is very useful to find out how much a DUT can handle until 
a DS kicks in.  The new metrics we propose have the following qualities:

     - Defined as a per hop behavior (PHB). 
     - Defined explicitly for congested traffic where the DUT MUST drop 
       frames. 
     - Several PHBs can be combined to approximate a path segment.  There is 
       no intent to represent end-to-end measurements.  Rather, a goal of 
       this effort is to evaluate what effect each DUT's metrics have on, 
       say, a backbone network as a whole. 

2. Defining specific methods to activate the DS in order to get an 
"apples-to-apples" comparison.  Different forms of DUT congestion will 
produce different results.  Main factors are traffic distribution, amount 
of over-subscription, and number of code points used.  On the issue of code 
points, a DUT might have 2, 4 or 8 queues to handle all 64 code points.  If 
a DUT only has 4 queues, then how does it handle 64 different services?

3. Creating one set of metrics for both IP precedence and DSCPs.  IP 
precedence is currently deployed.  DSCP is just starting to be deployed.  
By defining one methodology for both technologies, we help the latest 
networks while supporting existing ones.

4. Defining test scenarios for multiple DSCPs.  Most tests today just test 
2 priorities: protected and unprotected.  But DSCP can theoretically handle 
priorities.  A new model is needed to replace the current binary model.

5. Creating a foundation for new technologies that do a DS-type forwarding 
decision not based in the IP header.  These technologies can build upon the 
DSCP test methodology.  One such technology is MPLS, where the DSCP functionally
is embedded in a label just before the IP header.

The first terminology Internet-Draft on this work is proposed for January 2001.
The first methodology Internet-Draft on this work is proposed for July 2001.