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

Hi Spiros,

I don't think that you are miss-using the draft,
you are simply applying the definitions under circumstances
that are somewhat different from the usual IPPM active
measurement set-up, with instruments only present 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.

At 05:12 AM 11/8/2005, Spiros Spirou wrote:
>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

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm