[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03
All,
Here is the updated text. Please let me know if this captures the suggested
changes. If so, I will post the new revision of the draft:
Time of Day Accuracy
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).
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.
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. 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