Subject: Returned mail: User unknown

From: [email-masked] (Mail Delivery Subsystem)
Date: Mon, 28 Nov 1994 10:47:38 -0800

----- Transcript of session follows -----
While talking to isi.edu:
>>> RCPT To:<[email-masked]>
<<< 550 <[email-masked]>... User unknown
550 intserv... User unknown

   ----- Unsent message follows -----
Date: Mon, 28 Nov 1994 10:47:38 -0800
From: braden
Posted-Date: Mon, 28 Nov 1994 10:47:38 -0800
Received-Date: Mon, 28 Nov 1994 10:47:38 -0800
Message-Id: <[email-masked]>
Received: by can.isi.edu (5.65c/4.0.3-4)
	id <AA01801>; Mon, 28 Nov 1994 10:47:38 -0800
To: intserv
Subject:Cc: rsvp

Fred,

This issue properly belongs in the bailiwick of the int-serv
WG, so I am forwarding it there.

Bob

----- Begin Included Message -----

>From [email-masked] Wed Nov 23 01:31:01 1994
X-Sender: fred@nacho
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 23 Nov 1994 01:04:54 -0800
To: [email-masked]
From: [email-masked] (Fred Baker)
Subject: "minimal subset" flow specification
Content-Length: 3855
X-Lines: 75

In the very near term, I need some aspects of a "minimal subset" flow
specification nailed down so I can implement and deploy it, and so that
hosts have some clue as to what they are requesting and how I can be
expected to respond. This includes:
        - information elements exchanged
        - requirements for router algorithms

Understand, please, that I am in no sense looking for the ultimate
solution. I don't think we know what that will eventually be. However, the
Type 1 flow specification (CSV) seems describe things we know to be
essential today, and it seems like we can add flow specification formats as
we get smarter in the future.

So, let's nail down an initial version of the flow specification that will
be useful for the current generation of products. The Type 1 flow
specification now defines:

        QoS     (optimize for bandwidth, optimize for delay)
        Mean bandwidth required
        Maximum per-hop acceptable delay
        Maximum amount of data a router should store for a given flow

A couple of observations:

The text describing the type 1 flow specification meant something different
to Scott than it meant to me, when we spoke earlier this evening.

 - For predictive service, I have been thinking in terms of efficient
   deadline scheduling, which may be an oxymoron. Scott has been thinking
   in terms of a set of priority queues, which are sorted by (perhaps)
   order of magnitude of the delay bound. I would appreciate it if the
   specification more clearly stated the expectations here.

 - I am expecting to implement the queuing using a WFQ algorithm
   (applause). ABR traffic uses a weight that only a mother could love,
   while real-time guaranteed traffic uses a weight derived from the mean
   bit rate and the access rate.

   Predictive traffic, if I follow Scott's reasoning (I've been known to be
   a trifle dense), wants to have a single data link "conversation" per set
   of flows through the same next hop having a common delay bound, so that we
   are essentially implementing CBQ where the delay bound defines the class.
   I think I still want to include these in my WFQ data structures, but with
   weights that give predictive traffic a very high throughput capability.

   Note that I make no mention of burst capacity. I have no current plan to
   use that information, just QoS, mean bandwidth (for reservation) and delay.

   I don't think every router vendor is going to do things my way,and frankly
   I hope they don't. So what I need in the specification is a detailed set
   of requirements for the router's algorithms. What is it that, if the
   algorithm doesn't achieve it, the implementation is broken? Given a set of
   requirements, I can figure out an implementation that will meet them.

In an ATM cloud, an obvious use of an RSVP reservation is parameterization
or negotiation of a per-multicast VC. In order to do that, I need not only
the *mean* data rate (that's what *I'll* reserve based on), but the *peak*
data rate - I need to tell the switch about the peak data rate. I suggest
that we ask for that information in the initial version of the flow
specification.

May I suggest that the type 2 (RFC 1363) flow specification primarily
muddies the water? If the type 1 specificiation will meet the needs of
current generation applications, and Craig himself doesn't quite know what
to do with all the fields he has specified, I think the main effect of
pointing to RFC 1363 is to make application vendors ask which they should
use, and sometimes pick wrong. We would to better to yank the reference to
RFC 1363, and add it in later when we have identifiable requirements and
algorithms to solve them.

=============================================================================
        If you're not living on the edge, you're taking up too much room!

----- End Included Message -----

----- End Included Message -----