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

From: Dimitry Haskin <[email-masked]>
Date: Mon, 16 Jun 1997 16:11:41 -0400

At 11:03 AM 6/16/97 -0400, Christian Huitema wrote:
>> On a serious note..  I don't think that by not having the drop bit
>you're
>> actually solving the "wrong incentive" problem or making it any better.
>> I've heard of multimedia applications that deliberately duplicate their
>> packets in order of improving odds of data delivery (this is reeeally
>> wrong incentive, doesn't it?).
>
>Dimitry,
>
>There are indeed many problems that have to be solved if we want to
>guarantee a stable Internet.  As Steve put it out, it is much simpler for
>an application designer to be selfish and messy than adaptive and clean.
> This is obvious when dealing with multicast applications, but the
>practice of open several TCP connections in parallel is just as bad.
> Then, if you take a close look at the new selective-ack options of TCP,
>you will certainly recognize a great potential for individual
>accelerations.  There is thus zero doubt that, to obtain a stable
>Internet, one need active policing from inside the network.  Several
>policing algorithm have been proposed, the most popular being the
>adjunction of a "bad guy detection and punishment loop" to Random Early
>Detection.
>
>The first effect of policing is in presence of a bottleneck, applications
> will only be able to transmit their "fair share" of data.  In fact, a
>good policing response curve should guarantee that, if an application
>sends more than its "fair share", the number of successfully received
>packets will decrease, not increase.
>
I agree with all you said so far. I don't quite agree with your conclusions
below.

>If you have policing in place, then an application assigned drop priority
>bit becomes a bad idea, for at least three reasons:
>
>* if priorities are user-based, rather than network wide, policy machines
>will have to keep tabs of the actual consumption of each users, and
>effectively upgrade or downgrade the priority on a per user basis.  This
>is much more complex than the statistical policing envisaged today.
>

It depends.  As an example, it wouldn't be too difficult for a FR DTE to
intelligently map the drop-priority bit to the FR's Drop Eligibility bit to
utilize the Frame Relay's congestion management. I don't believe anyone
proposed a mandatory use of priority in all circumstances or as a
replacement to other policy schemes.

>* if packets are tunnelled, the user based priorities can only be used if
>the original users can be identified by the tunnels' relays, which defeats
>the purpose of tunneling.
>
Then what? Tunneling hides all attributes of encapsulated packets. It does
not mean that they are useless.

>* as Steve said, if packets are bound to be lost, there is no point
>sending them in the first place.
>
Sure.. if application new that. We're talking about the best effort
traffic, don't we? By definitions of the best effort services some of
transmitted packets are bound to be lost.

>As many have observed, adaptation loops are not perfect.  A good adaptive
>design should suppose assess how many packets can be sent, and should also
>be ready to loose some of these packets.  In some cases, applications will
>decide to split their allowance between plain packets and redondancy.
> Duplicating everything is a very crude implementation of that tactic.

No disagreement. It's just that some of us believe that information
provided in a priority bit (not sure if more than one is needed) may help
in some cases and that the presumable harm of this bit is exaggerated.

>-- 
>Christian Huitema

Dimitry