Subject: controlled delay service

From: Ashish Mehra <[email-masked]>
Date: Thu, 30 Nov 1995 02:49:12 -0500 (EST)

Hi folks,

I have a few doubts regarding the specification for the controlled
delay service class, and would appreciate if some of you can clarify 
the following:

I. Treatment of non-conformant traffic

The specification states that
    
    "At all policing points, non-conforming packets are treated as 
    best-effort datagrams....Other actions, such as delaying packets
    until they are compliant, are not allowed."

Consider the situation when a non-conforming datagram proceeds as 
a best-effort datagram and is awaiting transmission by the link
scheduling "module". Assume that best-effort traffic has lower priority
compared to other "real time" traffic, and all best-effort traffic
is merged onto a single FIFO; thus there may be a potentially large
delay in transmitting such packets. After some delay a conforming packet 
may arrive on the same session. Now, care must be taken to first
"drain" all outstanding packets on this session before transmitting
this conformant packet, if the order of packet transmissions is
to be preserved. Since this introduces additional complexity in the
implementation, how important is it to preserve the order of packet
transmissions (relative to packet arrivals) on a given session?

Allowing all non-conforming packets to be held back until conformance 
ensures that the above situation does not arise, if a FIFO packet
queue is maintained for each session. One could, of course,
choose to drop non-conforming packets but that violates the 
guideline of maintaining a very low level of packet loss.

II. Admission control

The specification gives an example of an implementation which performs
admission control as follows:

    "Each controlled delay service level would be associated with a 
    target queue utilization level, say 20% of level 1, 50% for the 
    combination of levels 1 and 2, and 70% for the combination of all
    three levels....."

Now, suppose there is no traffic in levels 1 and 2, and a whole bunch
of flows request admission in level 3. Since there is no traffic
in levels 1 and 2, all of the 70% is taken up by level 3 traffic. 
Now if level 2 flows request admission, the above approach would
only look at the combined link utilization of levels 1 and 2 and
admit flows up to 50% target queue utilization. Taking all the
levels together, however, the link has been over-committed. 
Shouldn't we be assigning target queue utilization levels to 
each level separately and performing admission control accordingly?

III. Basic service model for controlled delay

I think it was Fred's observation that having three (or some number)
of levels, with static priority between them, and measuring packet
delays for each level over 3 different intervals does not really
provide the application with a "meaningful" estimate of network
delay. As he suggested, the service levels should correspond to 
delay targets and the selection of packets from these levels should
be based on the associated deadlines. This seems quite reasonable
to me, but there has not been any followup discussion. If delay
targets are indeed provided, how many levels should a network element
support and how should the delay targets be chosen? 

Ashish

---

From: Lee Breslau <[email-masked]>
Date: Thu, 30 Nov 1995 09:40:23 PST

> . . .
Note that the reason that non-conformant packets are not dropped has
nothing to do with maintaining low packet loss for controlled delay
service.  The service only needs to provide low packet loss as long as
traffic conforms to the TSpec.  An application that sends non-conforming
traffic may or may not experience low packet loss. 

The reason that non-conformant packets are treated as best effort (rather
than being dropped) is to prevent the service a best effort receiver of
a flow receives from being severely degraded due to another receiver
making an inappropriately small reservation for the flow.  (This is 
a problem that I believe JJ raised on this mailing list several
months ago).  There is additional discussion of this issue in the Design
Notes document, and it will be a topic for discussion next week.

> . . .
It appears that the algorithm described in the draft is underspecified.
I think the intention is that when a new flow arrives in level 1, 
checks must be performed on the level 1 utilization, on the combined 
utilization of level 1 and level 2, and on the combined utilization of 
levels 1, 2 and 3.  

Thanks for pointing this out.

The algorithm you suggest also works.  It differs from the (correct version
of the) one specified in the draft in that it allows less flexibility
in the allocation of resources across different classes.

> support and how should the delay targets be chosen? 
A service in which each level corresponds to some target delay sounds
more like Predictive service to me.  The intent of Controlled Delay
is to be a fairly minimal service and therefore there is no requirement
that an implementation meet any target delays.  Of course, an implementation
is free to maintain delay targets internally, but it is not a requirement
of the service.

> Ashish 

Lee

---

From: Lee Breslau <[email-masked]>
Date: Thu, 30 Nov 1995 09:40:23 PST

Lee