Subject: two proposals sent around

From: Craig Partridge <[email-masked]>
Date: Thu, 24 Aug 95 11:51:13 -0700

Hi folks:

    Roch Guerin has sent around two proposals for modifications to the
guaranteed service document.  Although Scott Shenker is listed as one of
the co-authors of the proposals, no decision has yet been made about whether
to include the proposed changes.  I'd like to thank Roch and his colleagues
for the work they've put in on the proposal and like to encourage folks
to express their reviews.

    As a starter, here are my views:

    I think the peak rate proposal is a win.  It improves service in several
ways (listed at the start of the proposal), the calculations for using
it are straightforward, and the only downside is we have to carry around
an additional value in our Tspec, but I think many people would take
advantage of it in their implementations.

    I'm less happy about the slack term.  It has fewer benefits and feels
messier to me (it expects routers to dynamically worry about internal delay
terms), sufficiently messy that many folks won't use it -- and while I
understand that if one doesn't use it, it is just extra bits, I tend to
prefer not to require folks to carry bits that aren't goin to get used.
(Perhaps a case of KISS).

    So if I were revising the guaranteed draft tomorrow, I'd be inclined to
add peak rate but not the slack term.  (I will, in fact, be revising the
draft shortly based on comments on the last draft from various folks)>
I'd very much like to hear from people who think this is either (a) the
right approach or (b) the wrong approach.

Thanks!

Craig

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

---

From: Steve Jackowski <[email-masked]>
Date: Thu, 24 Aug 1995 15:25:59 -0900 (PDT)

Craig,

> advantage of it in their implementations.

No question about it!  

> (Perhaps a case of KISS).

I think their proposal is valid.  I'd really like to 
see a two pass flowspec to assure end to end delays, 
jitter, and MTU size, but failing a two pass 
QoS agreement, I believe that the slack term will permit 
better admission control decisions and tend to smooth out hop by 
hop rejections which might well be averaged out.  In 
addition, it helps provide a bound on jitter which I know 
many don't find useful, but I do.

Finally, I think it will facilitate mapping QoS 
requirements and associated guarantees to ATM interfaces 
which specify both delay and variance.

Steve