Subject: new document: "controlled-load" service

From: John Wroclawski <[email-masked]>
Date: Sun, 26 Nov 1995 00:02:33 -0500

Hi folks,

(Hopefully) following this note in your mailbox is an I-D called
"Specification of the Controlled-Load Network Element Service". A copy
of this is also available from the usual places as
"draft-ietf-intserv-ctrl-load-svc-00.txt"

This is a new and perhaps slightly surprising document, and deserves a bit
of explanation.

Controlled-load describes a "minimal" service, similar or perhaps
identical to what Sally Floyd, Lixia Zhang, and others have proposed
in the past. Technically, two things set it apart from the other
service documents currently under discussion.

  - It doesn't explicitly talk about delay. Instead, the basic contract
  controlled-load makes is that if your reservation is accepted you'll
  get behavior closely approximating what you'd get from the same path
  under unloaded conditions. The draft says more about what that means,
  but the basic idea is that simple.

  - It is aggressively minimal. There are no exported measurements or
  characterizations, and no control parameters (levels of service, delay
  targets, etc). In return, there are no questions about what these
  parameters mean to a particular implementation, whether a specific
  implementation supports all of them, and so on. All implementations of
  controlled-load will be identical in this regard.

I wrote it for a number of reasons, which are related to the points
above.

1) There have been some vaguely stubborn open issues with the
controlled-delay service, including whether or not the
level-of-service parameter should have a "global" delay meaning, what
the precise definition of the delay measurement functions should be,
whether the measurements should be optional or mandatory, whether the
measurements were even useful, etc.

The thing about all of these is that there's no obvious right choice;
in each there are good arguments for more than one answer. In at least
one case (the question of whether there should be a global meaning for
the level-of-service parameter), the choice of answer actually changes
the meaning of service definition quite fundamentally. 
  
These issues presumably remain open because we have a lack of
experience with using this stuff, and hence no real criteria to go on
other than instinct.  I decided that it would be interesting to see
what a service specification which didn't raise any of these open
issues might look like. If people believe it is useful, it might allow
us to both move ahead quickly and give some more thought and time to
some of these issues.

2) The minimal-service-profile question: A number of folks,
representing both vendors and customers, have recently suggested that
there should be a minimal "service profile" supported by every
integrated service router. There's widespread agreement that if this
profile is adopted, it should include a non-guaranteed service.

One suggested candidate is a slightly modified version of the
controlled-delay service.  The current controlled-delay specification
already allows an implementor to ignore the three levels of service
and support only one. The suggestion is to also make supplying the
actual-delay measurements optional, so that implementations for which
this was difficult or impossible would still be conformant to the spec
(for example, it might be quite difficult for a frame-relay network to
actually collect measurements of end-to-end packet delay).

Another plausible candidate would be a service such as the one
described in this note. In this case, the service specification
defines more limited functionality, but can be implemented in its
entirety by most any network element.

I was interested in seeing this choice between richer-but-optional and
smaller-but-universal made, if the group decides to make it, on the
basis of having documents in hand for both possibilities.

3) Thinking about this stuff, and chatting about it with a few other
folks, I've moved away from the view that the amount of delay, defined
traditionally and considered by itself, is a particularly useful
control knob for non-guaranteed services. This note is an attempt to
write down a service which would be useful and intuitive to folks
building internet applications today, while not focusing on delay so
much. 

-------

There are also some places where this service specification differs
from the other current service specifications, but aren't actually
intending to define significant differences in the services. Instead,
they're there just because of things that came up or got worked out
after the other specs were written. The section on policing is a
particular example of this (in fact most of that section is an
explanatory note, not a spec..)

-------

The stuff in this i-d is based completely on ideas from and
conversations with Dave Clark, Bruce Davie, Sally Floyd, Craig
Partridge, Scott Shenker, and Lixia Zhang (which certainly doesn't
mean they all -agree- with it, mind you). These folks also read it on
very short notice last week. Thank you!

			-john