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

["Marian Delkinov" <marian.delkinov at ericsson.com>]

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