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

Hi Al,

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

> 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).

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.

>
>  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.

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.

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

Spiros

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