Subject: Re: Adaptive applications

From: Francois Toutain <[email-masked]>
Date: Tue, 12 Aug 1997 15:22:03 +0200

>
>>   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

Hi Juha,
Thanks for your note,

Not so sure the Protected Best-effort service would do the job, for
at least two reasons (if my memory serves me right):

1. PBE did not handle delay guarantees (OK ATM's ABR doesn't do that
   either). But recall in the context of adaptive applications I
   asked for (possibly loose) delay guarantees, at least for apps.
   being of the interactive kind.

2. In the PBE draft it was advocated to enforce max-min fairness, that
   is, to provide equal shares of the available BW to each competing
   session, taking into account external constraints (guaranteed
   minimum and/or session bottlenecked somewhere else). In my opinion,
   max-min fairness is sort of too restricted when you're targeting
   adaptive applications, as it has a bias againt the most adaptive
   ones. For instance consider appl. A1 which requires at least 100
   Kb/s and gets optimal quality as long as it is provided 200 Kb/s,
   and appl. A2 requiring at least 100 Kb/s but being able to make use
   of 2 Mb/s. Say these sessions are the only two competing for BW
   allocation inside a given network element, the capacity of which is
   400 Kb/s. Then they both receive 200 Kb/s, which means A1 enjoys
   optimal level service when A2 is limited to "1/10th quality". Here
   I think some kind of proportional fairness, for instance based on
   the optimal quality BW requirements, would allow more flexibility.

Any comment on this ?

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 12 Aug 1997 16:52:15 +0300

yes, pbe didn't provide delay guarantees because it was a best effort
service, but it did provide delay fairness.

   2. In the PBE draft it was advocated to enforce max-min fairness, that
      is, to provide equal shares of the available BW to each competing
      session, taking into account external constraints (guaranteed
      minimum and/or session bottlenecked somewhere else). 

yes, min/max fairness is only one possible definition of fairness and it
may not be a good idea to say which fairness definition a service should
use.

      In my opinion,

no single fairness definition is good for all applications and it may be
difficult for one network to simultaneously support several fairness
models for different flows belonging to the same service category.  in
the above example, one could argue, that the situation is ok, since if
you had more bandwidth than 400 kbps then a1 would not use more than 200
kbps and a2 would get all the rest.

-- juha

---

From: Francois Toutain <[email-masked]>
Date: Fri, 15 Aug 1997 10:53:08 +0200

>   Except that, to be more general, you
>   may want to avoid coupling minimum requirement and excess
>   requirement.
>
>decoupling those two would certainly be nice to have, but not so easy to
>implement with wfq scheduler.  it looks to me that you would need two wfq
>schedulers: the first one guarantees the minimum and the second that
>operates after the first would guarantee the excess according to another
>set of weights.  i have not yet seen such schedulers in current
equipment, but it doesn't mean that there ain't any.

Using two separate WFQ-like schedulers doesn't look good to me, because
you can perform admission control on the first one so as to deliver
minimum bandwidth guarantees, thus get control over the service delay
(which is good for interactive adaptive applications), BUT you can't
do CAC on the second scheduler coz' you just want to fairly share the
excess capacity, hence you won't control the service delays inside.
So you'll end up with reordering and delay troubles that I discussed
with Nachum: either you wait for the worst delay, that is the delay
guarantee for the min part is almost useless, or you just drop late
packets, in which case you may have to drop all the excess traffic
you got (i.e. fairness is somewhat modified in the end).

I'll dare to afford a bit of self-advertizing here, because I had
a paper at HPN'97 dealing with this issue and introducing a fair
queuing principle which avoids the min BW / fairness coupling
(actually the packetized algorithm presented in the paper is not
that good and I've submitted a revised and augmented version to
Infocom'98). If you're interested, have a look at
ftp://ftp.rennes.enst-bretagne.fr/pub/prism/ft-HPN97.ps.gz

I can also provide the Infocom'98 draft on demand.

Cheers,
-ft.

---

From: [email-masked] (Ruutu Jussi NRC/Hki)
Date: Tue, 19 Aug 1997 19:33:38 +0200

Hello,

I would like to give a couple of comments on the message below.

1. SIMA makes all it can to deliver real-time packets as fast as   
possible. This is achieved by a small real-time buffer in a SIMA node as   
well as emptying real-time buffer before non-real-time buffer.  Actually,   
the real-time support is also an essential part of SIMA service, because   
SIMA is not only restricted to dealing with congestion or packet   
discarding.

2. True. Probably this is the most straightforward way to  make a   
guaranteed minimum when you have more and less important packets in the   
flow.

If your application gets feedback about the quality of the connection and   
adjusts its transmission rate accordingly, then you don't need two   
separate flows. You simply buy an NBR that allows the minimum quality   
(corresponding to L1) even during traffic peaks. Outside traffic peaks   
you can have higher quality (corresponding to L2) automatically.

3&4.  The basic feature of SIMA is the allocation of resources to "more   
important" applications. The "importance" is simply defined by the user   
herself/himself through the willingness to pay for NBR

5.  There are certainly many ways to support multicasting with SIMA. The   
one given below seems pretty natural way to handle the situation.

Jussi

 ----------
From:  Francois Toutain[SMTP:[email-masked]]
Sent:  Thursday, August 14, 1997 1:12 PM
To:  int-serv
Cc:  jh; Shacham; kalevi.kilkki
Subject:  Re: Adaptive Applications

Precedence: bulk

..

To go back to my initial wonders, i.e. how do adaptive apps. fit within
integrated services as they are envisioned today, I've come to consider
the SIMA proposal as a very good candidate. Because:

1. it offers (loose) real-time service, so interactive apps. may get
   presumably low end2end delay ;

2. it allows (loosely) guaranteed minimum. Consider for instance
splitting a flow into a min-to-be-guaranteed layer, say L1, and
another layer L2 that can be dropped if it deems necessary. Then
define a high NBR for L1 so that its packets get a high priority, and
a lower NBR for L2 because you don't wanna pay for full quality, but
you wish to enjoy better quality than just L1 if the network conditions
permit it. Put L1 and L2 into the same "rt" class, and packets from
both will probably incur similar delay and delay variation, even if
packets from L2 start being dropped as a result of network congestion.

3. It makes use of what I think is a very important aspect of adaptive
apps., i.e. the readiness to make room for a "more important" app.
that wishes to set up. Here "important" translates into the packet
priorities.

4. it seems to me that the fairness resulting from SIMA is coarsely
the one I was talking about above, i.e. proportional to users' needs,
as depicted by the charge they're ready to incur (stated through NBR).

5. What about mcast layered encoding ? Well, at first glance I think a
combination of SIMA and RLM could behave nicely. Again using the NBR
to actual rate ratio, one is able to "guarantee" some subset of the
layers by providing them with high NBRs, and one can take a chance to
get the other layers if network conditions allow that, by stating
lower NBRs for these subbands. Then it remains the responsibility of
RLM mechanisms to ensure layers are joined to in proper order.

I'd appreciate comments on this.

Cheers,
 -ft.