Subject: new guaranteed document

From: Craig Partridge <[email-masked]>
Date: Mon, 18 Dec 95 10:05:02 -0800

Hi folks:

    A new guaranteed service ID (version 4) should be out tomorrow.  I'll
also send text to the list today.

    This is the revised version of guaranteed to include the slack term
proposal from Roch Guerin.  Roch also cleaned up the draft in several spots.
(I've included Roch's note about what has changed below).

    Recall from our meeting in Dallas, that we decided we wanted to see
the slack term version to see if people liked it or not.  The slack term
issue is the only substantive issue remaining in the guaranteed draft.

Reactions to the slack term (public or private) are invited.  While it is
holiday season, if you could provide reactions this week, it would help
considerably.  The goal is to propose guaranteed as Proposed Standard in
early January and we need to know if the slack term is in our out.

Thanks!

Craig

PS: Other comments of nits or glitches to fix in the draft are, as always,
most welcome!

E-mail: [email-masked] or [email-masked]

------- Forwarded Message

Date: Fri, 15 Dec 95 10:38:41 EST
From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: Version of guaranteed service draft with slack term

Craig and Scott,

We are about to send you an updated version of the Guaranteed Service
specs (both the nroff source and the formatted text).  We'll send
them by separate mail, but wanted to outline in a note the modifications
that were made and point to a few remaining issues that may need to be
addressed.

1. Changes that were made
 a) Introduction of the slack term and its handling.
    We have covered its use, format, and requirements, and made additions
    to the sections "Invocation Information", "Ordering and Merging",
    and "Guidelines for Implementors"
 b) We have made a number of minor changes to some of the discussions
    related to the peak rate, i.e.,
    - Added maximum packet size term in some of the formulas,
    - Added mention of the peak rate term in the "Merging" section and a
    few other places,
    - Modified default value for peak rate from all 0s to infinity for
    consistency,
    - Pointed out the possible reduction in buffer requirement by accounting
    for (cumulative) latency, i.e., reduce Dsum by that amount if known.
    - In the section on "Policing", the formula that is given is an
    over-estimate of the buffer needed, so we slightly modified the
    language to reflect this fact.
    - Corrected a typo in the formula on buffer size in the
    "Guidelines for Implementors" section.

2. Some other issues that came up upon re-reading the doc
 a) In the section "Network Element Data Handling Requirements", the
 expression for the local delay bound that a network element must guarantee
 is correct, but may be confusing to implementors.  In particular, if their
 network element simply guarantees that delay without guaranteeing the
 "fluid" rate R, the end-to-end bound could be violated.  It is stated at
 the beginning of the section, but it may be worth reemphasizing here that
 guaranteeing the "fluid" service rate R is also an integral part of the
 requirement.
 b) If we want the network elements to be able to compute the lower buffer
 requirements achievable when the cumulative latency is known, we need to
 specify that this information needs to be made available to them.  This
 could be achieved by having it exported.  Note also that latency is defined
 in the "Service Characteristics" document, but only from the source.  We
 would need it from the last reshaping point as well, in order to use it to
 compute lower buffer requirements.
 c) In the section on "Policing" there is an issue wrt to buffer sizing
 which may be worth pointing out.  Currently it talks about the amount of
 buffering required to reshape the traffic.  However, the expression, in
 addition to be a loose bound, is also a bound on the total amount of
 buffer needed, i.e., including reshaping and queueing at the scheduler.
 It may be worth pointing out that this is the total buffer needed as
 people may otherwise wonder what else they need to add to this for the
 scheduler.

Well, that's about it.  Please let us know if you want us to directly post
the formatted version to the mailing list, or if you'll do it.

Thanks.   Roch

------- End of Forwarded Message