Subject: looking for comments

From: Craig Partridge <[email-masked]>
Date: Wed, 10 Jan 96 11:19:59 -0800

Hi folks:

We had two near-term action items from the last meeting that need
to be wrapped up shortly.

First, we need to review the revised controlled load spec to see if 
folks are comfortable going forward with it as a proposed standard.
John Wroclawski circulated a revised draft about a month ago.
I've heard no comments.  Should I assume assent?

Second, at IETF, we decided to issue a new version of guaranteed that
contained a slack term, and ask everyone to read it, and decide if
they liked the slack term or not.  Roch Guerin has fulfilled his
side of the bargain  and produced a new draft (again about a month
ago), but I haven't seen much reaction to the slack term.  Do people
want it or not.  (Note, Roch also cleaned up the draft in other ways --
I'd propose to keep those improvements regardless).

If we don't get e-mail reactions quickly, we'll have to call an
interim face-to-face meeting (yuck...)

Thanks!

Craig

---

From: [email-masked] (Fred Baker)
Date: Wed, 10 Jan 1996 12:27:50 -0800

>interim face-to-face meeting (yuck...)

I will go back and read those again. I do have to say that when I read them
last, there was much improvement. You have, however, seen some commentary
by me affecting controlled delay and predictive services :^)

One thing that I think was supposed to be included in the updated drafts
was a picture of the flowspec data structure, in an appendix, specifying
values for names, and offsets. I'd like to see that.

One additional question: The current "guaranteed" draft (end each of its
predecessors) says:

   Guaranteed service guarantees that packets will arrive within the
   guaranteed delivery time and will not be discarded due to queue
   overflows, provided the flow traffic stays within its specified
   traffic parameters.  This service is intended for applications which
   need a firm guarantee that a packet will arrive no later than a
   certain time after it was transmitted by its source.  For example,
   some audio and video "play-back" applications are intolerant of any
   packet arriving after their play-back time.  Applications that have
   hard real-time requirements will also require guaranteed service.

It occurs to me that the example is a poor one: an application that is
seeking to stabilize its playback point is not measuring the end to end
delay, the delay since *transmission*. It is measuring the variation
between the earliest possible time-to-reciept and the earliest
time-to-reciept in which a message has a certain probability of having been
delivered. The point is not "within what time after *transmission* may the
message be held without giving it to the codec to display?", but "how long
after I *receive* a message must I hold it to assure that all other
relevant messages have a high probability of being received?". An
application seeking to minimize its playback point needs to maximize
probability of delivery and minimize variation (stabilize jitter) in delay,
but does not need to minimize end to end delay.

I wonder if there is a better example of an application that needs
assurance of end to end delay? Stock Quote distribution?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Some ideas are so crazy that only an intellectual could believe them...
        George Orwell