[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03



Al,

These have been corrected, thank you.

Regards,

Daryl


On 3/5/09 8:22 PM, "Al Morton" <acmorton at att.com> wrote:

> A few minor edits, below.
> Al
> 
> At 06:31 PM 3/5/2009, Daryl Malas wrote:
>> 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).
> spacing:
>      (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
> 
>      report.  The difference between a 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
> 


-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas at cablelabs.com