Subject: policing

From: [email-masked] (Bruce Davie)
Date: Sat, 13 May 1995 14:42:46 -0400

While thinking about this policing issue and the 3 sender audio
conference I described previously, the following thought occured to
me. Let's suppose that the merge point policing action is to drop
excess packets, and that I reserved enough resources to accomodate 2
speakers. When 3 speakers send at the same time, 1/3 of the packets
are dropped. However, if the links are uncongested and if I had made
no reservation at all, I would have received all the packets. So I
actually get worse service by making a reservation. Even worse, some
other receiver who shares some section of my multicast tree and who
made no reservation might find 1/3 of the packets being dropped
because my reservation is being policed, not because the network is
over loaded. 

The above scenario, if true, would seem to add weight to the `don't
police by dropping' argument I made earlier. It seems so unfair that
I'm wondering if I've overlooked something, so please feel encouraged
to show me where I've gone wrong in my reasoning.

Bruce

---

From: David Clark <[email-masked]>
Date: Tue, 16 May 95 14:36:50 -0400

I think you have not missed anything. 

Policing at the "edges" and at the merge points seems to have two different
purposes. 

Policing at the edge "seems" to deal with malformed hosts that oversend, and in
that case, dropping seems like a reasonable punishment. The assumption is that
the host can shape the traffic to fit inside the policing profile, so dropping
would not normally happen.

Policing at a merge point is to deal with statistical overloads caused by
acceptable but improbable host behavior. It seems as if a less hostile
alternative to dropping might be appropriate. If we had a scheme to mark packets
as more or less valuable, then the merge police point could just mark the excess
as less valuable, which would mean that iff the packets hit a congestion point,
the excess would be dropped.

So far, we have not managed to get a full spec for controlled dropping service,
but I think it is a key idea, and would love to see it worked out. This suggests
yet another purpose for it.

Dave

---

From: [email-masked] (KATSUBE Yasuhiro)
Date: Wed, 17 May 1995 23:59:06 +0900

Dave, 

I agree with Dave for the most part, but could you let me clarify a couple
of points? 

>> that case, dropping seems like a reasonable punishment. 

Does "the edge" mean only the first-hop router for the datagrams?  Doesn't
it mean inter-domain router also?  I have a feeling that if we surely would
like to protect our own network in terms of the amount of incoming traffic,
we had better install policing function at inter-domain routers also. 

>> yet another purpose for it.

Marking would be better and milder way to handle statistical overloads at 
merge points.  In this case how will the "marked datagram" be handled in the
network, in other words, what is the priority definition for the marked 
datagram? 

Introduction of "marking" would not mean any change of delay priority of the 
datagram but the introduction of new priority class "loss tolerable class" 
into the router network.  That means routers should install selective discard
capabilities in addition to delay-based (guaranteed, predictive, etc.) buffer
control capability.  
For instance, a flow requesting guaranteed-delay service may have two loss 
priority levels "intolerable" and "tolerable" because of marking.  When 
congestion occurs, the intolerable datagram had better be discarded even when
it is at the head of the output queue in order to assure delay quarity of
other guaranteed-delay service flows.  Defining threshold at queue length and
discarding arriving marked datagrams based on the queue length would not be 
enough, since marked datagrams already in the queue before congestion occurs 
may deteriorate the delay of arriving other guaranteed-delay service flows. 

I cannot say how much but installing selective discard capabilities to routers
would increase the cost for buffer management. 
Marking itself is not bad, but I am wondering about the increase of buffer 
management cost and complexities in QoS estimation algorithms in addition. 

Do we have to manage to resolve that or have other alternatives for this issue?
Or am I missing something? 

Yasuhiro Katsube
Toshiba R&D Center