Subject: Roch Guerin: Re: delay budget

From: Roch Guerin <[email-masked]>
Date: Tue, 24 Jun 97 15:26:17 -0400

Ooops, realized I forgot to cc: the list to my response.
Roch
------- Forwarded Message

Date:    Tue, 24 Jun 97 12:53:19 -0400 
From:    Roch Guerin <guerin>
To:      [email-masked] (Jan-Peter Richter)
Subject: Re: delay budget 

>As far as I understand, in GS the receiver uses the IS hop count of the
>received ADSPEC to determine the share of the desired delay budget which each
>IS-router may spend. This is done by dividing the budget by the hop count.
>(right?)

That's not really how GS works.  What you are describing would apply
to a "delay-based" approach to ensuring delay bounds, while GS relies
on a "rate-based" approach.  In other words, GS does not define a delay
budget to be spent at each hop, intstead it lets the receiver determine
the clearing/service rate it needs from ALL network elements in order to
meet its delay bound.  The underlying assumption is that the scheduler
at each network element attempt to emulate a constant rate server (at
the rate requested by the receiver) with some "error term" that they 
advertise, e.g., due to packetization delays and scheduling contention
between packets from different flows.  An example of such a scheduler is
weighted fair queueing (WFQ) and its many variants.  There are also ways
to use a delay-based scheduler, e.g., an earliest deadline first
scheduler, to implement such a service (we had a paper on that topic in
Sigcomm'96), so that the model is rather general even if it requires
that the *same* rate (at least as a first order approximation) be allocated 
at each network element.

So, to answer your question:

>Is there a way to divide the budget unequally among the routers?

This is not really an issue in the case of GS.

The only place where this may arise, is in the context of the slack
term as you may want to have specific rules to determine how it is
being apportioned.  There has been a number of proposals on how this
could be done (can check the mailing list archives, I think), but 
in order to achieve some particular goals, e.g., fairness, efficiency,
etc., they typically require collaboration, or at least agreement on a
common rule, by the network elements on the path.

>What happens if non-IS routers are part of the path (as indicated by the
>break bit)? I suppose, no special action is taken and the guarantee is
>simply 'downgraded' to be approximate, since non-IS routers may spoil
>the guarantee anyway. (right?)

Yeap, the "service not supported" bit is turned on, so that you (the
receiver) knows that there is a hole somewhere.  The only drawback is
that this is a binary indication, so that you don't really know how
big the hole is (how many routers do not support the service).  For all
you know it could simply be the O/S in the sender end-system that set
the bit on as it does not have scheduling support for GS, but all the
routers on the way are OK.

>Any enlightenment is appreciated.

Not sure the above qualifies, but I hope it helps.

RochDate:    Tue, 24 Jun 97 12:53:19 -0400 
From:    Roch Guerin <guerin>To:      [email-masked] (Ja
	  n-Peter Richter)Subject: Re: delay budget 

------- End of Forwarded Message