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

From: Dimitry Haskin <[email-masked]>
Date: Fri, 13 Jun 1997 10:26:05 -0400

At 03:18 PM 6/12/97 -0700, Steve Deering wrote:
>[The rest of this reply is addressed to the list, not just to Petri.]
>
>Look, I really like the idea of drop priority to minimize the perceptual
>damage caused to real-time applications by the inevitable transient
>congestion events.  That's why I specified the Priority field the way I
>did in the original IPv6 (and earlier SIP) spec.  But then the negative
>consequences of that feature were pointed out me, and after many months
>of resistance, I finally and reluctantly concluded that it would do much
>more harm than good.  I haven't heard anyone present a solution to the
>"wrong incentive" problem, other than usage-sensitive charging for
>best-efforts traffic.  Making the usability of IPv6 contigent upon the
>successful adoption and deployment of a per-packet charging infrastructure
>seems like a very bad idea to me.
>
>So, there's no need to keep explaining to me the possible benefits of a
>loss-priority feature.  Please explain how you would avoid the potential
>harmful consequences.
>
I thought we're now in a mood of giving away bits for the sake of a
presumable but quite questionable future benefits? ;-)

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?).  At least with the drop bit there is a hope that
some of these packet will be marked. Maybe I'm naive but I do believe that
there will be applications that will make the best use of the available
tool. Such applications will replace bad behaved applications not for
altruistic reasons but because it just make economic sense. And "economic"
does not necessary mean usage-sensitive charging.

Dimitry

---

From: [email-masked] (Christian Huitema)
Date: Mon, 16 Jun 1997 11:03:46 -0400

> 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.

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.

* 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.

* as Steve said, if packets are bound to be lost, there is no point
sending them in the first place.

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.
* if

-- 
Christian Huitema