[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03
Hi Al,
OK, I see your point. Please, disregard my remark.
Best regards!
Mario.
-----Original Message-----
From: Al Morton [mailto:acmorton at att.com]
Sent: Tuesday, 10 March, 2009 10:24
To: Marian Delkinov; Daryl Malas
Cc: pmol at ietf.org
Subject: RE: [PMOL] FW: IETF Draft: SIP Performance Metrics-03
Hi Mario,
The sentence is phrased as though there is one clock and two offsets (at
T1 and T4), and "between clock's" just reads rough to me.
Al
At 04:51 AM 3/10/2009, Marian Delkinov wrote:
>
>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