Subject: Re: new document: "controlled-load" service

From: Sally Floyd <[email-masked]>
Date: Thu, 30 Nov 95 17:36:53 PST

John -

>(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"

Many thanks for the controlled-load document - Lixia and I both like it.

>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.

Exactly.  

...
>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.

I think it would be a big step forward if some decision about a
minimal-service-profile came out of the Dallas intserv meetings.
In my view, either a minimal service as a subset of controlled-delay 
OR a minimal service as a separate controlled-load document would be a
viable option.

Completely apart from how this decision is made, I think that the
controlled-load draft has many helpful informal discussions about
a controlled-load service - guidelines for implementors, a discussion
of the range of possible admissions control procedures, and so on.

- Sally

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 01 Dec 1995 08:56:41 +0000

>Many thanks for the controlled-load document - Lixia and I both like it.

yes, - forgot to say, but mark handley & I were very pleased to see
this - we are '1 bit' fans:-)

 jon