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

From: Scott Bradner <[email-masked]>
Date: Wed, 11 Jun 1997 08:59:47 -0400 (EDT)

> So, I recommend that one bit from IPv6 version field is taken to this
> kind of drop bit

this sort of issue is not an easy one - there has been quite a bit
of discussion in many forums about how best to deal with excess
traffic - a discard OK bit is one of a number of options 

at this time it seems to me that the community does not have enough 
understanding of the complexities in this area and more research
is needed before we should be off reserving bits.

Scott

---

From: Koskelainen Petri <[email-masked]>
Date: Wed, 11 Jun 1997 16:15:36 +0300 (EET DST)

> is needed before we should be off reserving bits.

Yes, but excess traffic is only one issue. Much more important issue
is the applications ability to mark some packets with
"drop this in the case of congestion" label thus increasing
the propability of applications other packets delivery.

Currently there is no way for applications to do so and I certainly
believe that such is needed in the (near) future A/V applications.

Petri

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 11 Jun 1997 10:07:18 -0400

>believe that such is needed in the (near) future A/V applications.

With IPv4, it is trivial to do this by using the IP precedence to
weight the probability of drop in congestion instances. This can
either be set by the origin application, or policed by the network
ingress point.

Draw your own comparisons to what is possible with IPv6.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 11 Jun 1997 10:49:12 -0400

At 07:46 AM 06/11/97 -0700, Steve Deering wrote:

>
>With the revised definition of the IPv6 Priority field agreed to in Memphis,
>the same is possible with IPv6.
>

Not that I've been following very closely (I haven't), is this
modification documented yet?

- paul

---

From: Steve Deering <[email-masked]>
Date: Wed, 11 Jun 1997 07:46:59 -0700

Steve

---

From: Steve Deering <[email-masked]>
Date: Wed, 11 Jun 1997 08:25:02 -0700

> modification documented yet?

Only in the WG minutes, so far.  (I plan to have a new version of the base
IPv6 spec out before Munich.)  Here's what the minutes say:

  - Declare that 4 bits of Priority are rewritable by routers/ISPs for
    private purposes (and exclude from authentication header).
  - Priority bits have no significance to receivers
  - Convention: Sender sets low order bit to mean interactive traffic.
      o Delay more important than throughput
      o Suggests that routers/ISPs use other bits before touching the
        "interactive bit".
      o Affects queuing only, not routing (since re-writable).

Steve

---

From: Koskelainen Petri <[email-masked]>
Date: Wed, 11 Jun 1997 21:15:15 +0300 (EET DST)

> > >With the revised definition of the IPv6 Priority field agreed to 
> > >in Memphis, the same is possible with IPv6.
> > >
> >

Yes, perhaps senders may set priority bits but it makes no sense
since routers rewrite them usually. So, why bother setting priority
by application ?

About "unnecessary packets". Always (!) some packets are more important
than others!
Your codec can produce 20 or 200 packets/s but still, some packets
are more important than others! Of course you should reduce rate
for congested path but the problem is still same.

Briefly, there exists no equality between A/V codec packets.

No matter how small bitrate you have (even 1 kb/s), packets have still
different importance.

So, this (drop bit) does not encourage sending unnecessary packets.
All A/V applications should reduce bitrate as much as possible 
but the basic problem is still same!

--
Petri

---

From: Steve Deering <[email-masked]>
Date: Wed, 11 Jun 1997 20:48:40 -0700

At 11:15 AM -0700 6/11/97, Koskelainen Petri wrote:
> since routers rewrite them usually.

That's not necessarily true.  All we are saying is that the routers are
free to rewrite them.  We are not saying they must rewrite them, or that
they must usually rewrite them.

> but the basic problem is still same!

You say that all A/V applications should reduce bitrate as much as
possible, but that takes design and programming effort and if there is
no measurable benefit for exerting that effort, the application
designers won't do it.  We are long past the point where we can count
on the sense of community responsibility to ensure that applications
are well-behaved -- we have to design the system so that acting in ones
own best interest serves, rather than harms, the overall behavior of the
system.

Steve

---

From: Koskelainen Petri <[email-masked]>
Date: Thu, 12 Jun 1997 09:29:54 +0300 (EET DST)

> they must usually rewrite them.

Hmm..Yes, if there is reasonable propability that setting priority bits
will mean something (in the edge-router where most problems are) then yes.

> are well-behaved

I disagree.
Reducing own bitrate will also increase the probability that
the "more important" packets of that flow will get through.
I think this will encourage application developers to 
do things right.
And always, some receivers may be behind very low bitrate links, 
so it's better to use as small bitrate as possible.

Moreover, billing may depend on the amount of packets etc.
This also encourages not to send much traffic.

Petri

---

From: Steve Deering <[email-masked]>
Date: Thu, 12 Jun 1997 15:18:30 -0700

> the "more important" packets of that flow will get through.

Reducing or increasing the bitrate of the marked packets would not have
any effect on the probability of delivery of the unmarked packets, if
the bit were honoured by the routers in the way you wish, right?

> I think this will encourage application developers to

What will encourage them not to send streams of undeliverable packets
marked as less important?

> so it's better to use as small bitrate as possible.

But your priority bit or bits would let them send any amount of additional,
lower-priority packets towards those slow links without doing any harm to
the higher-priority packets.  That would be just the sort of thing you
would expect the designer of a real-time multicast app to do, so that
receivers reachable over higher-speed links would get better quality
reception.  A lot easier than the more network-friendly approach of
putting the different layers on different multicast groups and having
the receivers dynamically adapt to the right number of groups to avoid
loss.

> This also encourages not to send much traffic.

Someday.  Maybe.  If an infrastructure for universal, Internet-wide, per-
packet billing of best-efforts traffic from individual sources should
come into existence, that might be an appropriate time to consider adding
the feature you are requesting.

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

Steve

---

From: Koskelainen Petri <[email-masked]>
Date: Fri, 13 Jun 1997 12:02:14 +0300 (EET DST)

Let's first summarize what has been proposed for this IPv6 header:

To use one bit for Drop Prefedence, preferable from version field 
since priority bits are already in use and routers may rewrite them and 
original information is then lost.  Many people in list have emphasized
that this information should not be altered in the network.

Anyway, there would be two usages for that bit:
1) To mark RSVP excess traffic (by router)
2) To mark less important data (by application)

More research might be needed for case 1) but we have to decide things now.

>the receivers dynamically adapt to the right number of groups to avoid

True for multicasting, but receiver may be unicast.
This approach does not work then.
Or do you think it is ok to use multicast addresses for 
(hierarcially encoded media) one-to-one communication as well?

>                 I haven't heard anyone present a solution to the

> loss-priority feature.  Please explain how you would avoid the potential

I have still a doubt about these harmful consequences.

If application uses this presented feature (mark some of its packets
with drop label) current situation continue and only change is that
routers (at least some routers, for example just before slow mobile link)
have the ability (if they provide that feature) to drop enhancement data.

If we don't define this Drop bit, then situation is as today:
Applications send same amount of data as they would with Drop bit defined.

This Drop bit does not change applications beheviour.

So, if we specify Drop bit which is not changed by routers (except 
possible RSVP excess packets), we can't loose anything but we may
win something.

Petri

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 14 Jun 1997 22:35:27 +0300

the above doesn't sound like sound design, but rather a set of hacks.
the real solution is to have a real qos field in the header that is
setable by the application and possibly resetable by the network.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 15 Jun 1997 00:13:52 +0300

craig said that if the user sends above the contract, the service that
it receives will be useless.  so i don't quite see the need to mark
anything in such a case.

i don't know how useful a priority field is.  i would prefer to have a
three bit qos field and a one bit loss priority field.

-- juha