Subject: Re: (IPng 3987) Re: Qry on Traffic Policing (IPv6 header changes)

From: Dimitry Haskin <[email-masked]>
Date: Wed, 11 Jun 1997 20:41:15 -0400

Matt,

I think it's long understood that regulating traffic flows as close to
their sources as possible is a good thing. The question is if it always
possible or, more importantly, economical to provide congestion feedback on
the timescale and granularity that guaranty that no data discard would be
necessary.  And in many cases it may not be feasible for one reason or
other to extend such a feedback all the way to each traffic generating
application. The most likely the traffic admission control/excess discard
is done at edge routers or switches. It seems that in such a case a bit
saying "if you have to drop my packet I'd suffer less if this packet is
dropped" could be useful.

Dimitry

At 04:31 PM 6/11/97 -0500, Matt Crawford wrote:
>Petri says:
>> > ... the application should send as much useful data as can reach
>> > the destination.  If that amount is less than "all the data," the
>> > application should choose wisely which data to send.
>> 
>> Yes..You are right.
>> However, what if destination is multicast group with heteregenous
receivers ?
>
>Then the very best thing to do is to send the different "grades" of
>packets to different multicast addresses, and have the receivers
>only join as many groups as they can actually get.
>
>> Anyway, drop bit is needed because packets have always different
>> importance. 
>
>If you use a drop-preference bit, then you are sending packets which
>you believe may not make it all the way to the destination.  Once
>more ... suppose your packets can be classified at the source into
>ten grades of importance, and call those grades 1 through 10 (most
>important to least).  Suppose also that you determine at a certain
>time that the network is capable of delivering only enough bits per
>second to include all the packets of grades 1 through 4 and some of
>grade 5.  Then that's what you should send -- all of 1 through 4 and
>some of grade 5.
>
>If you don't do that, then suppose you marked only grades 8 through
>10 with your drop bit.  You waste network bandwidth up to the
>bottleneck carrying all of 1 through 10, then when you get to the
>bottlneck you lose all of 8 through 10, and some of 1 through 7 at
>random.  That's not the best you could have achieved.
>
>Now suppose you marked all of classes 3 through 10 with your drop
>bit.  At the bottleneck you retain all of classes 1 and 2, and some
>packets randomly in classes 3 through 10.  Again, not an optimal
>mix.
>
>Conclusion: to get the best result, put the smarts at the endpoints
>and send exactly the data which you choose and which the network can
>carry.
>
>And Dimitry says:
>> Is it that easy?! Does the application always know how much of its
>> data can reach the destination at any particular moment if
>> statistical multiplexing is used?
>
>TCP does a fair job of figuring this out.  If you get to design your
>protocol today from scratch, you should be able to do it even more
>efficiently, yes?  Or am I naive?
>					Matt
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to [email-masked]
>--------------------------------------------------------------------
>
>

---

From: Steve Deering <[email-masked]>
Date: Wed, 11 Jun 1997 21:12:44 -0700

At 5:41 PM -0700 6/11/97, Dimitry Haskin wrote:
> The question is if it always possible or, more importantly, economical
> to provide congestion feedback on the timescale and granularity that
> guaranty that no data discard would be necessary.

No, it's not possible to guarantee that no packets are discarded, when
using the Internet's "best effort" service.  Adding support for a drop-
preference bit would not eliminate the possibility of loss of "unmarked"
packets (i.e., packets without the drop-preference bit set), since there
could still be bursts of unmarked packets that exceed the bandwidth and
queueing capacity of a link.  Any application designed to operate over
best effort service ought to be able to gracefully survive occasional
packet loss, even of its "most important" packets.

Steve

---

From: Mike O'Dell <[email-masked]>
Date: Thu, 12 Jun 1997 06:19:57 -0400

I have to agree with the basic notion here.

There is often a heirarchy of need in applications, particular
multimedia apps, where some compression frames are a *lot* more
important than others.  the ability to express those relationships
is potentially useful in helping decide "what loses" when push
inevitably comes to shove.  this is one of those situations where
it might be hard to prefectly understand how the knowledge is used
in all cases, but if you don't have the information, you certainly
won't come to understand how to use it more effectively.

so lemme suggest something to be shot at (draw the fire, Steve
(grin))....

there should be TWO  DE bits - one for expressing Application
sensitivity and one for use downstream by site-egress traffic
shaping and policing (working in conjunction with packet priority
coloring).

	yours for controllably more-differentiated service....

	-mo

---

From: Roch Guerin <[email-masked]>
Date: Thu, 12 Jun 97 07:45:48 -0400

>dropped" could be useful.

There seems to be two issues here that are lumped together and it may
be preferable to look at them separately.

The first is that it is clearly best to send into the network ONLY those
packets that will make it through.  The second is whether there are
mechanisms that, in the absence of exact knowledge of how many packets
can make it through, can help ensure that the *more important* ones are 
more likely to succeed.  Here, *more important* could be based on some
applications ranking or determined by the network (edge router) as a
function of some pre-agreed service contract with the user, e.g., traffic
in excess of the contract are to be delivered only if resources are free.

The question wrt to the first issue is how easy it is to obtain that
kind of knowledge.  This depends on the time scale at which congestion
happens and disappears in the network, how fast the sender detects
changes in congestion, etc.  For example, a source-based closed-loop 
approach, such as what TCP uses, can only yield a very crude tracking
of congestion.  An approach, such as the one used by the ABR service
(yes, that's an ATM service ;-) that attempts to provide explicit 
feedback information to the source by returning the maximum possible 
transmission rate on the bottleneck link, gets one step closer but does 
involve quite a bit of added complexity, both at the end-systems and 
within the network.  Furthermore, it is not clear how well it works 
across scenarios.

So, as far as I'm concerned, I don't think we can assume that an end-system
can always *accurately* identify how much traffic they can successfully
transmit through the network.  As a result, you will be wasting bandwidth
on some links to transmit packets that will be dropped later.  This is why 
issue two is relevant, namely try to improve the odds of the more important 
packets making it through.  You can try to do that either assuming some 
cooperation between the network and the end-system, or by doing things only 
at the end-system and viewing the network as a black box.  

There has been a number of proposals for the latter, e.g.,
variants on sending multiple copies of the more important packets based on 
different types of underlying coding schemes, and they do yield improvements
for those applications that use them.  However, you can typically get
better results when there is some cooperation between the network and
the end-systems, and this is where marking can play a role.  For example,
by using some weighted RED type buffer management approach, you can 
lower the chance of more important packets experiencing congestion (I
believe Cisco is proposing something along those lines, based on the
material on their web site).  In general, there are many things that can
be done using various combinations of scheduling and buffer management
disciplines in the routers to take advantage of the availability of
the information that marking provides. 

So, I do believe that marking, either by the application to indicate
packets of different importance, or at the edge of the network as a 
function of some traffic contract, can be useful.  The tricky part
is that this requires consistent definitions in how the marking is
used, as well as added support (scheduling and buffer mgt) in the 
routers to be able to take advantage of this.  

My 2c.

Roch

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 14 Jun 1997 23:02:03 +0300

sure and a good implementation has a per flow queue with two thresholds.
once the queue is above the first, it starts to drop marked packets and
when above the second, it starts to drop all packets.

-- juha