Subject: [ippm] Comments/ questions on draft-ietf-ippm-ipdv-10.txt

From: "Alan Clark" <[email-masked]>
Date: Sat, 12 Oct 2002 08:59:51 -0400

Whilst I wholeheartedly agree with and support the methodology in the IPDV
draft (also the excellent description of drift, skew etc) I would like to
raise two issues.

1. Short term delay correlation
When considering the effect of PDV on adaptive jitter buffers it is
important to look at short term correlation - which tends to be lost when
the output metrics are averages or PDF/CDFs.  Although good models for
correlated packet loss exist there do not appear to be equivalent models
that reflect PDV correlation.

As examples,
(a) LAN congestion often appears as short spikes - it is entirely possible
that an adaptive jitter buffer may discard packets when the spike occurs and
then increase in size .. in this case possibly un-necessarily introducing
additonal delay.
(b) Access link congestion can appear as a ramp-like increase in delay, due
to the router's queue filling, introducing both an increase in PDV and an
increase in delay that could last from 100mS to seconds in duration.  The
delay increase may cause the jitter buffer to resynchronize, effectively
moving its "window" to correspond with the minimum delay - the number of
packets discarded would be more than a packet-to-packet delay metric and
less than a PDF would suggest.

Obviously if you are taking a sampling approach then it may be hard to see
these effects however they are extremely common, hence it would be very
useful to produce representative metrics.

The only reasonable approach that I've managed to come up with to address
this (very common) type of delay variation is a time series model -
basically a simple filter that is driven by impulses with a given time and
amplitude distribution.  This appears able to produce very plausible delay
profiles.

I would be interested to know how the current IPDV metrics would solve the
above problem, and if they don't, if there is a need to develop metrics
which would.

2. System issues
As you point out in the draft, there can be system issues that can affect
local timestamping - in our experience this is very variable from system to
system and can be quite a substantial problem. It may be helpful to indicate
some of the worst case scenarios in order to encourage implementors to look
at this issue carefully - and potentially some ideas on how the extent of
this can be measured or estimated.

Regards

Alan Clark
Telchemy

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: Philip Chimento <[email-masked]>
Date: Mon, 14 Oct 2002 15:00:18 -0400

> that reflect PDV correlation.

The I-D does not limit you to PDFs/CDFs or averages of IPDV. These are just 
examples of statistics that you can compute.

> then increase in size .. in this case possibly un-necessarily introducing

I am not sure what your point is here...if you are not measuring every packet 
between the endpoints of interest, you WILL miss some transient phenomena.

> less than a PDF would suggest.

Remember that PDV is really a "derivative" of delay. If you have a ramp-like 
increase in delay, your PDV will be (nearly) constant. PDV does NOT 
necessarily increase if delay increases.
 
> useful to produce representative metrics.

I am not sure what you mean by a "sampling approach", however, on page 9 of 
the draft, we do allow some flexibility in how an active measurement device 
could "sample". The point with Poisson sampling (as described in the One-Way 
Delay RFC) is that it generates a uniformly distributed sample for a fixed 
number of events in an interval. One COULD use, for example, a periodic 
stream, but then you leave yourself open to aliasing effects. You just have to 
be more careful with the analysis.

> above problem, and if they don't, if there is a need to develop metrics

In terms of "solving" the problem, the IPDV draft was intentionally made 
flexible with the "selection function" to select (sub)sequences of packets for 
the computation of statistics. It is easy enough to get a time-series out of a 
selection of consecutive packets. This is all (implicit) in the I-D.

> this can be measured or estimated.

This issue exists in most of the IPPM RFCs, especially in one-way delay. It is 
a real issue; but today's worst-case scenarios will be different than 
tomorrow's. Perhaps Stanislav Shulanov or Henk Uiterwaal have some ideas on
this ? 

A practical issue: The IPDV draft has gone to the IESG and has been approved 
(it hasn't been assigned an RFC number yet). The chairs can correct me if I am 
wrong, but I don't think that we can change the document easily at this point 
unless there is some show-stopper of a problem.

Regards, Phil Chimento

-- 
Phil Chimento             Ericsson IPI
Phone: 240-314-3597	  7301 Calhoun Place
[email-masked]   Rockville, Md. 20855
-----------------------------------------------------