Subject: Re: Adaptive applications within intserv framework

From: Nachum Shacham <[email-masked]>
Date: Wed, 30 Jul 1997 11:49:37 -0700

Hi Francois,

> Hi Nachum, thanks for your note,
> 
> With respect to my original posting, I would classify your note as a partial
> proposal to my asking for any (4), targeted towards layered flows, and I woul
d
> summarize it as:
> 
> ""
> Any (4) ?
> -> yes, implement stream-group mechanisms for layered flows, to be used
>     in conjunction with an existing service class.
> ""
> 
> Do you agree with that ?

Agree with the need to implement stream-group mechanisms.  Whether
or not the existing services classes will suffice depends on our
ability to specify the service requirements of a bundle based on the
requirements of the individual sub-streams.

> 
> >> (...) 
> >> 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.
> 
> Then this is no adaptive application any longer. I mean, you may not
> get some given layer due to insufficient resource, and you won't get it
> later when resources become available (unless you periodically try
> to set it up, which yields considerable management traffics...).

I would say that in general it is easier to detect the need to
reduce service requirements than the opening of additional
resources.  Most of the works I've seen over the last decade or so
detect excessive loss directly and attempt by trial-and-error to
increase resources when reduced-level service is adequate.  Why
would such actions disqualify an application from being called
adaptive?

> 
> Alternately you could discard any best-effort packet arriving later than
> the delay bound you get with guaranteed service. But I really cannot
> say if it is a good idea, i.e. will you get any best-effort packet ? Isn't th
ere
> a possible congestion collapse issue, as more and more useless best-effort
> packets will be transmitted ? Anybody's feeling on this ?
> This is quite close to the delay issue I mentionned in my first message.

I agree with the negative feelings on this issue.  Letting some
packets drop at random is likely to require the discarding of larger
blocks.  Heterogeneous Multicast (HMC) aims at getting only what you
can and need to get.  
> 
> Er...So you strongly think that layered-based transmissions should be
> made using a separate flow for each subband ? Why not merge these
> flows into a single reservation ? 

True HMC involves both merging and splitting.  Whereas merging is
done by the end points, splitting is done at the network switches.
You want the group tagging to be at the level that will make it
feasible for the switches to carry out splitting.  Since routers
work at the multicast address level it looks natural to me to merge
and split the layers at that level.

> We could even preserve distinct multicast
> addresses, so that end users can freely join to the number of subbands
> they want, but have the packet classifier assign the same resources
> to all packets coming on these addresses.

I thought that with IPng, addresses should not be looked at as a
scarce resource.  There suppose to be enough addresses to support
the migration of all the DNA molecules from the traditional
double-helix structure to IP-based distributed molecules.  Think
about it, inter-organism communication at the DNA level!  Congestion
will make people sick because some genes cannot communicate.
Surgeons will be replaced by sys-admin.  You set the wrong TTL and
the whole neighborhood knows what you think! But I digress.

> Under the assumption that layers can be totally ordered, then we merely
> have to define layer values to be carried by each packet, the semantics
> of which are restricted to the application (i.e. different apps' streams need
n't
> be compared between) and implement selective discard so that least
> important packets be dropped first. That way you avoid any mechanism
> dealing with inter-flow control, i.e. stream-groups. And selective discard is
> a feature that could be used for other purposes too (i.e. non-layered streams
).
> Heterogeneous multicasting would be easier I think. 

Total layer ordering is just one possibility. There may be other
relationships that will be more difficult to define and handle.  

A selective discard can benefit a lot from switches discarding from
one layer to save another.  BTW, I tend to consider all packets of
the same layer as having the same importance.  If you want to have
different discard priority at the same layer, then you might have to
do as much work (marking different packet etc.) as classifying them
as different layers.

> As for the threshold
> for the minimum level, it could be set, in a given node, to the max between
> thresholds requested by the different sub-trees. Then some packets could
> be handled as under-threshold inside the tree (thus receive "guaranteed"
> service), and become above-threshold as they reach a given split-point,
> where no downstream user required the layer they belong to to be guaranteed.
> Now adaptivity is still problematic. What I described above would fit into
> the Controlled-Load scenario, provided layer-threshold can be translated into
> a C/L TSpec, except that excess traffic would need some support for the two
> issues I mentionned in my first note, i.e. delay and competition.
> As for the Guaranteed+Best-effort scenario, the situation is not clear to me.
> I think it would require an additional capability of network elements to redi
rect
> nonconformant packets to best-effort, since one can no longer split the flow,
> a priori, into a guaranteed part and a best-effort part. The delay and compet
ition
> issues also remain in this case.

If I undertand your scheme,  ordering is defined not only among the
layers but also among the service classes, both are specified in
the request for service, and contention is resolved by
deliverying a layer at the highest requested service level.  This
sounds interesting, excepts that mixing Guaranteed and best effort
among layers may not work as we both seem to agree.  Can you
explain how this scheme works with C/L?

Best regards,

Nachum

---

From: [email-masked] (Francois Toutain)
Date: Thu, 31 Jul 97 17:36:54 +0200

>> requirements of the individual sub-streams.

All right. What I wanted to point out is that I was aiming in my first
message at defining stg general enough to encompass the various adaptation
techniques, whereas stream-group mechanisms are clearly targeted towards
layered streams.

>> would such actions disqualify an application from being called

The difference I would point out is you aren't able to make room for
a new stream. Im my opinion one of the major benefits of adaptive
applications is that they are prepared to give away some network
resources if these are more beneficial to another app, for instance
one trying to establish a new call. For instance this is proposed in the
Receiver-driven Layered Multicast from McCanne & Jacobson,
but in their scheme a given app has the ability to detect resource
scarcity and reduce its quality, *because RLM is based on best-effort
service*. In contrast if you send the various layers into Guaranteed
(or even C/L) sessions, you cannot do that.

>> the whole neighborhood knows what you think! But I digress.

;-) Food for William Gibson & Co I guess

>> > nonconformant packets to best-effort, since ...

Let me correct this, since nobody seems to have seen the bug...According to
the Guaranteed Service draft, "inside the network, network elements that
wish to police traffic MUST do so by reshaping traffic to the token bucket"
and "the reshaper SHOULD relegate non-conforming datagrams to best effort".
Hence it appears that network elements could automatically split the flow.
>> explain how this scheme works with C/L?

OK. I'll consider an augmented C/L in order to get rid of delay & competition
issues. Say a class offering loose guarantees w.r.t. delay and loss as C/L
does, for traffic conforming to a given TSpec and also providing fair
allocation of available BW between traffics exceeding their TSpecs, and
avoiding desequencing (i.e. excess traffic is sent "in-band"). In addition,
it extends the loose delay guarantee to the whole traffic, i.e. if an
excess traffic packet is sent it won't (loosely) incur a delay above the
(loose) guaranteed one nor impact the delay seen by other packets. Otherwise,
it's discarded.
The resulting service is variable depending on the amount of available BW,
on the number of sessions sending excess traffic, etc. But the serviced
traffic is (loosely) guaranteed to lay between TSpec and whole submitted
traffic, and to arrive within reasonable delay.

I envision such a class to be used by rate-adaptive apps. embedding end-
to-end feedback, as well as loss-adaptive flows. For the latter consider
for instance a FEC- or PET-encoded stream. Now for layered streams.

Say a stream consists in a baseband layer BL, and two enhancement layers
EL1 & EL2, with distinct multicast addresses. User X joins the three MC
groups and requires that BL be the guaranteed minimum quality level, and
that both ELs be delivered if possible. Then a reservation can be made
for BL so that its traffic falls into conforming C/L, and ELs traffics can
be sent as excess traffics for the same reservation. When an excess packet
is to be discarded inside a given element, selective discard allows to
preferentially drop an EL2 or an EL1 packet, depending on their relative
importance. Depending on the network conditions, the user may receive
the three layers, or maybe BL and EL1 and a few packets from EL2, or BL
and a few packets from EL1. I think the user may leave the MC group(s)
from which he/she just receives a few packets (unless they can be
used, is it possible ?). Then he/she will have to check later on if
the network conditions are better (as we discussed before).
Now consider a new user Y wishing to get the same data stream, but with
guaranteed minimum BL+EL1, and without taking the bet to get "extra" EL2.
Hence Y joins MC groups for BL and EL1 only.
In my view the reservation must be updated to make room for the aggregate
of BL and EL1 traffics (I understand there is an issue here), on the path
situated upstream from the split point. This could indeed improve the
service received by user X if the bottleneck (w.r.t. excess traffics) is
situated on this path.

Is it at last very different from what you have in mind ?
I guess there are several implicit issues that we have to dig out.
e.g. the route must be the same for the three layers...

Cheers,
-ft.