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

From: Al Morton <[email-masked]>
Date: Tue, 03 Mar 2009 16:13:24 -0500

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:[email-masked]
>
>
> > -----Original Message-----
> > From: Marian Delkinov [mailto:[email-masked]]
> > Sent: Friday, February 20, 2009 3:43 AM
> > To: Daryl Malas
> > Cc: [email-masked]
> > 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pmol

---

From: "Marian Delkinov" <[email-masked]>
Date: Wed, 4 Mar 2009 09:39:58 +0100

Thanks Al! 

IMO, the definitions you proposed are accurate and in accordance with
RFC 2330. 

Best regards!
Mario.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Al Morton
Sent: Tuesday, 03 March, 2009 22:13
To: Daryl Malas; [email-masked]
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:

Time Interval Accuracy

     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
> > 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.
> >
> > 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:
> > 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:
> >
> >    report.  The difference in errors between the time offsets at T1 
> > and
> >    error for the measurement and is associated with the clock's skew

> > [RFC2330].

---

From: Daryl Malas <[email-masked]>
Date: Wed, 04 Mar 2009 08:52:13 -0700

Mario and Al,

Thank you for coming to agreement on the text.  I will update the draft and
submit today.

Regards,

Daryl

>>> I'm OK with all other changes in version -03 compared to version

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

---

From: Daryl Malas <[email-masked]>
Date: Thu, 05 Mar 2009 16:31:08 -0700

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

   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

   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

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

---

From: Al Morton <[email-masked]>
Date: Thu, 05 Mar 2009 22:22:57 -0500

A few minor edits, below.
Al

>    between T1 and a recognized primary source of time, such as UTC
spacing:
     (offset = T1 - UTC).

>    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
                                    ^

---

From: "Marian Delkinov" <[email-masked]>
Date: Tue, 10 Mar 2009 09:51:33 +0100

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

"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:[email-masked]] 
Sent: Friday, 06 March, 2009 04:23
To: Daryl Malas; Marian Delkinov; [email-masked]
Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03

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
>
spacing:
     (offset = T1 - UTC).

>    measurement points SHOULD be synchronized to each other, to
minimize
>    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
                                    ^
1000
> > Thank you for coming to agreement on the text.  I will update the 
> > draft and submit today.
> >
> > Regards,
> >
> > Daryl
> >
> >
> >> IMO, the definitions you proposed are accurate and in accordance 
> >> with RFC 2330.
> >>
> >> Best regards!
> >> Mario.
> >>
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Al Morton
> >> 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.
> >>
> >> and since 2330 is our primary reference here, that's the way we 
> >> should go, IMO.
> >>
> >> Chapter 3, page 5:
> >>> 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

> >>>> 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".
> >>>> important
> >>>>    report.  The difference in errors between the time offsets at 
> >>>> T1 and

---

From: Al Morton <[email-masked]>
Date: Tue, 10 Mar 2009 05:24:07 -0400

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

---

From: "Marian Delkinov" <[email-masked]>
Date: Tue, 10 Mar 2009 11:22:52 +0100

Hi Al,

OK, I see your point. Please, disregard my remark.

Best regards!
Mario.

-----Original Message-----
From: Al Morton [mailto:[email-masked]] 
Sent: Tuesday, 10 March, 2009 10:24
To: Marian Delkinov; Daryl Malas
Cc: [email-masked]
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

> > > On 3/4/09 1:39 AM, "Marian Delkinov" 
> > > <[email-masked]>
>wrote:
> > >
> > >> Thanks Al!
> > >>
> > >> Mario's comment is in the archive (and my In-box) so it appears 
> > >> to have been processed by the list.
> > >>

> > >>     as defined by UTC.  If the clock reports a time Tc and the 
> > >> true
>time
> > >>      As defined above, T1 is associated with the start of a 
> > >> request
>and
> > >>      When measurement results will be correlated with other 
> > >> results
>or
> > >>      report. The difference between clock's offsets at T1 and T4 
> > >> is
>one
> > >>      SHOULD be constrained to less than +/- 1 ms, implying 1 part

> > >> per 1000

> > >>>> I checked the new version (03) of the draft. All the texts that

> > >>>> I
> > >>>> "clock's

> > >>>> I fail to understand the sentence "to minimize the error in the

> > >>>> all clocks used at the measurement sources to be synchronized 
> > >>>> to each other, rather than be synchronized to primary time
source.
> > >>>> Thus
> > >>>> at
> > >>>>    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.
> > >>>>
> > >>>>