Subject: question about RFC 2211 (Controlled Load)

From: Martin Karsten <[email-masked]>
Date: Tue, 4 Aug 1998 16:51:17 +0200 (MET DST)

Dear all,

the last paragraph of page 4 in RFC 2211 (Spec. of Controlled Load...)
states:
"If a flow receives exactly its promised token rate at all times, queueing
caused by an over-rate burst arriving at the network element may never
clear, causing the traffic queueing delay to permanently increase."

I understand that under worst-case conditions, the queueing delay incurred
by a burst followed by a traffic stream at exactly the token rate would not
be cleared, if the flow is serviced with exactly the token rate. However,
from my understanding of a token bucket specification, once a full burst
is sent (and the tokens are "used"), continuous sending with the token rate
prohibits generating another burst. In other words, the delay can increase
up to the "time equivalent" of the burst size, but it cannot increase
further, at least when considering a single node.

Am I wrong or misunderstanding the spec?

Another issue:
When considering multiple nodes in the context of both, CL and G service,
it's often said that the burstiness of the
traffic can increase from hop to hop, but it is hardly explained anywhere
how exactly this would happen. I have two scenarios in mind, which could
cause traffic burstiness to increase:
1) Merging and Splitting points (RSVP/Multicast) with different reservations
I.e., since it's not exactly defined how and which packets from a flow are
forwarded to an interface with a "smaller" reservation, the downstream
router experiences traffic flows not adjusted to the local TSpec.
2) A clumping effect analogous to what is described by the C and D error
terms of Guaranteed services.

Am I correct with these two points? Are there any other possibilities?

Thanks in advance,
Martin

---

From: Craig Partridge <[email-masked]>
Date: Tue, 04 Aug 1998 08:24:01 -0700

>Am I wrong or misunderstanding the spec?

No.  The language in the spec is intended to say exactly what your text
says -- namely if you put a burst in, it may (permanently) increase your
queueing delay by the size of the burst.

>Am I correct with these two points? Are there any other possibilities?

Certainly (2).  I'd have to think about (1).

Craig