Subject: Controlled-Load comments 2/26/96 11:45:04

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Mon, 26 Feb 96 17:26:48 EST

Reference:  Your note of Mon, 26 Feb 96 11:45:04 EST

jj, quick responses to your comments.

>First of all, the term "adaptive" has some history in the int-serv
>literature as referring to delay-adaptive applications (those that can
>move their playback point around).  I believe you are referring to
>applications that can adapt their sending rate based on feedback from
>the network.  Perhaps using the term "rate-adaptive" would keep me
>from getting confused (is it only me?).

Correct.  Please replace *adaptive* by *rate-adaptive* in my note.

>Secondly, I'd like to see the sections on policing modified to include
>those cases of a shared reservation on a multicast session with
>multiple senders.  For example, your "Guaranteed Bandwidth" service
>does not allow dropping within the network, but if a reservation is
>for less than the sum of the senders' rates, what do you do?

Sharing is certainly an aspect that I did not address as I wanted to
first take a crack at the *simple* cases.  Now, in the case of a shared
reservation on a multicast session where the reserved rate is less
than the sum of the senders' rate, we are in a sense in a situation
similar to that of category B., i.e., non-adaptive and not necessarily
conformant.  So, you'd face the same problems with one more tweak,
namely how to apportion traffic from different flows to the conformant
and non-conformant shares.  For example, if you have two senders and
bandwidth for only one, you could send one packet of each and drop or
downgrade to best effort the other one.  Alternatively, you could
pick all the packets from one guy and drop or downgrade to best
effort those from the other sender.  The latter is probably the right
thing to do in many cases, but it's not entirely clear in general.  For
example, in a video conference where two speakers suddenly become very
animated so that their bit rate goes through the roof (say, they are
debating the merits of various service models ;-) ), is it better to
accurately track the gesturing of one and *freeze* the other, or should
both appear with choppy motion?  The latter may be better, especially
if freezing one speaker for too long can result in some loss of
synchronization.

Altogether, these look like tricky issues that may depend on application
requirements, but for which the appropriate support may not always be
available in the service elements.  For example reshaping/policing may be
performed on the aggregate stream without awareness of individual flows.
In the context of a guaranteed bandwidth type service, a simple solution
might be to reshape at merge points and size the reshaping buffer to
be large enough to avoid dropping packets when only one flow is active,
but small enough not to introduce too big delays when several flows are
active simultaneously.  Here the shaping is doing the policing.
Alternatively, you could serve the aggregate stream at whatever rate is
available, i.e., the reserved plus any free bandwidth, and drop packets
when the buffer exceeds a level that would result in too big delays.
Here you only shape/police when you have to and packet dropping or
downgrading to best effort only occurs whenever you hit a congestion
point.  This is sort of taking an optimistic view, but may increase
instability and losses in the network (this will depend on how buffers
are managed at downstream nodes).

In general, I'd expect that we need additional experience in really
figuring out what works well for sharing.

Roch