Subject: Re: support for packet drop priority

From: Anindo Banerjea <[email-masked]>
Date: Wed, 21 Jan 1998 19:01:15 -0500

Nachum,

> The application does have an incentive to back off.  The reception fidelity
> of layered depends not
> only on the loss rate but also on where the losses are.  By dropping a
> layer, ...

I don't disagree with you. I merely observe that in Steve's view of the
world, the network should make sure that the loss is spread across ALL
the layers, to MAKE SURE that the video quality suffers if the
application does not back off. In other words, force the application to
back off by killing his base layer too, if the total rate that he is
sending is more than the capacity. This makes sense to me too.  If the
network does this, the adaptive layered application will forced to
adapt, and will still work, but may not be as reponsive and stable as
in the other case.

If we can separate the issues of policing (deciding when to clobber
packets "belonging" to a given "user" because he has been bad) and
priority within a single user's packets (deciding which of a given
user's packets to clobber if there is just random congestion but no one
has been bad) there seems to be some value (e.g., the adaptive
application becomes more stable). Of course, the questions of how
complex this is and is it worth it remains. But, it is an (albiet
incomplete) example of how to use DP to improve the behaviour of the
complete system (network + application).

The missing piece is, what makes sure the adaptive application actually
does back off? Two possible answers are: money (BW wasted should
translate to money wasted) or performance. The simplest performance
based answer is Steve's (clobber everything and the application is
forced to back off) and is attractive because no mechanisms are needed.
But there may be another answer: one reason to look for that answer is the
point that I raised (the application becomes more stable).

If such a solution exists, it would be useful not only to layered applications,
but also to the user who wants to give higher priority to his voice over
IP traffic than to his Web surfing traffic. Same point there. The
Web traffic should back off if it sees losses (and will if it is using
TCP) but who is to make sure that it does. Steve would kill his voice
traffic too, to make his Web traffic back off. In this case, there is
not much point doing that, since the applications are separate, but the
router can't tell the difference.

Anindo

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 22 Jan 1998 00:27:33 +0000

In message <[email-masked]>, Anindo Banerjea t
yped:

 >>translate to money wasted) or performance

the performanec hooks are what Wroclawski outlined in the first talk
on this - the profile for a good (single) TCP is defined
by the fairly solid theory now of what an aaptive application should
do when faced with congestion (acceptable long term stable throughput
is roughly 1/RTT*sqrt(loss), for flows in the "effectively" low
utilisation, lowish loss premium class - so a route r, even without
RTT info, can infer at least a statistical estimat of misbehaving (non
adaptive) flows...this is from the control theory (or frank kelly's
rate analaysis - see floyd, matthis/ott, or kelly - at
http://www.statslab.cam.ac.uk/~frank/pf/
for refs)
 >>router can't tell the difference.
 
right..money is the root of all fair unfairness

 cheers

   jon