Subject: Re: Qry on Traffic Policing

From: Mark W Garrett <[email-masked]>
Date: Tue, 10 Jun 1997 10:37:13 -0400 (EDT)

> Policing will mark a flow's nonconformant packes so that they may 
 > not be involved in meeting service committments.        

In IP, policing will cause nonconformant packets to be scheduled
so they get "best effort" service (in the node where the policing
occurs), but there is no mechanism, I believe, to carry the 'mark'
around with the packet.  Dave Clark had a paper last year on this idea
and some nice analysis and suggestions.  In ATM, such a marking bit
does exist (the CLP bit), and an IP-IS over ATM implementation could
use CLP marking in the ATM subnet based on IP-level policing.  Once
you get out of the ATM cloud though, the "tag" is lost.

I don't know whether there is an advantage or disadvantage to policing
once and "permanently" marking some packets as the non-conforming
ones, as opposed to policing/marking locally and separating packets
into conforming and non-conforming at each hop independently.

-Mark

-------------------------------------------------------------------------------
                        Bellcore   Rm. 1A-220B                  +1 201 829-4439
Mark W. Garrett         445 South St.                          [email-masked]
                        Morristown NJ 07960-6438  USA         Fax: 201 829-2504
                        WWW: ftp://ftp.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: Koskelainen Petri <[email-masked]>
Date: Tue, 10 Jun 1997 20:21:26 +0300 (EET DST)

> and some nice analysis and suggestions.  In ATM, such a marking bit

Yep, it'd nice to have some mechanism to mark those noncomformant packets.
For example, IPv6 version field is very much unnecessary
and one bit from there could be defined as remove bit, set by edge-router
especially for those packets which exceeds their RSVP contract.
(in fact, all misbehaving packets could be marked with R=1
and let succeeding routers to drop those if necessary)

Unfortunately, I guess it is too late to change IPv6 header anymore.

petri

---

From: Steve Deering <[email-masked]>
Date: Tue, 10 Jun 1997 12:46:08 -0700

> Unfortunately, I guess it is too late to change IPv6 header anymore.

No, it's just getting more difficult to change.

The IPv6 header compression proposal has already "claimed" the version field
for its own use, so if you are going after those bits, you should make sure
your proposed usage doesn't collide with that proposal.

Steve

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 11 Jun 1997 08:24:14 +0300

it sounds very artificial to overload the version field to carry also
priority information.  ipv4 has the tos field and that would be a much
more natural place for such a purpose.  two bits for telling the service
class and one for telling the priority within the class.  i understand
that also ipv6 can have a tos field in the extension header.

-- juha

---

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

Obviously we have a problem here. (actually, two problems)

We'd like to mark RSVP excess traffic (and also other
misbehaving flows or just perhaps poorly-paying customers' packets)
with some kind of "this packet can be dropped in the case of (or in
danger of) congestion" in the router interface.

Another problem is that applications don't have the ability to mark
packets with priority information. (note that RSVP is not available 
everywhere and it can not be used for every videophone etc)

Why not solve both these problems at the same time.

One bit is enough for that.
This bit (let's call it for example R bit) can be set by router or by 
end-terminal application.

Router marks packets with R=1 for packets which exceeds their RSVP 
token packet rate, or for poorly-paying customers in some cases.
 
Applications can set this bit anytime. Obvious situation is for
future audio/video applications for which some packets (GOP headers etc)
are very important while some (enhancement layer data) are not very
important. 

As discussed in IPng mailing list (in March 97), many people
opposed applications capability to mark some packets with higher
priority.  This new scenario (R=1) is an opposite strategy which can not
harm network although someone can argue that this encourages applications
to send unnecessary data to network. However, I don't believe that: they
send it anyway. 

Some kind of consensus in IPng was reached (unfortunately) that applications
are not allowed to change priority field bits and the usage of priority
field is left to operators private purposes.
For those who do not know; IPv6 includes 4 bits for priority field of 
which one is (as currently proposed) for Interactive bit and 
3 for operator private use.

Still, many people believe that (non-RSVP) applications should have 
the ability to mark packets with some kind of priority/drop information 
and since priority field is out of the question, why not using 
one bit from version field. (First or last bit from version field)
 
So, I recommend that one bit from IPv6 version field is taken to this 
kind of drop bit, set by either router or application.
The main usage of this bit is to mark RSVP excess traffic by router, and
mark enhancement data (e.g. for video) by application.

As far as I can see, this requires only minimal changes to 
IPv6 header compression proposal.

Petri Koskelainen
Nokia Research Center
Tampere, Finland

---

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

At 1:55 AM -0700 6/11/97, Koskelainen Petri wrote:
> to send unnecessary data to network.

It can harm the carrying capacity of the network.  The undeliverable packets
consume bandwidth on all the hops up to the point at which they are dropped.
That bandwidth would otherwise be available for more productive use by
other flows.

> However, I don't believe that: they send it anyway.

Without router support for drop priority, the transmission of excess
packets into a congestion point causes the "more important" packets to
be equally vulnerable to loss as the "less important" packets.  Thus,
there is an incentive for the applications to be designed not to send
less important packets into congested paths.  If they "send them anyway",
they will harm not only other flows in the Internet, but also their own
"more important" traffic.

Steve

---

From: Steven L Blake <[email-masked]>
Date: Wed, 11 Jun 1997 16:23:43 EDT

> "more important" traffic.

Even if video applications are good at estimating the instantaneous path
bandwidth and adjusting their compression rate correspondingly, packets
will still get clobbered due to transient congestion (or at sustained
congestion onset), which occurs on timescales shorter than the application's
congestion reaction time.  Priority bits would go a long way towards
protecting packets containing motion vectors and intraframe refresh blocks
during these short congestion intervals, and would give the video source
time to react to the congestion event if it persists.  Also, the burstiness
of (shaped) VBR video is such that the rate can vary by a factor of 3-5
within one frame period (~ 33 msec).  Allowing video applications to burst
periodically with 2 levels of loss priority is a very efficient means of
statistically multiplexing video sources while offering good delivery
probability for enhancement-layer packets and excellent delivery probability
for base-layer packets.

[Of course users whose expectations for video signal quality are not as
 adaptive as the roller-coaster quality delivered from the perpetually 
 congested best-effort Internet will utilize RSVP/IntServ instead.]

Regards,
/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven L. Blake                    [email-masked] |
| Internetworking Technology         (919)254-2030 (work) |
| IBM Networking Hardware Division   (919)254-5483 (fax)  |
| "You like the 'Net?  You ain't seen nothin' yet!"       |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/

---

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

binary priority alone is not very useful.  i would prefer a tos
indication so that rsvp would not be needed (or processed) at all.  this
is how ieee802.1p works and there should be a mapping between 802.1p qos
field and ip tos field.

-- juha

---

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

sure, but this is how it is with all best effort traffic.  with the
above logic, best effort traffic should be not allowed at all.

huh, are you suggesting that the network cannot protect guaranteed flows
from best effort traffic?

-- juha