[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ns] delay jitter
Iyad,
Thanks for the detailed answer. It furthered some of my understanding
about delay jitter. The answer was very well stated, and the answer
mentioned about scheduling algorithms taking care of delay jitter.
Well I am working on scheduling algorithms for single-hop WDM optical
networks, that provide QoS guarantees to different classes of service. And
want to do the delay and delay jitter analysis for my scheduling
algorithms. I will try to explain the problem in detail:
Packets belonging to EF/AF/BE destined towards each of the channel are
queued at a node (ie if there are C channels and N nodes, each node will
have 'C' queues). I am experimenting with nortel's diffserv impl (ie using
mulitple RED queues) but anyway any other queuing mechanism could be used.
My scheduling algorithm reserves a number of slots for each node on
each channel according to their demand. It then schedules packets in
cycles. This reservation includes slots for EF (high priority) Af and BE
(lowest priority) packets but exact slots are not reserved (ie a given
slot would serve EF traffic if EF demand for the cycle is not met and EF
packet available, else serve AF (if demand not met available) else serve
BE packets). How much reservation you allow and over what time period
determines your schedule lengths. The picture below may help u get an
idea:
|__________E___E___________|__________E_____E_________|__..
|<->|<-------------------->|<--->|
D1 D2 D3
As you can see the delay experienced by each packet is variable (I am not
considering propagation delays since our system model for the single-hop
network assumes that prop. delays to each node from any node are
constant). We call the D1, D2, D3 above queuing delays even if they
really are scheduling delays. And since they are variable I need to
provide bounds for delay and delay jitter.
How I plan to proceed with the problem is: first run simulations that can
given me an idea of what the bounds could be (these may not be worst case
bounds since the worst case may not occur during my simulation runs). If
these break some ice then go ahead with theoretical analysis and check if
the results match.
Hence it becomes important that my simulation uses correct formulas to
calculate delay and delay jitter. How do I calculate:
delay = packet transmission time - packet arrival time
delay jitter = (largest delay so far) - (smallest delay so far)
It makes sense to measure mean delay and delay variance. But does it make
sense to also keep track of mean delay jitter and delay jitter variance
(these would capture how delay jitter has been varying over time). Does it
make sense for delay jitter to be a number ie
largest delay for the simulation run - smallest delay for the simulation
run
Thanks a lot for your comments.
Regards,
Sudhin.
On Thu, 17 May 2001, Iyad Al Khatib wrote:
> At Thursday 04:35 AM 5/17/01 -0400, Sudhindra Suresh Bengeri wrote:
> >Hi,
> >
> >Could someone of u pls. tell me if the following definition of Delay
> >Jitter is correct:
> >
> >Delay Jitter = max. delay - min. delay
> >also does mean delay jitter (and variance of delay jitter) make any sense?
> >That does it make sense to keep track of delay jitter over time and then
> >calculate its mean..
>
> You have to be accurate when you say min and max, I mean what we mean or
> resemble by min and max.
> I will give you a detailed answer, where I start from scratch and end up
> with what you like to learn about, if I didn't misunderstand your question.
> Here we go:
> First, this is very related to statistics and probability, I can describe
> the delay bound as a deterministic bound (bound referring to min or max).
>
> Second, I would understand max delay as "worst case" delay.
> but remember, this max delay or worst case delay also includes the
> propagation delay in its calculation.
>
> Don't forget: Total Delay = Propagation delay + Delay_jitter.
>
> So, The worst case delay is the biggest *total* delay metric you can get
> over a connection.
> One might still wonder, so what is it statistically?
> The answer is that to get the worst case delay over a connection we
> calculate the longest time or worst case behavior of every routing point on
> the pathway. To be clearer, we need to define the word scheduler (to be
> more scientific), a scheduler is the module that decides the queuing and
> forwarding of data over a connecting node on the pathway from source to
> destination. therefore, now we can say that to calculate the worst case
> delay we just work out the calculations with the assumption that each and
> every scheduler is functioning with its worst case behavior. Now this gives
> rise to a questions on what a worst case behavior is for a scheduler. The
> answer is that we just have to identify that over our connection with the
> help of knowledge about the schedulers. A good point to mention is that
> many schedulers nowadays use WFQ or Weighted Fair Queuing techniques ,
> mostly Round Rubin ones. We can discuss this aside if you like, but it is
> just a tip for those who want to learn more.
> Another important parameter is the average delay over the same connection,
> which shall be calculated over each and every traffic arrival pattern of
> every other connection in the system. Note here that each packet delay here
> means a lot. Thus, the real average delay which is an "ideal" metric- if we
> can say so- can not be calculated or is impossible to measure.
> *** Here I would like to mention that this is a problem in traffic analysis
> and QoS analysis, that many experiments under study you can not have
> perfect control over.
> So, how to solve this problem?
> The answer is that we can measure the mean or average delay over packets
> sent on a connection, and that is what all people working in traffic
> analysis call as average delay i.e. it is the *measured* mean delay.
> As for delay-jitter, it is simply the difference between the worst delay
> and the smallest delay. So jitter is a variable that changes between two
> bounds, think of it like:
> a1 < jitter < a2
> where a1 and a2 are the smallest and worst delay bounds respectively.
>
> So, where is jitter useful?
> Ans. It is mainly useful for playback applications.
> For an audio or video stream of such a playback application (like voice
> calls, video-conference, etc..), a playback receiver will use playback
> instants in a way so that it can play a packet while one is received. Ah,
> well, but this is not simple! However, if delay jitter is bounded (as we
> just saw before), then the playback receiver can simply just delay the
> playing of the first packet on a connection determined by the higher jitter
> bound (a2) using a buffer- or what is known by traffic analyzers as the
> elastic buffer.
> So, what does this tell us about applications and demands?
> Ans. It simply says that if we want good QoS for our application, we should
> know that the more the jitter upper-bound is the more is our need of the
> elastic buffer size.
> However it is very complicated when the two parameters of buffer size and
> packet scheduling come to be studied at the same time It is good to know
> that queuing algorithms should keep track of the delay jitter upper bound
> for all packets being forwarded and not only the first few.
>
> Iyad
>
> >TIA.
> >
> >Regards,
> >Sudhin.
> >
> >****************** Sudhindra Suresh Bengeri ********************
> >Graduate Research Assistant | Home: |
> >to Dr. George N. Rouskas | 2110, Gorman St., |
> >EGRC 454H, Computer Sci. dept.| Raleigh, NC - 27606 |
> >NCSU, Raleigh, NC 27695 | Ph. (919) 852-1961 |
> >(919)515-3655(P) / 515-7925(F)
> >My web projection: http://www4.ncsu.edu/~ssbenger
> >
> >* Always glad to share my ignorance - I've got plenty. *
>
>
****************** Sudhindra Suresh Bengeri ********************
Graduate Research Assistant | Home: |
to Dr. George N. Rouskas | 2110, Gorman St., |
EGRC 454H, Computer Sci. dept.| Raleigh, NC - 27606 |
NCSU, Raleigh, NC 27695 | Ph. (919) 852-1961 |
(919)515-3655(P) / 515-7925(F)
My web projection: http://www4.ncsu.edu/~ssbenger
* Always glad to share my ignorance - I've got plenty. *