Subject: Re: Service disciplines for RSVP 7/08/95 7/11/95 22:33

From: Steve Jackowski <[email-masked]>
Date: Wed, 12 Jul 1995 09:07:00 -0900 (PDT)

Roch,
> >is HD, so that the delay jitter is 0.
> 
> 
> Actually, upon thinking some more about the issue of the impact of
> releasing packets early in rate controlled service disciplines (to make
> them work-conserving), I must actually disagree with my earlier
> intuition.... Sic...  Allowing early release of packets when the link
> is IDLE in rate-controlled service discipline will not worsen jitter,
> at least not the maximum jitter.
> 
> The reasons are as follows: The best and worst delays which a packet
> can experience are not changed by this modification of the discipline.
> This is easy to see for the best delay, i.e., take a packet (for example
> the first packet of a connection) which is compliant with its
> rate-controller and is, therefore, immediately forwarded to the
> scheduler at each node on its path.  If we further assume that this
> packet sees no contention on its path (all the links are idle), then
> the scheduler will always put it out immediately and the packet sees
> an end-to-end delay which is simply the (constant) propagation delay.
> For the worst case delay, we know (see section 6 of the report mentioned
> in previous notes) that releasing packets early when the link is idle
> does NOT impact the delay guarantees.  Hence, this modification of the
> rate controlled service discipline provides the same delay bounds as the
> non-work-conserving version.  Since the best and worst delays which a
> packet can experience are the same, this then implies that the worst
> jitter is also the same.  Hence, we have not made things worse from a
> worst case jitter point of view by allowing early release of packets.

While it's true that early release of a packet may 
actually improve its delay characteristics, and if we 
define jitter as variance in delay, clearly your argument 
stands.  However, if we look at jitter as difference in 
arrival times between consecutive packets (from the 
receiver's point of view this is a difference in delay), then 
for a CBR stream, I believe that early release of packets has to 
increase jitter.  

We've done some modelling here with codecs and it seems to 
show a regular periodic increase in end to end jitter with 
an intermediate smoothing based on bucket depths.  

> 
> The next question is whether early packet release (in case of idle links)
> may actually help improved overall jitter.  This is a little tricky as it
> depends on the exact definition of jitter (a very elusive thing).  If we
> 
> Again, providing zero jitter is quite difficult as it requires that we
> either impose both an upper and a lower bound on the operation of the
> scheduler or that we have mechanisms to dynamically adjust delay bounds
> at each node.  The first approach impacts/shrinks the schedulable region
> since it imposes additional constraints on the scheduler.  The second
> approach can certainly be achieved through variants of HRR or RCSP but
> requires additional control information, so that local bounds can be
> properly adjusted.  In any case, this more a design option than a hard
> constraint.
> 

I suspect that for realtime applications where jitter is a 
major factor, rate control without early release, and 
guaranteed delay bounds will limit jitter.  But I agree, 
eliminating jitter altogether is very difficult if not 
impossible in a multihop network.

Steve

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Jul 95 1:32:23 JST

> But I agree, 

Just have time-stamped packets and a single large buffer at the last
hop router, and you can remove all the multi-hop jitter.

							Masataka Ohta