Subject: Adaptive applications within intserv framework

From: [email-masked] (Francois Toutain)
Date: Tue, 29 Jul 97 15:44:42 +0200

Hi there,

We have general wonders about servicing adaptive applications within the
integrated services internet framework. We apologize if this is not the right
place / time to discuss it. We'd appreciate everybody's feedback on the
various points discussed below.

Several years of QoS study have shedded light on the ability of most
"future" applications to alter their contents. As a result, it is possible
to build audio, video, DIS, etc... applications which adapt to variable
bearing service. There are:

o rate-adaptive apps. which embed a feedback-loop to vary their throughput
  according to the available bandwidth,

o delay-adaptive apps. implementing a playout buffer with adjustable offset
  point, to absorb jitter,

o loss-adaptive apps. making use of redundant / hierarchical / layered data
  encoding to resist packet loss (particularly suited to heterogeneous multi
  casting, since multicast feedback schemes cannot deliver "optimal" quality
  to each receiver).

We view loss-adaptation as a greedy kind of rate-adaptation, where the data
rate is downscaled by the effect of packet loss. It is also more and more
considered that rate- and loss-adaptation can be performed down to some
minimum level. This is rather natural, since there usually exists some
minimum data quality for the content to be useful (such a quality level is
highly dependent upon the end user ; for instance foreign language is more
difficult to understand than native language when audio quality is reduced).
In the case of loss-adaptation, an absolute minimum level can be expressed
as a function of the encoding technique used: adding some level of redundancy
allows to resist a given level of losses; when using layered encoding,
at least the baseband must be correctly transmitted; etc...

In our opinion, delay-adaptation is somehow restricted because the service
degradation must be dealt with mainly by the end user. In case of interactive
communication, delay cannot grow that much. Conversely if the communication
isn't of interactive kind, there is almost no use to give the session a lower
delay when possible.

So we believe a great amount of future adaptive applications could consist of
applications needing reasonable end-to-end delays,  requiring that a minimum
service be "guaranteed", and being able to considerably improve their quality
upon this minimum level. When these requirements are met, the benefits of
using such applications are:

o high network utilization, since adaptive apps. will tend to use whatever
  BW is available,

o high network efficiency, because useful service can be provided to a number
  of users (admiting a new session may decrease the service offered to existing
  sessions, but since they are prepared to that, they still provide useful
  service),

o high flexibility, provided they can be properly parameterized,

o accurate handling of heterogeneity, as adaptive apps. naturally deal with
  heterogeneous bandwidth availability,

o ability to meet users (budget) contraints: one could request and pay for a
  high quality  communication, while another using the same app could get
  budget service, at the expense of lower quality.

Now, our main wonder is, how could these apps. be serviced within the intserv
framework ? We identify two ways: (1) use guaranteed + best-effort service,
or (2) use Controlled-Load.

(1) would consist in using Guaranteed service to provide the minimum service
aforementioned, while additional service would be obtained from best-effort
when available. This imposes to split the flow into a guaranteed part and a
best-effort part. The troubles we see are:

o no delay commitment can be made for the best-effort part, so there may be
  scenarii in which only the minimum, guaranteed part reaches the end-system
  in time to be displayed.
  And considerable resequencing would in general have to be performed,

o competition inside the best-effort class must be controlled. In our opinion,
  it is unrealistic to make the assumption that apps. are "good network
  citizens". For instance loss-adaptive flows are unresponsive to congestion.
  This is quite similar to the problem raised by S. Floyd for the best-effort
  service, whith the increasing deployment of non-congestion-controlled
  traffics vs. TCP traffics. Maybe the solution would be to implement RED-like 
  mechanisms. Also, consistent with competition control is the issue of
  fairness. For instance tending to divide available bandwidth equally between
  competing apps. would have a bias against highly demanding ones, whereas
  performing bandwidth allocation in proportion to the minimum, guaranteed
  rates would penalize highly adaptive apps. Here we believe fairness should
  be addressed in a way that promotes high adaptivity (because it meets
  network operators' needs) and does not penalize apps. with high needs.

(2) would consist in setting the C/L TSpec to the minimum service level, and
sending excess traffic, since "the network element MUST attempt to forward
the excess traffic on a best-effort basis if sufficient resources are
available", and "network elements must not assume that the arrival of
nonconformant traffic for a specific controlled-load flow will be ususal",
to quote the C/L draft. The issue we see here is linked to the fact that
"the controlled-load service does not define the QoS behavior delivered to
flows with nonconformant arriving traffic", as it may raise the same two
troubles that were depicted above (i.e. large delays, lack/need for
competition control). Could it be envisionned to further specify this
behavior in the context of adaptive applications ?

A possible (3) would be to specify a new service class. Such a class would
coarsely look like the Available Bit Rate Capacity of the ATM Forum, with a
guaranteed minimum rate and enforcment of a fair (which definition ?)
allocation between competing sessions. Except that ABR doesn't address the
delay question, and that should be handled in the new class.
Is it a good idea ?

Any (4) ?

These are general thoughts more than specific questions, but we would
appreciate any comment on the subject. Thanks.

Francois Toutain                           [email-masked]
Octavio Medina                             [email-masked]
Laurent Toutain                            [email-masked]

Ecole Nationale Superieure des Telecommunications de Bretagne
Campus de Rennes, Dept R.S.M.
FRANCE

---

From: Nachum Shacham <[email-masked]>
Date: Tue, 29 Jul 1997 15:24:57 -0700

Francois et al:

Layered-based applications can indeed handle nicely network and user
heterogneity in multiparty sessions.  However, to maximize the
benefit of such applications the network has to recognize the
relationship among the various layers, i.e, the network must have
mechanisms for handling stream groups.  Unfortunately, the current
versions int-serv and RSVP do not have this feature.  Attempting to
force-fit hierarchical multicast (HMC) applications into the present
QoS models is likely to result in short term solutions only.  I'd
rather see that RSVP and int-serv are modified to handle
stream-groups.

Consider for example the approach of sending the minimum level under
guaranteed service and higher layers by best effort.  The problem
with this approach is in setting the threshold for the minimum
level.  As you point out, the minimum level is likely to be user
dependent.  Fixing a single level reduces flexibility.  As an
alternative you may decide to send multiple layers under
the guaranteed service (each on a different multicast address, of
course). But then why stop?  Send them all under guaranteed service
and let each user select the number of layers to be delivered.

Mixing guaranteed service and best effort are also likely to result
in different delay jitter value at the different layers.  Since 
the layers are combined at the receivers, the overall performance
will be set by the worst performing layer, i.e., the best effort.
In this case why send anything under guaranteed service?

There may also be cases where the admission request for low levels
is rejected.  If the layers are related hierarchically, receiving
the higher layers only will be of no use to a receiver.  you better
have a mechanism that makes sure that higher levels are not sent
unless the lower ones are delivered.

To avoid these and other similar issues, there is a need to take a
fresh look at the current QoS models and protocols and see how they
can be adapted to support stream-groups.  In doing so one may come
up with techniques for discarding packets from one stream to
preserve the integrity of the more important layers, how to bound
the delay of a group rather than a single stream, how to control
stream admission according to the relative importance, etc.

Last year we (Don Hoffman, Michael Speer, Madhu Sudan, and I)
offered changes in this direction to the RSVP group.  Apparently
they were concerned with getting RSVP ver 1 through the process.
Now that that version made it to the finish line, may it's time to
think about extensions to stream groups.

Nachum Shacham

======================================================================
Nachum Shacham                             voice: (415) 859-5710
Computer Science Laboratory (EL252)        fax:   (415) 859-2844
SRI International                          email: [email-masked]
333 Ravenswood Ave
Menlo Park, CA 94025
======================================================================

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 29 Jul 1997 19:05:19 -0400

>think about extensions to stream groups.

I find it ironic that with the scaling issues involved with
deploying version 1, that there is such exuberance to add
additional complexity to the protocol specs without explicitly
addressing the existing scaling issues.

Perhaps you could address this for me.

- paul

---

From: Nachum Shacham <[email-masked]>
Date: Tue, 29 Jul 1997 16:36:45 -0700

> Perhaps you could address this for me.

1. Where did you discen exuberance?  
2. Scaling is not just in numbers but also in heterogeneity 
3. I was not aware that the deployment issues of RSVP are 
   insurmountable to the extent that merely mentioning potential
   improvments sounds ironic.  

Nachum

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 29 Jul 1997 20:04:22 -0400

>1. Where did you discen exuberance?  

Okay, so perhaps my off-hand remarks were somewhat less
than specific -- exuberance was only derived, perhaps
not implied on your part.

>2. Scaling is not just in numbers but also in heterogeneity 

The only heterogeneity issues that I am aware of deal with
ATM SVC's and multicast. Is this the area which you intend to
focus?

>   improvments sounds ironic.  

Unless enhancements to the protocol are those which reduce the
issues of scaling, then I would venture to say that my gratuitous
use of the word 'ironic' is appropriate.

Cheers,

- paul

---

From: Nachum Shacham <[email-masked]>
Date: Tue, 29 Jul 1997 17:13:54 -0700

> ATM SVC's and multicast. Is this the area which you intend to

There might still be some scaling issues in IP multicast too.  For
example, in the context of distribution of real-time streams in a
network with bandwidth heterogeneity (wire and wireless for one).
Since the original message addressed this type of environment, my
response was in the same context.  That it, the suggested RSVP
modifications are aimed at supporting multicast of layered streams.

Regards,

Nachum

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 29 Jul 1997 20:45:23 -0400

>modifications are aimed at supporting multicast of layered streams.

I guess I'll stow my comments until I have the opportunity to
review a/the specific proposal.

Thanks,

- paul

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 30 Jul 1997 08:53:58 +0100

>ATM SVC's and multicast. Is this the area which you intend to
 
i think heterogeneity includes not just this, but layering, and
dynamics of congestion/adaption for layered scalable coded
video/audio/data, over services that give softer guarantees....

also, i'd like to include the "suspension of contract" so we can
retain dynamic routing, but define some sort of hiatus so that pople
can deterministically use standard routing and rsvp soft state, but
set timers so that the service guarantee suspensions have a known
duration....

and a few other things...

cheers

 jon

---

From: David Black <[email-masked]>
Date: Wed, 06 Aug 1997 16:20:56 -0400

> set timers so that the service guarantee suspensions have a known

A related potentially useful concept is that of a "fallback contract." This
supports discontinuous adaptivity (the application adapts by
fundamentally changing the way something is done) as opposed to continuous
adaptivity (the application adapts by adjusting a parameter such as
number of iterations, frame rate, degree of compression, etc.).

Consider the (contrived) example of a videoconferencing application that can
operate in color and black and white modes.  In each mode one could envision
continuous adaptation of things such as frame rate and degree of compression to
deal with bandwidth fluctuations, but there is some minimum bandwidth below
which the right thing to do is revert to black and white to get an acceptable
frame rate.  This is a discontinuous transition, and absent support from the
network the application has to sample performance and guess whether things are
going to stay broken/fixed enough for long enough to justify the mode
transition.  In an environment with a "fallback contract", the application
could place a contract sufficient for color and specify the fallback that
handles black and white -- when the network has to break the color contract and
does the fallback to black and white, this ought to be an event visible to the
application that causes it to immediately switch modes.  In this environment,
some component has to take responsibility for ensuring that there isn't a
frequent oscillation between modes -- the whole notion of "contract" places
that responsibility in the network area where more information is available
(and presumably therefore a better job can be done).

--David

============================================================================
David L. Black            THE OPEN GROUP     Voice: +1 (617) 621-7347
The Open Group                                 Fax: +1 (617) 621-8696
Eleven Cambridge Center      RESEARCH       E-Mail: [email-masked]
Cambridge, MA  02142        INSTITUTE         http://www.opengroup.org/~dlb/
============================================================================

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 11 Aug 1997 11:01:22 +0300

A possible (3) would be to specify a new service class. Such a class would
   coarsely look like the Available Bit Rate Capacity of the ATM Forum, with a
   guaranteed minimum rate and enforcment of a fair (which definition ?)
   allocation between competing sessions. 

i tried about a year ago to propose that kind of service.  the i-d was
called Protected Best Effort.

-- juha