Subject: Sticky Network Service and Diff-Serv

From: Jean-Yves Le Boudec <[email-masked]>
Date: Tue, 18 Nov 1997 17:09:23 +0200

It is possible to bring a little more than just best effort
differentiation, while using just two TOS bits, and without state
maintenance in the routers. The principle is to offer a "sticky" network
service. The objective of the sticky network service is to allow sources to
determine whether a minimum rate exists to a destination, and can be
sustained by the network for as long as the source needs it.

It works as follows. A source that wishes to send data with some minimum
guarantees probes the path to the destination by sending data packets
tagged as REQ packets. Data packets may be tagged as REQ, RES or
BEST-EFFORT, using two TOS bits. At regular intervals, the source receives
some feedback from the destination, using for example RTCP. The feedback
contains (roughly speaking) the rate at which REQ packets have been
received. The rate may be less than the source rate if routers on the path
have degraded REQ packets to BEST-EFFORT, or even discarded them. Then the
source may send data packets of type RES at the maximum rate indicated in
the feedback.

The key thing is that routers remember the rate at which they have seen REQ
and RES packets pass by, using an estimator as we do with controlled-load.
When a router accepts to forward a REQ packet, it updates its estimator in
such a way that it means a commitment to accept  future RES packets (this
is the basis for the sticky network behaviour). As a result, routers
normally never have to discard RES packets.  Again, as with controlled load
estimators, if a flow of RES packets decreases for a long enough time, the
estimator concludes that the reservation level should be decreased.

There is no signalling, no per-flow information kept in routers. Routers
keep only aggregate information about REQ and RES flows. They have no mean
to distinguish one large flow from a number of small flows.

The proposal relies on source cooperation: we expect SRP sources to obey
the protocol, just as we do for TCP sources.

Multicast is supported. For more details, see SRP (scalable resource
reservation protocol) at http://lrcwww.epfl.ch/srp/

____________________________________________________________________
JL                         Bien faire, laisser braire (Prov., Bret.)