Programme

1. Per-class shaping:
   • GOAL: verify the effectiveness, the impact of the end-to-end performance and the actual benefit of having shaping at each boundary between domains
   • TIMELINE: 1st Q 2001
   • PROGRAMME: analysis of
     1. accuracy and granularity of shaping
     2. impact of shaping on device performance
     3. effectiveness of shaping functionality in devices
     4. impact of traffic shaping on the profile of a given micro-flow as a function of:
        • the number of shaping devices on the data path (inter-domain QoS)
        • aggregation degree (number of microflows in the class
        • offered load of the class
   • REQUIREMENTS and considerations:
     1. use production traffic if possible for background traffic and for injection of traffic in the reference aggregated stream (the one to which shaping applies)

     2. IOS IOS 12.1(5)T or higher (per class shaping on any interface)
     3. C7500 (VIP4-80 ?), C7200 (no per-class shaping on GSR)
     4. Cat 6000: per-class shaping at line speed (MSFC 2 + PFC2)
     5. SmartBits 6000, POS OC-3c/STM-1 or POS OC-48c/STM-16
   • EXPERIMENTAL results

2. High-speed to low-speed:
   1. GOAL:
      verify the impact on the microflow delay and jitter profile of devices (e.g. at diffserv domain boundaries) forwarding traffic from an input high-speed interface to an output lower-speed output interface
   2. TIMELINE: 1st Q 2001
   3. PROGRAMME:
      Analysis of the delay and jitter frequency distributions of packets of a given microflow when coming from a high-speed interface to a lower-speed interface.
      The experiment can be repeated for different input rate/output rate ratios
   4. REQUIREMENTS:
      1. production traffic for background and reference-class traffic; reference microflow injected by specialized device for precise delay and jitter estimation;
      2. Input: STM-16; Output: STM-4 and lower

3. Deaggregation:
   1. GOAL:
      verify the impact of one or multiple deaggregation points on the data path of a given micro-flow
   2. TIMELINE: 1st and 2nd Q 2001
   3. PROGRAMME:
      1. testbed configuration with multiple hops;
      2. definition of traffic patterns so that a given micro-flow traverses alternatively multiple aggregation/deaggregation points
      3. reference microflow: injected by specialized hardware
   4. REQUIREMENTS:
      1. background and reference-class production traffic

4. Per-microflow end-to-end performance within a traffic aggregate (Tijani Chahed)
   GOAL:
   For end-to-end QoS in a heterogeneous environment, the main challenge is to be able to offer a seamless, end-to-end service. At the user side, the latter sees only its single micro-flow and is only able to express its QoS requirement in terms of QoS parameters. The QoS deal between QoS domains, is formulated in terms of QoS parameters as well. The task is then to map the QoS parameters between the different entities of the end-to-end system.

   In a diffserv context, the issue is then to find a qualitative as well as a quantitative mapping of QoS, in terms of QoS parameters, between the end user, individual, (intserv or other) flows and their network operator, diffserv aggregate.

   Analytical works done so far on the distribution of, for example loss, between the individual flows of the aggregate, adopt probabilistic assumptions and fail to account for possible biases that may be found in this distribution among individual flows which may be caused by synchronization at the packet level between single arrivals upon aggregation.

   Worst-case deterministic analysis shows that, qualitatively, packet loss at the diffserv level results in bursty, consecutive loss at the intserv level. Quantitatively, packet loss at the diffserv region is first related to consecutive, intserv packet loss and then to the local packet loss at the intserv level. As of delay, synchronization may lead a packet to experience maximum delay at every network element of the end-to-end path. The bias may be even worse with respect to delay variation.

   I would suggest to have an experimental look at this distribution of QoS parameters at the aggregate level among the single flows.

   • TIMELINE: 3nd and 4rd Q 2001
   • PROGRAMME: to be specified
   • REQUIREMENTS: to be specified

5. Enforcement of delay and jitter-guarantees:
   • GOAL:
     how can the network be configured so that the application's end-to-end delay and jitter requirements are actually met in presence of traffic aggregation?
   • TIMELINE: 3nd and 4rd Q 2001
   • PROGRAMME:
     1. survey of literature on analytic models for traffic prediction and self-similarity in Internet traffic
     2. collection of statistics from the per-SLS monitoring tool to estimate the per-microflow delay and jitter frequency distributions experienced on the data path. Statistics have to be collected for different aggregationi degrees and traffic patterns
     3. definition (if any) of a probabilistic rule (traffic pattern independent) which gives the possibility to predict delay and
   • REQUIREMENTS:
     1. deployment of production traffic
     2. per-SLA monitoring tool; metrics: per-microflow delay and jitter