Subject: Re: Adaptive Applications

From: Francois Toutain <[email-masked]>
Date: Thu, 14 Aug 1997 13:12:01 +0200

Juha,

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

You'd end up with basically the same situation, i.e. A1 receiving
optimal service and A2 getting (more or less) reduced service. What I
meant is, having a bias against highly demanding applications is not
good. Would you agree to give preference to audio apps. over video
ones ? IMHO, max/min fairness, i.e. equal shares, is only acceptable
as long as a flat charging scheme is deployed. In such a case it
seems natural to divide BW equally between competing apps. But highly
demanding users will not be happy with that. In contrast, consider the
case when users can state their needs, and receive service in proportion
to them. Under the assumption that needs' requirements translate into
proper charging, you end up with a fairness that states "in proportion
to users' needs, as depicted by how much they're ready to pay". If
my memory serves me right, this is the standard fairness definition
in the economics field when in a priced context.

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.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 14 Aug 1997 14:30:13 +0300

What I
   good. 

if all applications use the same tos and one is more demanding than
another, then the weigth of that applications should be higher, which
would also result in higher share of the excess bandwidth.

   Would you agree to give preference to audio apps. over video
   ones ? 

this problem can be solved by having different tos for each application
type and doing weighting/fairness within each tos.

   IMHO, max/min fairness, i.e. equal shares, is only acceptable
   as long as a flat charging scheme is deployed. In such a case it
   seems natural to divide BW equally between competing apps. But highly
   demanding users will not be happy with that. 

as i said, a highly demanding application can ask for a higher weigth
(via a higher minimum rate as in case of my pbe proposal) and also then
pay for it.

i too think that sima has lots of good ideas, but nbr is just one
example of expressing a user profile.  as david clark said yesterday, we
should separate packet handling in the network from the algorithm that
is used to classify the packets.

an open question is how many drop priority levels are really needed.  a
good solution would be to allow any number (within the limits of the
packet header of course) of priority bits to be supported. so one device
might support only one bit and another one could use three.  if i
remember correctly, this is how the three bit priority field is defined
in 802.1p and there is a table that tells what to do when a switch only
can handle one or two priority bits.

-- juha