Subject: controlled load overload (was: Re: Concerns about exported numbers)

From: Curtis Villamizar <[email-masked]>
Date: Sat, 20 Jan 1996 11:34:08 -0500

Sorry to jump into this late.  There is clearly disagreement about how
to treat controlled load traffic that is outside the traffic spec.
I'd like to make (or maybe repeat) a suggestion.

[ summary: make "b" == 0 a legal value in ctrl-load-svc and make it
available for use with elastic traffic. ]

The Problem:

Controlled load needs to be friendly toward at least two very
different types of application:

	adaptive real time
	elastic

Plus it would be nice if it were tolerant of small transgressions on
the part of real time flows due to accumulated queueing jitter (making
traffic that was sent as conformant no longer conformant).

Right now we have:

   The TSpec takes the form of a token bucket specification plus a
   minimum policed unit (m) and a maximum packet size (M).

   The token bucket specification includes a bucket rate r and a bucket
   depth, b.  Both r and b must be positive.  The rate, r, is measured
   in bytes of IP datagrams per second. Values of this parameter may
   range from 1 byte per second to 40 terabytes per second. Network
   elements MUST return an error for requests containing values outside
   this range. Network elements MUST return an error for any request
   containing a value within this range which cannot be supported by the
   element. In practice, only the first few digits of the r parameter
   are significant, so the use of floating point representations,
   accurate to at least 0.1% is encouraged.

   The bucket depth, b, is measured in bytes. Values of this parameter
   may range from 1 byte to 250 gigabytes. Network elements MUST return
   an error for requests containing values outside this range. Network
   elements MUST return an error for any request containing a value
   within this range which cannot be supported by the element. In
   practice, only the first few digits of the b parameter are
   significant, so the use of floating point representations, accurate
   to at least 0.1% is encouraged.

   The range of values allowed for these parameters is intentionally
   large to allow for future network technologies. Any given network
   element is not expected to support the full range of values.

   The minimum policed unit, m, is an integer measured in bytes.  All IP
   datagrams less than size m will be counted against the token bucket
   as being of size m. The maximum packet size, M, is the biggest packet
   that will conform to the traffic specification; it is also measured
   in bytes.  Network elements MUST reject a service request if the
   requested maximum packet size is larger than the MTU of the link.
   Both m and M must be positive, and m must be less then or equal to M.

   The preferred concrete representation for the TSpec is two floating
   point numbers in single-precision IEEE floating point format followed
   by two 32-bit integers in network byte order.  The first value is the
   rate (r), the second value is the bucket size (b), the third is the
   minimum policed unit (m), and the fourth is the maximum packet size
   (M).

What this means to the user today:

For elastic traffic, setting a low "r" and very high value of "b"
might seem like an option.  One approach might be to make "b"
proportional to the share of the bandwidth the user expects to get
under favorable conditions.  This is very impractical and I could see
setting this "guess" to be the TCP window size.  

Consider as an example, a congested DS3 link with 500 flows who would
like at least 64 kb/s but think they might be able to use a 50KB
window under favorable conditions.  You'd be getting a request for a
total of 32 MB of queueing.  You should deny any request beyond your
queue capacity and you should queue up to the limit of what you
claimed to be able to accept.

The only workaround is to set "b" according to something closer to
worst case, if you could guess what that would be.  Under favorable
confnditions, if drop was done on non-conforming traffic, a lot of
premature drop would occur.  This sort of takes the "elastic" out of
elastic traffic.

The Suggestion:

The problem is that with elastic traffic, how much to buffer for a
particular flow before you drop depends on the total capacity and load
at the congestion point, not the characteristics of that particular
flow.  A better scheme would be for elastic traffic to simply specify
the desired minimum rate "r" and not specify a "b".

Currently the value zero is an illegal value of "b".  This value zero
could be used to indicate that this is elastic traffic.  [ aside: The
value of "r" is used to dictate a weight in WFQ or CBQ ].  The network
element at the congestion point could then monitor the total queue
capacity in use and take appropriate action when too much is being
accumulated in the queue on the basis of an algorithm of the vendor's
choosing (ie: tail drop, EPD, RED, or something else)

Curtis

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 22 Jan 1996 09:56:31 +0000

Curtis

 jon
ok - so we need a bit in IP to say that for controlled load traffic,
there are two service models, and an applicaiton can choose which
suits best

or else we need to subdivide the service model....

but surely its easier than this....sureally the Internet should _only_
provide controled load, and those that do RSVP get the guarantee plus
drop service model, and those that don;t get the guarantee + delay service
model (under congestion as defined for the proportion of the capacity
allocated to each service class...)?

jon