[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03
Al,
Regarding the second edit, is it really necessary?
...
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].
"offsets" is plural, so why should "a" be inserted there?
Or perhaps you had another idea?
Best regards!
Mario.
-----Original Message-----
From: Al Morton [mailto:acmorton at att.com]
Sent: Friday, 06 March, 2009 04:23
To: Daryl Malas; Marian Delkinov; pmol at ietf.org
Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03
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