source of error for the measurement and is associated with the
clock's skew [RFC2330].
A stable and reasonably accurate clock is needed to make the time
interval measurements required by this memo. This source of error
SHOULD be constrained to less than +/- 1 ms, implying 1 part per 1000
frequency accuracy for a 1 second interval. This implies greater
stability is required as the length of the T4-T1 increases, in order
to constrain the error to be less than +/- 1ms.
Regards,
Daryl
On 3/4/09 8:52 AM, "Daryl Malas" <d.malas at cablelabs.com> wrote:
> Mario and Al,
>
> Thank you for coming to agreement on the text. I will update the draft and
> submit today.
>
> Regards,
>
> Daryl
>
>
> On 3/4/09 1:39 AM, "Marian Delkinov" <marian.delkinov at ericsson.com> wrote:
>
>> Thanks Al!
>>
>> IMO, the definitions you proposed are accurate and in accordance with
>> RFC 2330.
>>
>> Best regards!
>> Mario.
>>
>> -----Original Message-----
>> From: pmol-bounces at ietf.org [mailto:pmol-bounces at ietf.org] On Behalf Of
>> Al Morton
>> Sent: Tuesday, 03 March, 2009 22:13
>> To: Daryl Malas; pmol at ietf.org
>> Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03
>>
>> Mario's comment is in the archive (and my In-box) so it appears to have
>> been processed by the list.
>>
>> I think that the main question, when trying to reconcile Gerald's and
>> Mario's comments, is whether we are talking about clock offset, or time
>> offset and error in time offset.
>>
>> RFC 2330 defines clock offset in section 10.1:
>> To begin, we define a clock's "offset" at a particular moment as the
>> difference between the time reported by the clock and the "true"
>> time
>> as defined by UTC. If the clock reports a time Tc and the true time
>> is Tt, then the clock's offset is Tc - Tt.
>> and since 2330 is our primary reference here, that's the way we should
>> go, IMO.
>>
>> Chapter 3, page 5:
>> As defined above, T1 is associated with the start of a request and
>> also serves as the time-of-day stamp associated with a single
>> specific measurement. The clock offset [RFC2330] is the difference
>> ^^^^^
>> between T1 and a recognized primary source of time, such as UTC
>> (offset = T1- UTC).
>>
>> Same page, (approx. Mario's suggested text):
>> When measurement results will be correlated with other results or
>> information using time-of-day stamps, then the time clock that
>> supplies T1 SHOULD be synchronized to a primary time source, to
>> minimize the clock's offset. The clocks used at the different
>> measurement points SHOULD be synchronized to each other, to
>> minimize the relative offset (as defined in RFC2330). The
>> clock's offset and the relative offset MUST be reported with
>> each measurement.
>>
>> Later in the same section:
>>
>> Time Interval Accuracy
>>
>> The accuracy of the T4-T1 interval is also critical to maintain and
>> report. The difference between clock's offsets at T1 and T4 is one
>> source of error for the measurement and is associated with the
>> clock's skew [RFC2330].
>>
>> A stable and reasonably accurate clock is needed to make the time
>> interval measurements required by this memo. This source of error
>> SHOULD be constrained to less than +/- 1 ms, implying 1 part per
>> 1000
>> frequency accuracy for a 1 second interval.
>>
>> Hope this helps,
>> Al
>> (as a participant)
>>
>> At 01:52 PM 2/24/2009, Daryl Malas wrote:
>>> Forwarding comments on behalf of Mario, because I never saw them hit
>>> the mailing list...
>>>
>>>
>>> ----------------
>>> Daryl Malas
>>> CableLabs
>>> (o) +1 303 661 3302
>>> (f) +1 303 661 9199
>>> mailto:d.malas at cablelabs.com
>>>
>>>
>>>> -----Original Message-----
>>>> From: Marian Delkinov [mailto:marian.delkinov at ericsson.com]
>>>> Sent: Friday, February 20, 2009 3:43 AM
>>>> To: Daryl Malas
>>>> Cc: pmol at ietf.org
>>>> Subject: RE: IETF Draft: SIP Performance Metrics-03
>>>>
>>>>
>>>> Daryl,
>>>>
>>>> Sorry, for my perhaps delayed feedback! (I'm back after a long
>>>> absence).
>>>>
>>>> I checked the new version (03) of the draft. All the texts that I
>>>> had comments before are fine.
>>>>
>>>> However, I found some changes in other texts, based on other
>>>> people's comments, that I have to disagree with.
>>>>
>>>> ---
>>>> Chapter 3, page 5:
>>>> As defined above, T1 is associated with the start of a request and
>>>> also serves as the time-of-day stamp associated with a single
>>>> specific measurement. The time offset [RFC2330] is the
>> difference
>>>> between T1 and a recognized primary source of time, such as UTC
>>>> (offset = T1- UTC).
>>>>
>>>> Instead of using the term "time offset" above, I suggest "clock's
>>>> offset". Thus the text will comply with the terminology used in
>>>> RFC2330, chapter 10.1.
>>>>
>>>> ---
>>>> Same page, the text:
>>>> When measurement results will be correlated with other results or
>>>> information using time-of-day stamps, then the time clock that
>>>> supplies T1 SHOULD be synchronized to a primary time source, to
>>>> minimize the error in the time offset. The time offset MUST be
>>>> reported with each measurement.
>>>>
>>>> I fail to understand the sentence "to minimize the error in the time
>>
>>>> offset". There is no ERROR in the time offset, because the time
>>>> offset IS the error. Moreover RFC2330 doesn't define such error, the
>>
>>>> draft doesn't define it either, so better avoid using it. I suggest
>>>> keeping the text as in version-02, but using "clock's offset".
>>>>
>>>> In addition, when correlating measurements, it's much more important
>>
>>>> all clocks used at the measurement sources to be synchronized to
>>>> each other, rather than be synchronized to primary time source. Thus
>>
>>>> the relative offset should be minimized.
>>>>
>>>> So the text should be:
>>>>
>>>> When measurement results will be correlated with other results or
>>>> information using time-of-day stamps, then the time clock that
>>>> supplies T1 SHOULD be synchronized to a primary time source, to
>>>> minimize clock's offset. The clocks used at the different
>>>> measurement sources SHOULD be synchronized to each other, to
>>>> minimize the relative offset (as defined in RFC2330). The
>>>> clock's offset and the relative offset MUST be reported with
>>>> each measurement.
>>>>
>>>> ---
>>>> Respectively and for the same reasons, the following text:
>>>> The accuracy of the T4-T1 interval is also critical to maintain and
>>>> report. The difference in errors between the time offsets at T1
>>>> and
>>>> T4 is associated with the clock's skew [RFC2330].
>>>>
>>>> Should be kept as in version -02, but use the "clock's offset" term:
>>>>
>>>> The accuracy of the T4-T1 interval is also critical to maintain and
>>>> report. The difference between clock's offsets at T1 and T4 is
>> the
>>>> error for the measurement and is associated with the clock's skew
>>
>>>> [RFC2330].
>>>>
>>>>
>>>> I'm OK with all other changes in version -03 compared to version
>> -02.
>>>>
>>>> Best regards!
>>>> Mario.
>>>>
>>>>
>>> _______________________________________________
>>> PMOL mailing list
>>> PMOL at ietf.org
>>> https://www.ietf.org/mailman/listinfo/pmol
>>
>> _______________________________________________
>> PMOL mailing list
>> PMOL at ietf.org
>> https://www.ietf.org/mailman/listinfo/pmol
>
>
> -----------------
> Daryl Malas
> CableLabs
> (o) +1 303 661 3302
> (f) +1 303 661 9199
> mailto:d.malas at cablelabs.com
>
>
> _______________________________________________
> PMOL mailing list
> PMOL at ietf.org
> https://www.ietf.org/mailman/listinfo/pmol
-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas at cablelabs.com