Chaos with QoS

Position Statement

Dagstuhl, June 1995

Wolfgang Effelsberg
University of Mannheim

What is Quality of Service?

Application QoS parameters

image quality, image size, frame rate, startup delay, reliability ...

Network QoS parameters

bandwidth, delay, jitter, loss rate ...

The user is unable to specify network QoS parameters.

Why is QoS a Problem?

The relationship between application QoS parameters and network QoS parameters is very complex:
QoS must be end-to-end ("photon-in / photon-out"), not TSAP to TSAP
The best operating point might change during connections.

Providing QoS Guarantees

Service quality can be classified into

best - effort (no QoS)
That is not what we want.
with stochastic guarantees (e.g. for 99 % of all packets the delay
will be < 5 ms)
We don't know how to implement that.
with deterministic guarantees
Currently the only feasible approach.

Two application/network interface paradigms

the contract approach
the media scaling approach, nowadays called "adaptive applications"

QoS Adaptation

1. The application adapts to changes in the network:

media scaling

2. The network adapts to changing application requirements:

multicast filtering
dynamic join and leave for multicast connections
dynamic channel management

3. both!

Media Scaling

Proposed by IBM ENC, Heidelberg and others

If two applications want to scale up, who wins?

Multicast Filtering

Tree nodes contain filters to optimize bandwidth utilization.
Requires hierarchical stream encoding.
Will require application-specific knowledge in the network nodes!

RSVP proposes such filters in IP nodes. The filters themselves are application-independent, they can be activated based on an identifier in the packet stream.

Dynamic Join and Leave for Multicast

It is difficult to maintain QoS when membership changes in a multicast connection.

Dynamic Channel Management

Proposed by the Tenet group at ICSI, Berkeley.

Idea: Assign an alternative channel through the network when QoS parameters change.

Procedure: Compute alternate channel, reserve resources on that channel, switch over in an atomic transition. New channel can partially overlap old channel.

Can be network-initiated or application-initiated.

Conclusions

1. We need an overall QoS architecture including

the interface
the network components
the end systems (not just a list of parameters)

2. We don't know how to implement stochastic guarantees.

3. QoS mapping is difficult, must be solved for each application separately.

4. For the time being, the contract approach with interval parameters [lower bound, upper bound], connection-oriented multicast and resource reservation seems to be a feasible solution for packet-switched internetworks.

Stephan Fischer <fisch@pi4.informatik.uni-mannheim.de>

Last modified: Tue Jun 20 02:28:24 1995

Chaos with QoS