Subject: Re: Integrated Services Implementor's BOF (resend of 4/17 note)

From: [email-masked] (John Krawczyk)
Date: Wed, 10 May 95 12:16:55 EDT

This thread should probably move to the int-serv list, so I'm doing
that (taken from the intserv-test list).

   On Thu,  4 May, Lixia Zhang ([email-masked]) wrote:

   > At 10:21 AM 5/4/95, Lixia Zhang wrote:
   > >- I dont know what you guys are implementing, what service is to be
   > >  supported in the fall demo?  Is that bandwidth reservation by WFQ
   > >  (that's my impression)? That perhaps need be spelt out.
   > 
   > I'm suggesting predictive and guaranteed service; folks I've spoken with
   > seem to have different ideas of what they want to do about that, so for the
   > moment I'm leaving it at "advanced queuing algorithms". Those words were
   > suggested by John Krawczyk.
   
   I'd like to see this spelt out more clearly because I want to better
   understand what would be the end-to-end performance, which is a
   concatination of all these different implementations.
   
Lixia,

It doesn't seem that you would need to know what the underlying
implementation is to determine the end-to-end performance.  If saying
"router X supports guaranteed service as spelled out in the Guaranteed
Service template" doesn't give you enough information, the service
template is broken.

If a particular service has to exhibit external behavior that makes it
look like it has implemented a particular algorithm (e.g., WFQ), then,
the service template must spell this out.  If someone does something
different, but still provides the same external behavior, that's fine.
If the different algorithm doesn't give you what you need, the service
on that router is just plain broken.

That's the reason I asked Fred to change the wording.

   Just remind you that my question came from the assumption that your
   scheduler is WFQ.

   Under WFQ, the end-to-end delay is computed by Parekh formula:
	B/r + (h - 1) * P/r + h*P/bw
   where B=bucket size, r=bucket rate, P=max pkt size, h=hop count,
	bw=link bandwidth
   (if each link along the path has diff bw, then the last term will be a
   summation)

This should be spelled out in the guaranteed service template.  It
also sounds like guaranteed service doesn't work without OPWA -
without the hop count and the bandwidths/MTUs from each link, the end
node cannot figure out the end-to-end behavior.

That all said, I am doing WFQ for guaranteed service.

-jj

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 8 Jul 1995 09:39:01 PDT

> that (taken from the intserv-test list).

and because of the move, I didnt get to see your msg until now :-)
(yes, that says how long I have not been reading int-serv;-( but I'm
trying to catch up now)

better later than never, so here's my response

> Service template" doesn't give you enough information, the service

perhaps my fault for not spell out the details clearly.
- At that time, I recall we had not specified a service type to use
  for the demo (and I had an assumption that each vendor would
  just use whatever they've implemented, that would be a concatenation
  of not necessarily the same service type).

- As one of my research interest, I wanted to understand the *actual*
  end-to-end delay, not the stated bound, which presumbly should not
  be violated if you asked for guaranteed service.
  (At the time, I was thinking about some simulations with each box
  running your individual schemes to see what I may get as end-to-end
  delay, that you people could use to check against the numbers from
  your real code)

> node cannot figure out the end-to-end behavior.

well, depend how precise you meant by "behavior".  If that means
absolute E2E delay, you're right.
But as always, I dont really see a need to guarantee such absolute
delay numbers.

> That all said, I am doing WFQ for guaranteed service.

WFQ guarantees your thruput to say the least.

Lixia