Subject: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10

From: "Spiros Spirou" <[email-masked]>
Date: Thu, 3 Nov 2005 12:40:02 +0100

Hi folks,

Is it terribly wrong to use the RTP timestamp as the SrcTime parameter of
the Type-P-Reordered metric?

TIA,

Spiros

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Thu, 03 Nov 2005 12:08:22 -0500

>the Type-P-Reordered metric?

Thanks for your interest in reordering and for posting your question.

Clearly, we were thinking of "wire time" when defining SrcTime,
as below (from ippm-reordering-10) :

>3.2 Metric Parameters:
>
>    +  Src, the IP address of a host
>
>    +  Dst, the IP address of a host
>
>    +  SrcTime, the time of packet emission from the Source (or wire
>       time)

And from RFC 3550:

>    timestamp: 32 bits
>       The timestamp reflects the sampling instant of the first octet in
>       the RTP data packet.  The sampling instant MUST be derived from a
>       clock that increments monotonically and linearly in time to allow
>       synchronization and jitter calculations (see Section 6.4.1).  The
>       resolution of the clock MUST be sufficient for the desired
>       synchronization accuracy and for measuring packet arrival jitter
>       (one tick per video frame is typically not sufficient). ...

So, whether it is terribly wrong to use the RTP timestamp in place of
wire time depends on what happens between the instant of the
time stamp and the instant of actual packet emission.

If there is a constant delay between time stamping and emission,
then it's a source of error that's easy to characterize and remove.

If there is considerable "source jitter" (the time between timestamp and
emission is variable and significant w.r.t. delay variation in the
test path), then you would be headed toward "terribly wrong" if the error
due to source jitter was ignored.

So, it's best to characterize any source of error, and source jitter
is exactly that in this scenario.

hope this helps,
(the framework RFC 2330 probably treats this topic in general, too)
Al

---

From: "Spiros Spirou" <[email-masked]>
Date: Tue, 8 Nov 2005 11:12:12 +0100

Hi Al,

Thanks for the reply.

I may be trying to misuse the draft: What I have in mind is a self-contained
measuring device (receiver) that reports the Type-P-Reordered metric and
associated parameters (including SrcTime for completeness).

However, it seems that the requirement to report SrcTime as wire time
prohibits a self-contained Type-P-Reordered measurement, because it
necessitates a simultaneous measurement of the transmission wire time at the
source. Following from your correct observations, this complication may also
hold when earlier times (such as the RTP timestamp) are used in reporting
the SrcTime, because one still needs to detect, estimate, and remove the
"source jitter" component, and I don't see how these can be done at the
receiver without measurements at the server as well.

So, am I going up a dead-end? Is there a way to report the SrcTime as (the
elusive) wire time without access to the server?

Regards,

Spiros

----- Original Message ----- 
From: "Al Morton" <[email-masked]>
To: "Spiros Spirou" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 03, 2005 6:08 PM
Subject: Re: [ippm] RTP timestamp as SrcTime in
draft-ietf-ippm-reordering-10

---

From: Al Morton <[email-masked]>
Date: Thu, 17 Nov 2005 12:11:49 -0500

Sorry - mail tool problem, here's the complete reply:

Hi Spiros,

I don't think that you are misusing the draft,
you are simply applying the definitions under circumstances
that are somewhat different from the usual IPPM active
measurement set-up, with instruments present only at the
receivers.  Perhaps you can make measurements
more ubiquitously as a single-point measure, and the
information you derive may out-weigh the errors between
the true wire time and the RTP time stamp, as long as you
are clear about *what* was measured (both network and source
effects on transmission time).

 From RFC 2330, section 10.2:
    When appropriate, metrics should be defined in terms of wire times
    rather than host endpoint times, so that the metric's definition
    highlights the issue of separating delays due to the host from those
    due to the network.

You might attack the problem of characterizing source error by making
measurements as "close to the source" as possible.

It's usually better to light a candle than to curse the darkness.

Al

---

From: Al Morton <[email-masked]>
Date: Thu, 17 Nov 2005 12:02:59 -0500

Hi Spiros,

I don't think that you are miss-using the draft,
measurement set-up, with instruments only present at the

---

From: "Spiros Spirou" <[email-masked]>
Date: Fri, 18 Nov 2005 14:31:09 +0100

Hi Al,

Thanks for making the time to reply. Please see my comments below.

> effects on transmission time).

However, I suspect that then I will not be able to claim adherence to the
soon-to-be-RFC draft, because without the "out-of-band" clarification that
you suggest, SrcTime would be falsely interpreted as wire time by a third
party. I am not sure whether the problem lies at the inherited requirement
to use the "ideal" wire time to report SrcTime, the lack of a defined
mechanism to further clarify the reporting of SrcTime for more practical
cases, or just my intention to use the draft in "circumstances that are
somewhat different from the usual IPPM active measurement set-up" as you
have correctly observed.

> measurements as "close to the source" as possible.

This might not be always easy when one tries to measure deployed systems.
Furthermore, it might also be impossible when reordering measurements are
done internally to a receiver with the intent of dynamicaly modifiying its
real-time behaviour to achive better Quality of Experience.

Spiros