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

From: Matt Crawford <[email-masked]>
Date: Wed, 11 Jun 1997 16:31:18 -0500

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

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 11 Jun 1997 21:01:31 -0400

>and send exactly the data which you choose and which the network can

There are two issues here, each are equally valid, but it appears we
are talking past one another.

One might suggest that having applications support to set priority
is a fundamental design goal, whether one decides to honor it or
not is a matter of policy. I know some service providers who would
be happy with the downstream application setting priority -- they
would just require adequate measurement tools to bill them for
the volume of 'premium' class traffic as opposed to the volume
of 'best effort' traffic. Que sera, sera.

On the other hand, there are those of us who would prefer to
engineer policing mechanisms into the network to guard against
downstream applications setting priority higher than I would
care for them to, so I can properly do capacity engineering
in my network.

This is a policy issue -- we should simply develop the
protocol support to handle both.

- paul