Subject: Question on your Dec 15 msg "template doc"

From: [email-masked]
Date: Mon, 23 Jan 1995 16:37:40 -0800

Scott,

You wrote:

   4)  Ordering relations

   The service module must be able to answer questions about the ordering
   between different service requests.  This is used when merging service
   requests from different receivers.  One service request is greater than
   or equal to another if and only if both its TSpec and its RSpec are
   greater than or equal.

The last sentence appears to define only a partial order, which is
insufficient for merging.

Bob

---

From: Scott Shenker <[email-masked]>
Date: Mon, 23 Jan 1995 17:28:56 PST

> insufficient for merging.

Bob,

I've only got a few minutes now, but I wanted to respond with two quick
points.

First, any ordering involving token bucket based TSpec's gives only a
partial order, because of the two parameters.  This isn't a new problem
introduced by using both the RSpec and the TSpec.

Second, merging with only a partial order is doable, in fact I have
heard you utter those words.  To merge two service requests, you take a
least upper bound of the two requests (by taking a least upper bound of
the TSpec's and a least upper bound of the RSpec's).  If there is no
such upper bound then you can't merge.  That only becomes a problem
when the two RSpec's aren't comparable (e.g., predictive and
guaranteed).  I am sure I have heard you say this before.  Am I
hallucinating, or just missing your point?

--Scott

---

From: [email-masked]
Date: Tue, 24 Jan 1995 08:11:51 -0800

*> 
  *> First, any ordering involving token bucket based TSpec's gives only a
  *> partial order, because of the two parameters.  This isn't a new problem
  *> introduced by using both the RSpec and the TSpec.
  *> 
  *> Second, merging with only a partial order is doable, in fact I have
  *> heard you utter those words.  To merge two service requests, you take a
  *> least upper bound of the two requests (by taking a least upper bound of
  *> the TSpec's and a least upper bound of the RSpec's).  If there is no
  *> such upper bound then you can't merge.  That only becomes a problem
  *> when the two RSpec's aren't comparable (e.g., predictive and
  *> guaranteed).  I am sure I have heard you say this before.  Am I
  *> hallucinating, or just missing your point?
  *> 
  *> --Scott
  *> 

Scott,

My point was only that the template doc's 1-sentence prescription for
finding a "max" reservation request is incomplete.

Bob