Subject: Re: support for packet drop priority

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

Here is a possible way that drop priority within the packets from
a single source could be useful. This only works IN CONJUNCTION with a
receiver who also backs off on detecting loss, so it is not an
argument that drop priority alone is a complete answer.

Suppose I am receiving a layered video session. Things are working
fine and I am subscribed to, and receiving, N layers with no or
minimal loss. Now, suddenly there is congestion.

If the loss from this congestion is concentrated on the highest
layer, its a clear signal to me to drop this layer.

If the loss is spread across all the N layers, the signal is weaker
by a factor of N, since I get only 1/Nth the loss on any layer. It may
take me longer to decide to back off, or I might not back off at all
if my threshold is set higher than the perceived loss.

We are playing with such layered receivers in our lab and it seems
to be easier to set the thresholds and do quick and yet stable backoff
at the receiver, if the network beats up the layers in an orderly way.

I agree that in this case my receiver does not have an incentive to do
the backoff (since my video quality remains the same before and after
the backoff) but if application is coded correctly, the priority drop
network is actually helping my application to the right thing by giving
it more information. The overall behaviour of an adaptive application
and network drop priority is more stable and responsive than that of an
adaptive application alone.

If the application is written by Darth Vader, then doing the priority
dropping actually hurts the network. In this case, I think the economic
stick (and not the performance carrot) is the right answer. In other
words, charge me by how many bits I send out, and then I will become
a good citizen and only send out as much as I can use. Or rather I
will stop using the Darth Vader application because it costs too much
and gives the same performance as the Ben Kenobi application.

Comments?

Anindo Banerjea

Dept. of Electrical & Computer Engineering
University of Toronto
10 King's College Road 
Toronto, Ontario  M5S 3G4
Canada

---

From: "Andrew T.Campbell" <[email-masked]>
Date: Wed, 21 Jan 1998 14:07:11 -0800

> at the receiver, if the network beats up the layers in an orderly way.

I'm slightly off track but .. here is a comment:

Congestion on the net today would statistically beat up across all
your packets/N layers. 'Beating up in an orderly way' requires different
controllers
for each layer. We did some work on this by guaranteeing bandwidth to
the base-layer and using adaptive control for enhancements (see IEEE
Network March 1997) in native ATM nets. Results were mixed. Conclusion: 
you have to push too much complexity into the net.

It would be v. neat if you could use some of the work emerging from
diff-serv to support the idea of a network that
"beats up the layers in an orderly way" for layered apps. 
This sounds a little like AN mantra to me; that is, pushing application
semantics to the net, or ATM mantra, calling for isolation for each
VC/sub-layers.

>From a 100 miles up it almost looks like N virtual networks to transport
N
layers - an extreme view. Where each virtual network has its own set of
controllers
running providing different services to each layer; as Steve
mentioned different congestion controller maybe active in
each virtual net.

Nothing is impossible but I don't buy 'orderly beating up of
packets' in NGI, not unless those are diff-serv VC of course!
It is tough to do all this just with edge semantics. 

Best,
Andrew

--
Andrew T. Campbell  
http://comet.ctr.columbia.edu/~campbell
Wireless Media Systems Project 
http://comet.ctr.columbia.edu/wireless