Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15893A6A89 for ; Tue, 24 Mar 2009 17:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95P3bZrj5Fe2 for ; Tue, 24 Mar 2009 17:56:42 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 746E53A6A88 for ; Tue, 24 Mar 2009 17:56:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2P0vWI22998 for ; Wed, 25 Mar 2009 01:57:32 +0100 (CET) Received: from [10.21.117.163] (sjc-vpn2-1443.cisco.com [10.21.117.163]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2P0vTt02774 for ; Wed, 25 Mar 2009 01:57:29 +0100 (CET) Message-ID: <49C98179.9080600@cisco.com> Date: Tue, 24 Mar 2009 17:57:29 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pmol@ietf.org Content-Type: multipart/alternative; boundary="------------020308010709020102090004" Subject: [PMOL] Editorial comments on the framework draft X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:56:43 -0000 This is a multi-part message in MIME format. --------------020308010709020102090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Not sure if those two were mentioned already... 1. You might want to mention what compagg is. It's in the reference but ... 3.3.2 Index (from compagg) An Index is a metric for which the output value range has been selected for convenience or clarity, and the behavior of which is selected to support ease of understanding (e.g. G.107 R Factor). The deterministic function for an index is often developed after the index range and behavior have been determined. 2. I see two instances of "[Ref ?]" Regards, Benoit. --------------020308010709020102090004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Not sure if those two were mentioned already...

1. You might want to mention what compagg is. It's in the reference but ...
3.3.2 Index (from compagg)
   An Index is a metric for which the output value range has been
   selected for convenience or clarity, and the behavior of which is
   selected to support ease of understanding (e.g. G.107 R Factor).
   The deterministic function for an index is often developed after
   the index range and behavior have been determined.
2. I see two instances of "[Ref ?]"

Regards, Benoit.



--------------020308010709020102090004-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D553A6A53 for ; Tue, 24 Mar 2009 11:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9sptVs+VNII for ; Tue, 24 Mar 2009 11:09:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A317D3A6905 for ; Tue, 24 Mar 2009 11:09:52 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A077120272; Tue, 24 Mar 2009 19:10:42 +0100 (CET) X-AuditID: c1b4fb3e-aafb3bb000006d6d-16-49c92222ab4a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6D63E201D5; Tue, 24 Mar 2009 19:10:42 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 19:10:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ACAB.D7A85AA8" Date: Tue, 24 Mar 2009 19:10:40 +0100 Message-ID: <40D78CDB69283744A4B07581DDFDEB550237DADF@esealmw106.eemea.ericsson.se> In-Reply-To: <200903231322.n2NDM3JK018184@klph001.kcdc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] Fwd: [74attendees] Audio Streams for IETF 74 San Francisco Thread-Index: Acmrumlpm1CAdvM5S6Kzw/RDZxTojQA8HsxA References: <200903231322.n2NDM3JK018184@klph001.kcdc.att.com> From: "Marian Delkinov" To: "Al Morton" , "Daryl Malas" X-OriginalArrivalTime: 24 Mar 2009 18:10:42.0010 (UTC) FILETIME=[D80103A0:01C9ACAB] X-Brightmail-Tracker: AAAAAA== Cc: pmol@ietf.org Subject: Re: [PMOL] Fwd: [74attendees] Audio Streams for IETF 74 San Francisco X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:09:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ACAB.D7A85AA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I'm currently in Bulgaria (GMT+2) attempting to participate remotely, however my Jabber client can't login. Obviously some problems with the hotel's proxies settings, or similar. If I'm unable to join until the meeting starts, please consider my full support to both documents the Performance Metrics and the Framework.=20 Have a nice and successful meeting! Sorry for not being able to join. I'll read the logs tomorrow. =20 Best regards! Mario. ________________________________ From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of Al Morton Sent: Monday, 23 March, 2009 14:22 To: pmol@ietf.org Subject: [PMOL] Fwd: [74attendees] Audio Streams for IETF 74 San Francisco Here's the answer for remote participation, (as posted to the attendees list, where it will only serve as info for those who are here!) The tools team agenda simplifies some of the searching: http://tools.ietf.org/agenda/74/ All times are US PDT, which I believe is GMT-7. You need a Jabber client, etc. http://jabber.ietf.org/ Al X-VirusChecked: Checked X-Env-Sender: 74attendees-bounces@ietf.org X-Msg-Ref: server-2.tower-146.messagelabs.com!1237671316!11230027!1 X-StarScan-Version: 6.0.0; banners=3D-,-,- X-Originating-IP: [64.170.98.32] X-SpamReason: No, hits=3D0.0 required=3D7.0 tests=3Dsa_preprocessor:=20 VHJ1c3RlZCBJUDogNjQuMTcwLjk4LjMyID0+IDk3MzUz\n X-Original-To: 74attendees@core3.amsl.com Delivered-To: 74attendees@core3.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level:=20 X-Spam-Status: No, score=3D0.002 tagged_above=3D-999 required=3D5 tests=3D[BAYES_50=3D0.001, HTML_MESSAGE=3D0.001] From: Morgan Sackett To: 74attendees@ietf.org Date: Sat, 21 Mar 2009 14:34:59 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [74attendees] Audio Streams for IETF 74 San Francisco X-BeenThere: 74attendees@ietf.org X-Mailman-Version: 2.1.9 List-Id: "This is a discussion list for attendees of IETF 74. " <74attendees.ietf.org> List-Unsubscribe: < https://www.ietf.org/mailman/listinfo/74attendees >, < mailto:74attendees-request@ietf.org?subject=3Dunsubscribe > List-Archive: < http://www.ietf.org/mail-archive/web/74attendees > List-Post: < mailto:74attendees@ietf.org > List-Help: < mailto:74attendees-request@ietf.org?subject=3Dhelp > List-Subscribe: < https://www.ietf.org/mailman/listinfo/74attendees >, < mailto:74attendees-request@ietf.org?subject=3Dsubscribe > Sender: 74attendees-bounces@ietf.org =09 There will be MP3 audio streams of the meetings happening in the breakout rooms. Specifically these are =09 Continental 1&2 Continental 3 Continental 4 Continental 5 Continental 6 Imperial A Imperial B Franciscan A =09 Please refer to the online agenda at http://tools.ietf.org/agenda/74/ to find a link to the stream for each session. =09 If there are concerns about the audio streams, there are a few ways to get our attention. Via email either audio@meeting.ietf.org, or noc@meeting.ietf.org. Via XMPP at noc@jabber.ietf.org. =09 =09 Morgan Sackett VP of Engineering =09 VeriLAN Event Services, Inc. 215 SE Morrison Street Portland, OR 97214 =09 Tel: 503 907-1415 Fax: 503 224-8833 =09 msackett@verilan.com www.verilan.com =20 =09 =09 This e-mail contains proprietary information and may be confidential. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you received this message in error, please delete it immediately. =09 =09 =09 _______________________________________________ 74attendees mailing list 74attendees@ietf.org https://www.ietf.org/mailman/listinfo/74attendees ------_=_NextPart_001_01C9ACAB.D7A85AA8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'm currently in Bulgaria (GMT+2) attempting = to=20 participate remotely, however my Jabber client can't login. Obviously = some=20 problems with the hotel's proxies settings, or similar. If I'm unable=20 to join until the meeting starts, please consider my full support=20 to both documents the Performance Metrics and the Framework.=20
Have a nice and successful meeting! Sorry for = not being=20 able to join. I'll read the logs tomorrow.
 
Best regards!
Mario.

From: pmol-bounces@ietf.org=20 [mailto:pmol-bounces@ietf.org] On Behalf Of Al = Morton
Sent:=20 Monday, 23 March, 2009 14:22
To: = pmol@ietf.org
Subject:=20 [PMOL] Fwd: [74attendees] Audio Streams for IETF 74 San=20 Francisco

Here's the answer for remote participation,
(as posted to = the=20 attendees list, where it will
only serve as info for those who are=20 here!)

The tools team agenda simplifies some of the = searching:
http://tools.ietf.org/agenda/74/

All times = are US=20 PDT, which I believe is GMT-7.

You need a Jabber client, = etc.
http://jabber.ietf.org/

Al

X-VirusChecked:=20 Checked
X-Env-Sender: 74attendees-bounces@ietf.org
X-Msg-Ref:=20 = server-2.tower-146.messagelabs.com!1237671316!11230027!1
X-StarScan-Ve= rsion:=20 6.0.0; banners=3D-,-,-
X-Originating-IP: = [64.170.98.32]
X-SpamReason: No,=20 hits=3D0.0 required=3D7.0 tests=3Dsa_preprocessor:
 =20 VHJ1c3RlZCBJUDogNjQuMTcwLjk4LjMyID0+IDk3MzUz\n
X-Original-To:=20 74attendees@core3.amsl.com
Delivered-To:=20 74attendees@core3.amsl.com
X-Virus-Scanned: amavisd-new at=20 amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:=20
X-Spam-Status: No, score=3D0.002 tagged_above=3D-999=20 = required=3D5
        =20 tests=3D[BAYES_50=3D0.001, HTML_MESSAGE=3D0.001]
From: Morgan = Sackett=20 <msackett@verilan.com>
To: 74attendees@ietf.org
Date: Sat, = 21 Mar=20 2009 14:34:59 -0700
X-Mailer: Apple Mail (2.930.3)
Subject:=20 [74attendees] Audio Streams for IETF 74 San Francisco
X-BeenThere:=20 74attendees@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "This is = a=20 discussion list for attendees of IETF 74.=20 "
        =20 <74attendees.ietf.org>
List-Unsubscribe: <=20 = https://www.ietf.org/mailman/listinfo/74attendees>,
&nbs= p;       =20 <=20 = mailto:74attendees-request@ietf.org?subject=3Dunsubscribe>
List= -Archive:=20 <=20 http://www.ietf.org/mail-archive/web/74attendees>
List-Post: = <=20 mailto:74attendees@ietf.org>
List-Help: <=20 = mailto:74attendees-request@ietf.org?subject=3Dhelp>
List-Subscr= ibe:=20 <=20 = https://www.ietf.org/mailman/listinfo/74attendees>,
&nbs= p;       =20 <=20 = mailto:74attendees-request@ietf.org?subject=3Dsubscribe>
Sender= :=20 74attendees-bounces@ietf.org

There will be MP3 audio streams of = the=20 meetings happening in the breakout rooms.  Specifically these=20 are

Continental 1&2
Continental 3
Continental=20 4
Continental 5
Continental 6
Imperial A
Imperial = B
Franciscan=20 A

Please refer to the online agenda at http://tools.ietf.org/agenda/74= /=20 to find a link to the stream for each session.

If there are = concerns=20 about the audio streams, there are a few ways to get our = attention.  Via=20 email either audio@meeting.ietf.org, or = noc@meeting.ietf.org.  = Via XMPP at=20 noc@jabber.ietf.org.


<= FONT=20 color=3D#e91700>Morgan Sackett
VP of=20 Engineering

VeriLAN Event Services, Inc.
215 SE = Morrison=20 Street
Portland, OR 97214

Tel: 503 907-1415
Fax: = 503=20 224-8833

msackett@verilan.com
<= A=20 href=3D"http://www.verilan.com/"=20 eudora=3D"autourl">www.verilan.com


This e-mail contains proprietary = information and=20 may be confidential. If you are not the intended recipient of this = e-mail, you=20 are hereby notified that any dissemination, distribution or copying of = this=20 message is strictly prohibited. If you received this message in error, = please=20 delete it=20 = immediately.



_________________________________________= ______
74attendees=20 mailing list
74attendees@ietf.org
https://www.ietf.org/mailman/listinfo/74attendees<= /BLOCKQUOTE> ------_=_NextPart_001_01C9ACAB.D7A85AA8-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2021828C318 for ; Tue, 24 Mar 2009 11:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.983 X-Spam-Level: X-Spam-Status: No, score=-104.983 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VcK6sSwEp8f for ; Tue, 24 Mar 2009 11:08:53 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 3608528C2B8 for ; Tue, 24 Mar 2009 11:08:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-167.messagelabs.com!1237918182!10442454!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.44] Received: (qmail 15474 invoked from network); 24 Mar 2009 18:09:43 -0000 Received: from sbcsmtp0.sbc.com (HELO mlth002.enaf.sfdc.sbc.com) (144.160.20.44) by server-4.tower-167.messagelabs.com with AES256-SHA encrypted SMTP; 24 Mar 2009 18:09:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlth002.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2OI9gVk012258 for ; Tue, 24 Mar 2009 14:09:42 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by mlth002.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2OI9d8r012222 for ; Tue, 24 Mar 2009 14:09:39 -0400 Message-Id: <200903241809.n2OI9d8r012222@mlth002.enaf.sfdc.sbc.com> Received: from acmt.att.com (vpn-135-70-154-45.vpn.mwst.att.com[135.70.154.45](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090324180938gw1000u6jqe>; Tue, 24 Mar 2009 18:09:38 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Mar 2009 14:09:37 -0400 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [PMOL] Fwd: Comment on framework 01 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:08:54 -0000 Resending this for reference today. Al >Date: Fri, 21 Nov 2008 12:59:06 -0500 >To: pmol@ietf.org >From: Al Morton >Subject: Comment on framework 01 > >Alan, > >As we discussed yesterday, please consider this comment as part of the >WG Last Call (message to follow): > >Section 3.4.3 >... > (iv) Reporting Model > > The Reporting Model definition is intended to make any relationship > between the metric and the reporting model clear. There are often > implied relationships between the method of reporting metrics and the > metric itself, however these are often not made apparent to the > implementor. For example, if the metric is a short term running > average packet delay variation (e.g. PPDV as defined in RFC3550) > however this value is reported at intervals of 6-10 seconds > this results in a sampling model which may have limited accuracy if > packet delay variation is non-stationary. > >I suggest we use the metric name from RFC 3550 to help people find >the reference there, as follows: > > ... For example, if the metric is a short term running > average source-to-receiver packet spacing difference > (e.g. D(i,j) as defined in RFC3550), then > the value is typically reported at intervals of 6-10 seconds. > This reporting frequency results in a sampling model which > may have limited accuracy if the inter-packet delay variation > is non-stationary. > >Al Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468A228C0F6 for ; Mon, 23 Mar 2009 06:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.733 X-Spam-Level: X-Spam-Status: No, score=-104.733 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkd36SamjLV9 for ; Mon, 23 Mar 2009 06:21:30 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id DAC9728C0EF for ; Mon, 23 Mar 2009 06:21:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-12.tower-146.messagelabs.com!1237814537!3496375!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 19099 invoked from network); 23 Mar 2009 13:22:18 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-12.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 23 Mar 2009 13:22:18 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2NDMGtc028308 for ; Mon, 23 Mar 2009 06:22:16 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2NDMA2b028242 for ; Mon, 23 Mar 2009 06:22:10 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n2NDMA0e018290 for ; Mon, 23 Mar 2009 08:22:10 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n2NDM3JK018184 for ; Mon, 23 Mar 2009 08:22:03 -0500 Message-Id: <200903231322.n2NDM3JK018184@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-34-82.vpn.west.att.com[135.70.34.82](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090323132202gw1000u65se>; Mon, 23 Mar 2009 13:22:02 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 09:22:00 -0400 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [PMOL] Fwd: [74attendees] Audio Streams for IETF 74 San Francisco X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:21:31 -0000 Here's the answer for remote participation,
(as posted to the attendees list, where it will
only serve as info for those who are here!)

The tools team agenda simplifies some of the searching:
http://tools.ietf.org/agenda/74/

All times are US PDT, which I believe is GMT-7.

You need a Jabber client, etc.
http://jabber.ietf.org/

Al

X-VirusChecked: Checked
X-Env-Sender: 74attendees-bounces@ietf.org
X-Msg-Ref: server-2.tower-146.messagelabs.com!1237671316!11230027!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [64.170.98.32]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor:
  VHJ1c3RlZCBJUDogNjQuMTcwLjk4LjMyID0+IDk3MzUz\n
X-Original-To: 74attendees@core3.amsl.com
Delivered-To: 74attendees@core3.amsl.com
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5
         tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
From: Morgan Sackett <msackett@verilan.com>
To: 74attendees@ietf.org
Date: Sat, 21 Mar 2009 14:34:59 -0700
X-Mailer: Apple Mail (2.930.3)
Subject: [74attendees] Audio Streams for IETF 74 San Francisco
X-BeenThere: 74attendees@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "This is a discussion list for attendees of IETF 74. "
         <74attendees.ietf.org>
List-Unsubscribe: < https://www.ietf.org/mailman/listinfo/74attendees>,
         < mailto:74attendees-request@ietf.org?subject=unsubscribe>
List-Archive: < http://www.ietf.org/mail-archive/web/74attendees>
List-Post: < mailto:74attendees@ietf.org>
List-Help: < mailto:74attendees-request@ietf.org?subject=help>
List-Subscribe: < https://www.ietf.org/mailman/listinfo/74attendees>,
         < mailto:74attendees-request@ietf.org?subject=subscribe>
Sender: 74attendees-bounces@ietf.org

There will be MP3 audio streams of the meetings happening in the breakout rooms.  Specifically these are

Continental 1&2
Continental 3
Continental 4
Continental 5
Continental 6
Imperial A
Imperial B
Franciscan A

Please refer to the online agenda at http://tools.ietf.org/agenda/74/ to find a link to the stream for each session.

If there are concerns about the audio streams, there are a few ways to get our attention.  Via email either audio@meeting.ietf.org, or noc@meeting.ietf.org.  Via XMPP at noc@jabber.ietf.org.


Morgan Sackett
VP of Engineering

VeriLAN Event Services, Inc.
215 SE Morrison Street
Portland, OR 97214

Tel: 503 907-1415
Fax: 503 224-8833

msackett@verilan.com
 www.verilan.com


This e-mail contains proprietary information and may be confidential. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you received this message in error, please delete it immediately.



_______________________________________________
74attendees mailing list
74attendees@ietf.org
https://www.ietf.org/mailman/listinfo/74attendees
Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D282C28C0E2 for ; Tue, 10 Mar 2009 03:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92e46l9QmLtt for ; Tue, 10 Mar 2009 03:31:10 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 05CE43A6CF7 for ; Tue, 10 Mar 2009 03:31:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C375D22B37; Tue, 10 Mar 2009 11:31:43 +0100 (CET) X-AuditID: c1b4fb3e-ad09cbb0000023da-87-49b63f7e26be Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1AB2C22A77; Tue, 10 Mar 2009 11:22:54 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 11:22:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2009 11:22:52 +0100 Message-ID: <40D78CDB69283744A4B07581DDFDEB550219286B@esealmw106.eemea.ericsson.se> In-Reply-To: <200903100924.n2A9OBrB030929@klph001.kcdc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 thread-index: AcmhYgDqhT0H7Z1ESRSYjJLAUn0hSgABxJPw References: <200903060322.n263MxV5021155@klph001.kcdc.att.com> <40D78CDB69283744A4B07581DDFDEB550219264D@esealmw106.eemea.ericsson.se> <200903100924.n2A9OBrB030929@klph001.kcdc.att.com> From: "Marian Delkinov" To: "Al Morton" , "Daryl Malas" X-OriginalArrivalTime: 10 Mar 2009 10:22:53.0751 (UTC) FILETIME=[2C3C1470:01C9A16A] X-Brightmail-Tracker: AAAAAA== Cc: pmol@ietf.org Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 10:31:11 -0000 Hi Al, OK, I see your point. Please, disregard my remark. Best regards! Mario. =20 -----Original Message----- From: Al Morton [mailto:acmorton@att.com]=20 Sent: Tuesday, 10 March, 2009 10:24 To: Marian Delkinov; Daryl Malas Cc: pmol@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@att.com] >Sent: Friday, 06 March, 2009 04:23 >To: Daryl Malas; Marian Delkinov; pmol@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=20 > >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 =3D T1- UTC). >spacing: > (offset =3D 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=20 > > 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" wrote: > > > > > Mario and Al, > > > > > > Thank you for coming to agreement on the text. I will update the=20 > > > draft and submit today. > > > > > > Regards, > > > > > > Daryl > > > > > > > > > On 3/4/09 1:39 AM, "Marian Delkinov"=20 > > > >wrote: > > > > > >> Thanks Al! > > >> > > >> IMO, the definitions you proposed are accurate and in accordance=20 > > >> with RFC 2330. > > >> > > >> Best regards! > > >> Mario. > > >> > > >> -----Original Message----- > > >> From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On=20 > > >> Behalf Of Al Morton > > >> Sent: Tuesday, 03 March, 2009 22:13 > > >> To: Daryl Malas; pmol@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=20 > > >> 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=20 > > >> 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=20 > > >> 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=20 > > >> should go, IMO. > > >> > > >> Chapter 3, page 5: > > >> As defined above, T1 is associated with the start of a=20 > > >> 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 =3D T1- UTC). > > >> > > >> Same page, (approx. Mario's suggested text): > > >> When measurement results will be correlated with other=20 > > >> 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=20 > > >> 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@cablelabs.com > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] > > >>>> Sent: Friday, February 20, 2009 3:43 AM > > >>>> To: Daryl Malas > > >>>> Cc: pmol@ietf.org > > >>>> Subject: RE: IETF Draft: SIP Performance Metrics-03 > > >>>> > > >>>> > > >>>> Daryl, > > >>>> > > >>>> Sorry, for my perhaps delayed feedback! (I'm back after a long=20 > > >>>> 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=20 > > >>>> 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 =3D T1- UTC). > > >>>> > > >>>> Instead of using the term "time offset" above, I suggest=20 > > >>>> "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=20 > > >>>> error, the > > >> > > >>>> draft doesn't define it either, so better avoid using it. I=20 > > >>>> suggest keeping the text as in version-02, but using "clock's >offset". > > >>>> > > >>>> In addition, when correlating measurements, it's much more=20 > > >>>> important > > >> > > >>>> all clocks used at the measurement sources to be synchronized=20 > > >>>> 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=20 > > >>>> 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=20 > > >>>> 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=20 > > >>>> version > > >> -02. > > >>>> > > >>>> Best regards! > > >>>> Mario. > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> PMOL mailing list > > >>> PMOL@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/pmol > > >> > > >> _______________________________________________ > > >> PMOL mailing list > > >> PMOL@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@cablelabs.com > > > > > > > > > _______________________________________________ > > > PMOL mailing list > > > PMOL@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@cablelabs.com Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938A73A68C0 for ; Tue, 10 Mar 2009 02:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.744 X-Spam-Level: X-Spam-Status: No, score=-105.744 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEC9J6Eah357 for ; Tue, 10 Mar 2009 02:23:45 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 0229E3A67F5 for ; Tue, 10 Mar 2009 02:23:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-161.messagelabs.com!1236677058!14712650!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 32250 invoked from network); 10 Mar 2009 09:24:19 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-10.tower-161.messagelabs.com with AES256-SHA encrypted SMTP; 10 Mar 2009 09:24:19 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2A9OICW012524 for ; Tue, 10 Mar 2009 05:24:18 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2A9OGE6012515 for ; Tue, 10 Mar 2009 05:24:17 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n2A9OGMh023309 for ; Tue, 10 Mar 2009 05:24:16 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n2A9OBpl023283 for ; Tue, 10 Mar 2009 05:24:11 -0400 Message-Id: <200903100924.n2A9OBpl023283@alph001.aldc.att.com> Received: from acmt.att.com (vpn-135-70-10-55.vpn.west.att.com[135.70.10.55](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090310092409gw1000u6bje>; Tue, 10 Mar 2009 09:24:10 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Mar 2009 05:24:07 -0400 To: "Marian Delkinov" , "Daryl Malas" From: Al Morton In-Reply-To: <40D78CDB69283744A4B07581DDFDEB550219264D@esealmw106.eemea. ericsson.se> References: <200903060322.n263MxV5021155@klph001.kcdc.att.com> <40D78CDB69283744A4B07581DDFDEB550219264D@esealmw106.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pmol@ietf.org Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 09:23:46 -0000 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@att.com] >Sent: Friday, 06 March, 2009 04:23 >To: Daryl Malas; Marian Delkinov; pmol@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" 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" >wrote: > > > > > >> Thanks Al! > > >> > > >> IMO, the definitions you proposed are accurate and in accordance > > >> with RFC 2330. > > >> > > >> Best regards! > > >> Mario. > > >> > > >> -----Original Message----- > > >> From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On > > >> Behalf Of Al Morton > > >> Sent: Tuesday, 03 March, 2009 22:13 > > >> To: Daryl Malas; pmol@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@cablelabs.com > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] > > >>>> Sent: Friday, February 20, 2009 3:43 AM > > >>>> To: Daryl Malas > > >>>> Cc: pmol@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@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/pmol > > >> > > >> _______________________________________________ > > >> PMOL mailing list > > >> PMOL@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@cablelabs.com > > > > > > > > > _______________________________________________ > > > PMOL mailing list > > > PMOL@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@cablelabs.com Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9430E3A6A14 for ; Tue, 10 Mar 2009 01:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U75z83mGziG5 for ; Tue, 10 Mar 2009 01:51:02 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 504623A6803 for ; Tue, 10 Mar 2009 01:51:02 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2CE3321000; Tue, 10 Mar 2009 09:51:36 +0100 (CET) X-AuditID: c1b4fb3e-ac89bbb0000023da-6c-49b62a17530f Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EADF22079C; Tue, 10 Mar 2009 09:51:35 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 09:51:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2009 09:51:33 +0100 Message-ID: <40D78CDB69283744A4B07581DDFDEB550219264D@esealmw106.eemea.ericsson.se> In-Reply-To: <200903060322.n263MxV5021155@klph001.kcdc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 thread-index: AcmeCuOn4OAr634kQXSzmPY+eCaqpwDUY3fA References: <200903060322.n263MxV5021155@klph001.kcdc.att.com> From: "Marian Delkinov" To: "Al Morton" , "Daryl Malas" X-OriginalArrivalTime: 10 Mar 2009 08:51:35.0112 (UTC) FILETIME=[6AB61C80:01C9A15D] X-Brightmail-Tracker: AAAAAA== Cc: pmol@ietf.org Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 08:51:04 -0000 =20 Al,=20 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?=20 Or perhaps you had another idea? Best regards! Mario. -----Original Message----- From: Al Morton [mailto:acmorton@att.com]=20 Sent: Friday, 06 March, 2009 04:23 To: Daryl Malas; Marian Delkinov; pmol@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=20 >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 =3D T1- UTC). spacing: (offset =3D 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" wrote: > > > Mario and Al, > > > > Thank you for coming to agreement on the text. I will update the=20 > > draft and submit today. > > > > Regards, > > > > Daryl > > > > > > On 3/4/09 1:39 AM, "Marian Delkinov" wrote: > > > >> Thanks Al! > >> > >> IMO, the definitions you proposed are accurate and in accordance=20 > >> with RFC 2330. > >> > >> Best regards! > >> Mario. > >> > >> -----Original Message----- > >> From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On=20 > >> Behalf Of Al Morton > >> Sent: Tuesday, 03 March, 2009 22:13 > >> To: Daryl Malas; pmol@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=20 > >> have been processed by the list. > >> > >> I think that the main question, when trying to reconcile Gerald's=20 > >> 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=20 > >> 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 =3D 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=20 > >> 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=20 > >>> hit the mailing list... > >>> > >>> > >>> ---------------- > >>> Daryl Malas > >>> CableLabs > >>> (o) +1 303 661 3302 > >>> (f) +1 303 661 9199 > >>> mailto:d.malas@cablelabs.com > >>> > >>> > >>>> -----Original Message----- > >>>> From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] > >>>> Sent: Friday, February 20, 2009 3:43 AM > >>>> To: Daryl Malas > >>>> Cc: pmol@ietf.org > >>>> Subject: RE: IETF Draft: SIP Performance Metrics-03 > >>>> > >>>> > >>>> Daryl, > >>>> > >>>> Sorry, for my perhaps delayed feedback! (I'm back after a long=20 > >>>> 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=20 > >>>> 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 =3D 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=20 > >>>> 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=20 > >>>> time > >> > >>>> offset". There is no ERROR in the time offset, because the time=20 > >>>> offset IS the error. Moreover RFC2330 doesn't define such error,=20 > >>>> the > >> > >>>> draft doesn't define it either, so better avoid using it. I=20 > >>>> suggest keeping the text as in version-02, but using "clock's offset". > >>>> > >>>> In addition, when correlating measurements, it's much more=20 > >>>> important > >> > >>>> all clocks used at the measurement sources to be synchronized to=20 > >>>> each other, rather than be synchronized to primary time source.=20 > >>>> 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=20 > >>>> 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=20 > >>>> skew > >> > >>>> [RFC2330]. > >>>> > >>>> > >>>> I'm OK with all other changes in version -03 compared to version > >> -02. > >>>> > >>>> Best regards! > >>>> Mario. > >>>> > >>>> > >>> _______________________________________________ > >>> PMOL mailing list > >>> PMOL@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pmol > >> > >> _______________________________________________ > >> PMOL mailing list > >> PMOL@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@cablelabs.com > > > > > > _______________________________________________ > > PMOL mailing list > > PMOL@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@cablelabs.com Return-Path: X-Original-To: pmol@ietf.org Delivered-To: pmol@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8C5113A6B17; Mon, 9 Mar 2009 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309233001.8C5113A6B17@core3.amsl.com> Date: Mon, 9 Mar 2009 16:30:01 -0700 (PDT) Cc: pmol@ietf.org Subject: [PMOL] I-D Action:draft-ietf-pmol-metrics-framework-02.txt X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 23:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Metrics for Other Layers Working Group of the IETF. Title : Framework for Performance Metric Development Author(s) : A. Clark Filename : draft-ietf-pmol-metrics-framework-02.txt Pages : 14 Date : 2009-03-09 This memo describes a framework and guidelines for the development of performance metrics that are beyond the scope of existing working group charters in the IETF. In this version, the memo refers to a Performance Metrics Entity, or PM Entity, which may in future be a working group or directorate or a combination of these two. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pmol-metrics-framework-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pmol-metrics-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09161742.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E0A3A69A1 for ; Sat, 7 Mar 2009 05:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.723 X-Spam-Level: X-Spam-Status: No, score=-105.723 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADWtsOH-B1op for ; Sat, 7 Mar 2009 05:20:40 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id A1AE53A6ABE for ; Sat, 7 Mar 2009 05:20:40 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-129.messagelabs.com!1236432071!23994147!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 18318 invoked from network); 7 Mar 2009 13:21:11 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-2.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 7 Mar 2009 13:21:11 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n27DLBGA029208 for ; Sat, 7 Mar 2009 05:21:11 -0800 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n27DL6Bo029175 for ; Sat, 7 Mar 2009 05:21:07 -0800 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n27DL6oS013935 for ; Sat, 7 Mar 2009 07:21:06 -0600 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n27DL0K0013883 for ; Sat, 7 Mar 2009 07:21:01 -0600 Message-Id: <200903071321.n27DL0K0013883@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-8-248.vpn.west.att.com[135.70.8.248](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090307132059gw1000u616e>; Sat, 7 Mar 2009 13:21:00 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Mar 2009 08:20:57 -0500 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [PMOL] Draft Agenda for pmol at IETF-74 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 13:20:41 -0000 Performance Metrics for Other Layers WG (pmol) The WG is currently scheduled for Tuesday 1710-1810 Afternoon Session III Imperial A Co-Chairs: Al Morton Alan Clark Please help contribute to a successful meeting by reading the drafts and references before we meet. Agenda: Draft of 3/7/09 0. Agenda Bashing 1. WG Status http://tools.ietf.org/wg/pmol/ 2. SIP Metrics Draft: Daryl Malas (review comment resolutions) http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics-03 3. Framework and Guidelines Draft: Alan Clark (file not yet available) http://tools.ietf.org/html/draft-ietf-pmol-metrics-framework-02 4. Discussion of Future of PMOL - Further thoughts following discussion at IETF-73: Is there a continued need for PMOL, as a WG or as a Directorate? 5. AOB Please contact the co-chairs directly with any proposals. To offer comments on PMOL work in progress or the agenda itself, please send email to: pmol@ietf.org Return-Path: X-Original-To: pmol@ietf.org Delivered-To: pmol@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6CCD33A685D; Fri, 6 Mar 2009 14:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306224501.6CCD33A685D@core3.amsl.com> Date: Fri, 6 Mar 2009 14:45:01 -0800 (PST) Cc: pmol@ietf.org Subject: [PMOL] I-D Action:draft-ietf-pmol-sip-perf-metrics-03.txt X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Metrics for Other Layers Working Group of the IETF. Title : SIP End-to-End Performance Metrics Author(s) : D. Malas, A. Morton Filename : draft-ietf-pmol-sip-perf-metrics-03.txt Pages : 32 Date : 2009-03-06 This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) based services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pmol-sip-perf-metrics-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pmol-sip-perf-metrics-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06144021.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96E93A6D0C for ; Fri, 6 Mar 2009 08:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg4ZJ9ASYDV4 for ; Fri, 6 Mar 2009 08:18:15 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 6D90D3A68B8 for ; Fri, 6 Mar 2009 08:18:15 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n26GIe6c012780; Fri, 6 Mar 2009 09:18:40 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 6 Mar 2009 09:18:41 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.253.129.8 ([10.253.129.8]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Mar 2009 16:18:41 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 06 Mar 2009 09:18:39 -0700 From: Daryl Malas To: Al Morton , Marian Delkinov , Message-ID: Thread-Topic: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 Thread-Index: AcmedzVXGykKM6LTeUW/FFYzUtgaFQ== In-Reply-To: <200903060322.n263MxAV021154@klph001.kcdc.att.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 16:18:16 -0000 Al, These have been corrected, thank you. Regards, Daryl On 3/5/09 8:22 PM, "Al Morton" 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" 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" wrote: >>> >>>> Thanks Al! >>>> >>>> IMO, the definitions you proposed are accurate and in accordance with >>>> RFC 2330. >>>> >>>> Best regards! >>>> Mario. >>>> >>>> -----Original Message----- >>>> From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of >>>> Al Morton >>>> Sent: Tuesday, 03 March, 2009 22:13 >>>> To: Daryl Malas; pmol@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@cablelabs.com >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] >>>>>> Sent: Friday, February 20, 2009 3:43 AM >>>>>> To: Daryl Malas >>>>>> Cc: pmol@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@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pmol >>>> >>>> _______________________________________________ >>>> PMOL mailing list >>>> PMOL@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@cablelabs.com >>> >>> >>> _______________________________________________ >>> PMOL mailing list >>> PMOL@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@cablelabs.com > ----------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3623A6D03 for ; Fri, 6 Mar 2009 08:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvuBXy9qPu8I for ; Fri, 6 Mar 2009 08:12:45 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id BA0EB3A68B8 for ; Fri, 6 Mar 2009 08:12:45 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n26GDF94012388; Fri, 6 Mar 2009 09:13:15 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 6 Mar 2009 09:13:15 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.253.129.8 ([10.253.129.8]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Mar 2009 16:13:14 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 06 Mar 2009 09:13:13 -0700 From: Daryl Malas To: Hadriel Kaplan Message-ID: Thread-Topic: (PMOL) IETF Draft: SIP Performance Metrics-03 Thread-Index: AcmLtlWZPOXhD9n3TOSSKt3F+SngYQCUsoAgAFI8rNADyRgvsA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Cc: "pmol@ietf.org" Subject: Re: [PMOL] (PMOL) IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 16:12:46 -0000 Hadriel, You are correct regarding this errors. These have been corrected. I also added some dialog regarding the the interval when calculating at the UAS. The previous interval description was only accurate from the view point of the UAC. Regards, Daryl On 2/14/09 3:02 PM, "Hadriel Kaplan" wrote: > > Daryl, > > Also, I think there're some errors: > > Section 4.5.1 says "Successful session completion SDT", but I believe it > should be "Successful session duration". > > Section 4.5.2 says it's: "defined as the interval between sending the first > bit of a session completion message, such as a BYE, and the resulting Timer F > expiration." But the drawing shows from time of 200, as did the previous > section's timer. > > -hadriel > Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAA13A6BF4 for ; Thu, 5 Mar 2009 19:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.715 X-Spam-Level: X-Spam-Status: No, score=-105.715 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwS34We4Wr2x for ; Thu, 5 Mar 2009 19:22:45 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id B97453A6BE5 for ; Thu, 5 Mar 2009 19:22:40 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1236309791!10648464!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 9173 invoked from network); 6 Mar 2009 03:23:11 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-8.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 6 Mar 2009 03:23:11 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n263N8B1027124 for ; Thu, 5 Mar 2009 19:23:08 -0800 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n263N3Nq026593 for ; Thu, 5 Mar 2009 19:23:04 -0800 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n263N3jD021218 for ; Thu, 5 Mar 2009 21:23:03 -0600 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n263MxVx021156 for ; Thu, 5 Mar 2009 21:22:59 -0600 Message-Id: <200903060322.n263MxVx021156@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-210-202.vpn.east.att.com[135.70.210.202](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090306032258gw1000u6nte>; Fri, 6 Mar 2009 03:22:58 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Mar 2009 22:22:57 -0500 To: Daryl Malas , Marian Delkinov , From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 03:22:47 -0000 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" 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" wrote: > > > >> Thanks Al! > >> > >> IMO, the definitions you proposed are accurate and in accordance with > >> RFC 2330. > >> > >> Best regards! > >> Mario. > >> > >> -----Original Message----- > >> From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of > >> Al Morton > >> Sent: Tuesday, 03 March, 2009 22:13 > >> To: Daryl Malas; pmol@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@cablelabs.com > >>> > >>> > >>>> -----Original Message----- > >>>> From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] > >>>> Sent: Friday, February 20, 2009 3:43 AM > >>>> To: Daryl Malas > >>>> Cc: pmol@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@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pmol > >> > >> _______________________________________________ > >> PMOL mailing list > >> PMOL@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@cablelabs.com > > > > > > _______________________________________________ > > PMOL mailing list > > PMOL@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@cablelabs.com Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08793A6949 for ; Thu, 5 Mar 2009 15:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AekWdDoa-swF for ; Thu, 5 Mar 2009 15:30:44 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 77F8D3A6856 for ; Thu, 5 Mar 2009 15:30:44 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n25NV9mq024459; Thu, 5 Mar 2009 16:31:10 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 5 Mar 2009 16:31:10 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.253.129.2 ([10.253.129.2]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Mar 2009 23:31:10 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 05 Mar 2009 16:31:08 -0700 From: Daryl Malas To: Marian Delkinov , Al Morton , Message-ID: Thread-Topic: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 Thread-Index: AcmcRO+eQKNzdV1sSKaHAXAV262ligAXoyFQAA9sw64AQlGj8g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 23:30:45 -0000 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). 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 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" 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" wrote: > >> Thanks Al! >> >> IMO, the definitions you proposed are accurate and in accordance with >> RFC 2330. >> >> Best regards! >> Mario. >> >> -----Original Message----- >> From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of >> Al Morton >> Sent: Tuesday, 03 March, 2009 22:13 >> To: Daryl Malas; pmol@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@cablelabs.com >>> >>> >>>> -----Original Message----- >>>> From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] >>>> Sent: Friday, February 20, 2009 3:43 AM >>>> To: Daryl Malas >>>> Cc: pmol@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@ietf.org >>> https://www.ietf.org/mailman/listinfo/pmol >> >> _______________________________________________ >> PMOL mailing list >> PMOL@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@cablelabs.com > > > _______________________________________________ > PMOL mailing list > PMOL@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@cablelabs.com Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AA6C28C425 for ; Thu, 5 Mar 2009 11:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqx3pyYfKqeU for ; Thu, 5 Mar 2009 11:06:32 -0800 (PST) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id E47F928C3CB for ; Thu, 5 Mar 2009 11:06:31 -0800 (PST) X-AuditID: ac108108-00000dc800000758-5d-49aeca6002f4 Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 10:37:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99CF7.B3E0A44E" Date: Wed, 4 Mar 2009 10:37:21 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: test from Research thread-index: Acmc+DxA/thxc5tEREm/OIywR5PPTw== From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Subject: [PMOL] test from Research X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: research@apparentnetworks.com List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:06:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99CF7.B3E0A44E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please ignore - having trouble posting. =20 Loki Jorgenson Chief Scientist Apparent Networks The Hudson House Suite 400 - 321 Water Street Vancouver, BC, Canada, V6B 1B8 e ljorgenson@ApparentNetworks.com t 604 433 2333 ext 105 f 604 433 2311 m 604 250-4642 w www.ApparentNetworks.com =20 ------_=_NextPart_001_01C99CF7.B3E0A44E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please = ignore -=20 having trouble posting.
 

Loki Jorgenson
Chief Scientist
Apparent = Networks
The=20 Hudson House
Suite 400 - 321 Water Street
Vancouver, BC, Canada, = V6B=20 1B8

e   = ljorgenson@ApparentNetworks.com
t   604=20 433 2333 ext 105
f   604 433 2311
m   604=20 250-4642
w   www.ApparentNetworks.com

 
------_=_NextPart_001_01C99CF7.B3E0A44E-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A303C28C3A2 for ; Thu, 5 Mar 2009 11:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.685 X-Spam-Level: X-Spam-Status: No, score=0.685 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rvj5M+VdjZ4V for ; Thu, 5 Mar 2009 11:06:33 -0800 (PST) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id 4F9C028C46B for ; Thu, 5 Mar 2009 11:06:32 -0800 (PST) X-AuditID: ac108108-00000dcc00000758-ac-49ad900367b6 Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 12:16:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C3C.554F4900" Date: Tue, 3 Mar 2009 12:16:04 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Test - please ignore thread-index: AcmcPNi0WhREplJrS2OW+Jd5tVM6LA== From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Subject: [PMOL] Test - please ignore X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:06:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C3C.554F4900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been unable to post to this list to date (although I receive postings by others). =20 I have just tried unsubscribing and subscribing again. =20 Loki Jorgenson e ljorgenson@ApparentNetworks.com t 604 433 2333 ext 105 f 604 433 2311 m 604 250-4642 w www.ApparentNetworks.com =20 ------_=_NextPart_001_01C99C3C.554F4900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have = been unable=20 to post to this list to date (although I receive postings by=20 others).
 
I have = just tried=20 unsubscribing and subscribing again.
 

Loki Jorgenson
e  =20 ljorgenson@ApparentNetworks.com
t   604 433 2333 ext=20 105
f   604 433 2311
m   604 = 250-4642
w  =20 www.ApparentNetworks.com

 
------_=_NextPart_001_01C99C3C.554F4900-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D536B28C3CB for ; Thu, 5 Mar 2009 11:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.728 X-Spam-Level: X-Spam-Status: No, score=0.728 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBz+kJ7mIb3t for ; Thu, 5 Mar 2009 11:06:33 -0800 (PST) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id 83BCF28C481 for ; Thu, 5 Mar 2009 11:06:32 -0800 (PST) X-AuditID: ac108108-00000cfc00000758-db-49ad864b6fd6 Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 11:34:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C36.8A5AFF5A" Date: Tue, 3 Mar 2009 11:34:36 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Testing PMOL subscription thread-index: AcmcNxEWnZYdU9WxSWaf8VP6kXiC+Q== From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Subject: [PMOL] Testing PMOL subscription X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:06:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C36.8A5AFF5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pardon this test - postings to PMOL have not worked for me in the past, even though I receive the postings from others. =20 Loki Jorgenson Chief Scientist Apparent Networks The Hudson House Suite 400 - 321 Water Street Vancouver, BC, Canada, V6B 1B8 e ljorgenson@ApparentNetworks.com t 604 433 2333 ext 105 f 604 433 2311 m 604 250-4642 w www.ApparentNetworks.com =20 ------_=_NextPart_001_01C99C36.8A5AFF5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pardon = this test -=20 postings to PMOL have not worked for me in the past, even though I = receive the=20 postings from others.
 

Loki Jorgenson
Chief Scientist
Apparent = Networks
The=20 Hudson House
Suite 400 - 321 Water Street
Vancouver, BC, Canada, = V6B=20 1B8

e   = ljorgenson@ApparentNetworks.com
t   604=20 433 2333 ext 105
f   604 433 2311
m   604=20 250-4642
w   www.ApparentNetworks.com

 
------_=_NextPart_001_01C99C36.8A5AFF5A-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D453228C3A2 for ; Thu, 5 Mar 2009 11:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdBE6vYB7nNs for ; Thu, 5 Mar 2009 11:06:32 -0800 (PST) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id 1DC0F28C453 for ; Thu, 5 Mar 2009 11:06:32 -0800 (PST) X-AuditID: ac108108-00000dd000000758-63-49aeb4627213 Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 09:03:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99CEA.986330CC" Date: Wed, 4 Mar 2009 09:03:31 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: comments on Framework Metrics draft thread-index: Acmc6yDA5SVndh2KQbGG9V2tieZapg== From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Subject: [PMOL] comments on Framework Metrics draft X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:06:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99CEA.986330CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All - I am aware that the WG last call closed January 2, 2009 for the Framework for Performance Metrics Development draft (v0.1). I am not sure of the utility of any comments past the expiry time. I have not seen any mention of it being submitted. =20 Regardless, on a recent re-reading, I noted some additional concerns. I am posting them in brief for consideration: =20 ------------------------------------- =20 Quality of Service/Experience: =20 There are a variety of references within the document to "quality of service" (QoS) and several more for "quality of experience" (QoE). Further, there are references to "application performance". None of these have been defined and therefore have been accepted with denotative meaning. However, these words have broader connotative meaning within the field and it would be difficult to interpret certain passages without additional reference. =20 >>> I would suggest that they should be more precisely defined. I can provide some input to this if it is seen as desirable. =20 Related point - there are repeated references to "application performance" as well as references to "application performance models" (ex. 3.5.3). These seem distinct and yet related to QoS and QoE. Some pundits (including myself) have begun referring to "quality of application" (QoA) to distinguish between the effects attributed to the network layers (QoS), the impacts of the application design and implementation (e.g. codec), and the experience of the end-user (QoE) which derives from other influences besides QoS and QoA. QoA seems most pertinent here insofar as PMOL aims to capture aspects of what may be considered application design (choice of buffer, codec, protocol). =20 >>> I would suggest considering the addition of QoA and using it as part of the definition set above. Again, I can provide some input if desirable. =20 Related point - there is a general suggestion that a proposed metric should be correlated against one of "quality of service", "quality of experience", or perhaps "application performance/quality of application" (see 3.2 (ii)) as a "test of usefulness". Similarly, 3.4.2 (ii) refers to "how this relates to the performance of the system being measured". Also, 4.2 refers to metric assessment on the basis of "correlation with application performance/user experience". =20 However there are no further directions on how that correlation is done, what the criteria are, or how correlation should be described within a PE entity definition. For example using the language referred to above, it may be that a given metric is considered identical to QoE (e.g. MOS) and thus directly comparable to end-user experience - correlation would then be exact with respect to the G.107 implementation and correlate approximately with standard means for generating user opinion scores. Alternately, a given metric may be considered only partially related (e.g. rate of discards given a fixed buffer size) and could be described as having some well-defined correlation to QoE or a QoE-specific metric (perhaps simply a graph of discards to MOS). =20 >>> I would recommend a section in the informative part of the metric definition describing any anticipated relationships or correlations to a quality assessment, and, where possible, how to confirm that correlation. =20 3.3.1 - the phrase "each of which has a greater time span that the original metrics" causes some confusion on first read. Upon reflection, and by virtue of the example provided, the meaning of the qualifier can be determined correctly. However, it can be incorrectly read that (each or all of) the summarized metrics span a greater time than the source metrics that generated the summary - which of course they don't - at best they span the same overall period. What is intended was something like "each individual metric value within the summarized set spans a period of time greater than or equal to each metric value from the original set". However, that still may not be the case where the periods for each metric value are unequal within the original set and/or where the summarized values may aggregate those original values unequally. =20 3.3.2 - The reference to an index would benefit from an example. An obvious one would be MOS or R-value from the Emodel. =20 3.4.2 (iii) Measurement Method - The second line suggests "It is important to also define exception cases...". I suggest that this should be replaced with "This SHOULD also define exception cases and how these are handled". =20 3.4.2 (iv) Units of Measurement - "must" --> "MUST" =20 3.4.2 (v) Measurement Timing - "must" --> "MUST" =20 3.4.3 (i) Implementation - "may" --> "MAY" =20 3.4.3 (iv) Reporting Model - the initial statement should rephrased as a "SHOULD" statement. Such as "The Reporting Model definition SHOULD describe any relationship(s) between the metric and the reporting model" =20 3.4.4. The "Verification" section described in 3.4.3 (ii) is missing. =20 3.4.4 The layout could be improved for readability - the "Normative" and "Informative" headers appear as peers of the other aspects. =20 3.4.5 Examples - the "Verification" section appears named as "Conformance Testing" - this should be made consistent with the balance of the document. =20 3.5.3 Relationship .... - as mentioned above, this section seems centrally important and yet under-represented in the definition of a PE. Simply listing this as a "dependency" seems inconsistent with the other statements throughout the document. I would recommend that QoS/QoE be more explicitly defined, with appropriate examples, possibly with addition of QoA (if there is support for this), and some sketch at least of how correlation may be established or can be described. Loki Jorgenson Chief Scientist Apparent Networks The Hudson House Suite 400 - 321 Water Street Vancouver, BC, Canada, V6B 1B8 e ljorgenson@ApparentNetworks.com t 604 433 2333 ext 105 f 604 433 2311 m 604 250-4642 w www.ApparentNetworks.com =20 ------_=_NextPart_001_01C99CEA.986330CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All - I am=20 aware that the WG last call closed January 2, 2009 for the Framework for = Performance Metrics Development draft (v0.1).   I am not sure = of the=20 utility of any comments past the expiry time.  I have not seen any = mention=20 of it being submitted.
 
Regardless, on a=20 recent re-reading, I noted some additional concerns.   I am = posting=20 them in brief for consideration:
 
-------------------------------------
 
Quality of=20 Service/Experience:
 
There = are a variety=20 of references within the document to "quality of service" (QoS) and = several=20 more for "quality of experience" (QoE).  Further, there are = references to=20 "application performance".  None of these have been defined and = therefore=20 have been accepted with denotative meaning.  However, these words = have=20 broader connotative meaning within the field and it would be difficult = to=20 interpret certain passages without additional = reference.
 
>>> I would=20 suggest that they should be more precisely defined.  I can = provide=20 some input to this if it is seen as desirable.
 
Related point -=20 there are repeated references to "application performance" as well as = references=20 to "application performance models" (ex. 3.5.3).  These seem = distinct and=20 yet related to QoS and QoE.  Some pundits (including myself) have = begun=20 referring to "quality of application" (QoA) to distinguish between = the=20 effects attributed to the network layers (QoS), the impacts of the = application=20 design and implementation (e.g. codec), and the experience of the = end-user (QoE)=20 which derives from other influences besides QoS and QoA.   QoA = seems=20 most pertinent here insofar as PMOL aims to capture aspects of what may = be=20 considered application design (choice of buffer, codec,=20 protocol).
 
>>> I would=20 suggest considering the addition of QoA and using it as part of the = definition=20 set above.  Again, I can provide some input if=20 desirable.
 
Related point -=20 there is a general suggestion that a proposed metric should = be correlated=20 against one of "quality of service", "quality of experience", or perhaps = "application performance/quality of application" (see 3.2 (ii)) as a = "test of=20 usefulness".   Similarly, 3.4.2 (ii) refers to "how this = relates to=20 the performance of the system being measured".  Also, 4.2 refers to = metric=20 assessment on the basis of "correlation with application = performance/user=20 experience".
 
However there are no=20 further directions on how that correlation is done, what the criteria=20 are, or how correlation should be described within a PE entity=20 definition.  For example using the language referred to above, it = may be=20 that a given metric is considered identical to QoE (e.g. MOS) and thus = directly=20 comparable to end-user experience - correlation would then be exact with = respect=20 to the G.107 implementation and correlate approximately with standard = means for=20 generating user opinion scores.  Alternately, a given = metric may=20 be considered only partially related (e.g. rate of discards given a = fixed=20 buffer size) and could be described as having some well-defined = correlation to=20 QoE or a QoE-specific metric (perhaps simply a graph of discards to=20 MOS).
 
>>> I would=20 recommend a section in the informative part of the metric definition = describing=20 any anticipated relationships or correlations to a quality assessment, = and,=20 where possible, how to confirm that correlation.
 
3.3.1 = - the phrase=20 "each of which has a greater time span that the original metrics" causes = some=20 confusion on first read.  Upon reflection, and by virtue of = the=20 example provided, the meaning of the qualifier can be determined=20 correctly.  However, it can be incorrectly read that (each or all=20 of)  the summarized metrics span a greater time than the = source=20 metrics that generated the summary - which of course they don't - at = best they=20 span the same overall period.  What is intended was something = like=20 "each individual metric value within the summarized set spans a period = of time=20 greater than or equal to each metric value from the original=20 set".  However, that still may not be the case where the periods = for each=20 metric value are unequal within the original set and/or where the = summarized=20 values may aggregate those original values=20 unequally.
 
3.3.2 = - The=20 reference to an index would benefit from an example.  An obvious = one would=20 be MOS or R-value from the Emodel.
 
3.4.2 = (iii)=20 Measurement Method - The second line suggests "It is important to also = define=20 exception cases...".   I suggest that this should be replaced = with=20 "This SHOULD also define exception cases and how these are=20 handled".
 
3.4.2 = (iv) Units of=20 Measurement - "must" --> "MUST"
 
3.4.2 = (v)=20 Measurement Timing - "must" --> "MUST"
 
3.4.3 = (i)=20 Implementation - "may" --> "MAY"
 
3.4.3 = (iv) Reporting=20 Model - the initial statement should rephrased as a "SHOULD"=20 statement.  Such as "The Reporting Model definition SHOULD describe = any=20 relationship(s) between the metric and the reporting = model"
 
3.4.4. = The=20 "Verification" section described in 3.4.3 (ii) is = missing.
 
3.4.4  The=20 layout could be improved for readability - the "Normative" and = "Informative"=20 headers appear as peers of the other aspects.
 
3.4.5 = Examples - the=20 "Verification" section appears named as "Conformance Testing" - this = should be=20 made consistent with the balance of the document.
 
3.5.3 = Relationship=20 .... - as mentioned above, this section seems centrally important and = yet=20 under-represented in the definition of a PE.  Simply listing this = as a=20 "dependency" seems inconsistent with the other statements throughout the = document.  I would recommend that QoS/QoE be more explicitly = defined, with=20 appropriate examples, possibly with addition of QoA (if there is support = for=20 this), and some sketch at least of how correlation may be established or = can be=20 described.

Loki Jorgenson
Chief Scientist
Apparent = Networks
The=20 Hudson House
Suite 400 - 321 Water Street
Vancouver, BC, Canada, = V6B=20 1B8

e   = ljorgenson@ApparentNetworks.com
t   604=20 433 2333 ext 105
f   604 433 2311
m   604=20 250-4642
w   www.ApparentNetworks.com

 
------_=_NextPart_001_01C99CEA.986330CC-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8306728C47B for ; Thu, 5 Mar 2009 11:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 738mqLRaAUog for ; Thu, 5 Mar 2009 11:06:31 -0800 (PST) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id B805A28C43B for ; Thu, 5 Mar 2009 11:06:31 -0800 (PST) X-AuditID: ac108108-00000d0800000758-b4-49aecdfb7d3c Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 10:52:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99CF9.DA17F444" Date: Wed, 4 Mar 2009 10:52:44 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Test to PMOL thread-index: Acmc+mJy7DaPvm0wRrmfleSsSpzVxQ== From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Subject: [PMOL] Test to PMOL X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:06:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99CF9.DA17F444 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please ignore - having trouble getting submissions to the list Loki Jorgenson Chief Scientist Apparent Networks The Hudson House Suite 400 - 321 Water Street Vancouver, BC, Canada, V6B 1B8 e ljorgenson@ApparentNetworks.com t 604 433 2333 ext 105 f 604 433 2311 m 604 250-4642 w www.ApparentNetworks.com =20 ------_=_NextPart_001_01C99CF9.DA17F444 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please = ignore -=20 having trouble getting submissions to the list

Loki Jorgenson
Chief Scientist
Apparent = Networks
The=20 Hudson House
Suite 400 - 321 Water Street
Vancouver, BC, Canada, = V6B=20 1B8

e   = ljorgenson@ApparentNetworks.com
t   604=20 433 2333 ext 105
f   604 433 2311
m   604=20 250-4642
w   www.ApparentNetworks.com

 
------_=_NextPart_001_01C99CF9.DA17F444-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF99728C43B for ; Thu, 5 Mar 2009 11:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok8nHXYPhoUD for ; Thu, 5 Mar 2009 11:06:31 -0800 (PST) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id 8A92228C427 for ; Thu, 5 Mar 2009 11:06:31 -0800 (PST) X-AuditID: ac108108-00000dcc00000758-d0-49aef1f05120 Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 13:26:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99D0F.48731D46" Date: Wed, 4 Mar 2009 13:26:09 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: comments on Framework Metrics draft thread-index: Acmc6yDA5SVndh2KQbGG9V2tieZapgAJIcGQ References: From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Subject: [PMOL] comments on Framework Metrics draft X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:06:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99D0F.48731D46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All - I am aware that the WG last call closed January 2, 2009 for the Framework for Performance Metrics Development draft (v0.1). I am not sure of the utility of any comments past the expiry time. I have not seen any mention of it being submitted. =20 Regardless, on a recent re-reading, I noted some additional concerns. I am posting them in brief for consideration: =20 ------------------------------------- =20 Quality of Service/Experience: =20 There are a variety of references within the document to "quality of service" (QoS) and several more for "quality of experience" (QoE). Further, there are references to "application performance". None of these have been defined and therefore have been accepted with denotative meaning. However, these words have broader connotative meaning within the field and it would be difficult to interpret certain passages without additional reference. =20 >>> I would suggest that they should be more precisely defined. I can provide some input to this if it is seen as desirable. =20 Related point - there are repeated references to "application performance" as well as references to "application performance models" (ex. 3.5.3). These seem distinct and yet related to QoS and QoE. Some pundits (including myself) have begun referring to "quality of application" (QoA) to distinguish between the effects attributed to the network layers (QoS), the impacts of the application design and implementation (e.g. codec), and the experience of the end-user (QoE) which derives from other influences besides QoS and QoA. QoA seems most pertinent here insofar as PMOL aims to capture aspects of what may be considered application design (choice of buffer, codec, protocol). =20 >>> I would suggest considering the addition of QoA and using it as part of the definition set above. Again, I can provide some input if desirable. =20 Related point - there is a general suggestion that a proposed metric should be correlated against one of "quality of service", "quality of experience", or perhaps "application performance/quality of application" (see 3.2 (ii)) as a "test of usefulness". Similarly, 3.4.2 (ii) refers to "how this relates to the performance of the system being measured". Also, 4.2 refers to metric assessment on the basis of "correlation with application performance/user experience". =20 However there are no further directions on how that correlation is done, what the criteria are, or how correlation should be described within a PE entity definition. For example using the language referred to above, it may be that a given metric is considered identical to QoE (e.g. MOS) and thus directly comparable to end-user experience - correlation would then be exact with respect to the G.107 implementation and correlate approximately with standard means for generating user opinion scores. Alternately, a given metric may be considered only partially related (e.g. rate of discards given a fixed buffer size) and could be described as having some well-defined correlation to QoE or a QoE-specific metric (perhaps simply a graph of discards to MOS). =20 >>> I would recommend a section in the informative part of the metric definition describing any anticipated relationships or correlations to a quality assessment, and, where possible, how to confirm that correlation. =20 3.3.1 - the phrase "each of which has a greater time span that the original metrics" causes some confusion on first read. Upon reflection, and by virtue of the example provided, the meaning of the qualifier can be determined correctly. However, it can be incorrectly read that (each or all of) the summarized metrics span a greater time than the source metrics that generated the summary - which of course they don't - at best they span the same overall period. What is intended was something like "each individual metric value within the summarized set spans a period of time greater than or equal to each metric value from the original set". However, that still may not be the case where the periods for each metric value are unequal within the original set and/or where the summarized values may aggregate those original values unequally. =20 3.3.2 - The reference to an index would benefit from an example. An obvious one would be MOS or R-value from the Emodel. =20 3.4.2 (iii) Measurement Method - The second line suggests "It is important to also define exception cases...". I suggest that this should be replaced with "This SHOULD also define exception cases and how these are handled". =20 3.4.2 (iv) Units of Measurement - "must" --> "MUST" =20 3.4.2 (v) Measurement Timing - "must" --> "MUST" =20 3.4.3 (i) Implementation - "may" --> "MAY" =20 3.4.3 (iv) Reporting Model - the initial statement should rephrased as a "SHOULD" statement. Such as "The Reporting Model definition SHOULD describe any relationship(s) between the metric and the reporting model" =20 3.4.4. The "Verification" section described in 3.4.3 (ii) is missing. =20 3.4.4 The layout could be improved for readability - the "Normative" and "Informative" headers appear as peers of the other aspects. =20 3.4.5 Examples - the "Verification" section appears named as "Conformance Testing" - this should be made consistent with the balance of the document. =20 3.5.3 Relationship .... - as mentioned above, this section seems centrally important and yet under-represented in the definition of a PE. Simply listing this as a "dependency" seems inconsistent with the other statements throughout the document. I would recommend that QoS/QoE be more explicitly defined, with appropriate examples, possibly with addition of QoA (if there is support for this), and some sketch at least of how correlation may be established or can be described. Loki Jorgenson Chief Scientist Apparent Networks The Hudson House Suite 400 - 321 Water Street Vancouver, BC, Canada, V6B 1B8 e ljorgenson@ApparentNetworks.com t 604 433 2333 ext 105 f 604 433 2311 m 604 250-4642 w www.ApparentNetworks.com =20 ------_=_NextPart_001_01C99D0F.48731D46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All - I am aware that the WG last call closed January 2, = 2009 for=20 the Framework for Performance Metrics Development draft = (v0.1).   I am=20 not sure of the utility of any comments past the expiry time.  I = have not=20 seen any mention of it being submitted.
 
Regardless, on a=20 recent re-reading, I noted some additional concerns.   I am = posting=20 them in brief for consideration:
 
-------------------------------------
 
Quality of=20 Service/Experience:
 
There = are a variety=20 of references within the document to "quality of service" (QoS) and = several=20 more for "quality of experience" (QoE).  Further, there are = references to=20 "application performance".  None of these have been defined and = therefore=20 have been accepted with denotative meaning.  However, these words = have=20 broader connotative meaning within the field and it would be difficult = to=20 interpret certain passages without additional = reference.
 
>>> I would=20 suggest that they should be more precisely defined.  I can = provide=20 some input to this if it is seen as desirable.
 
Related point -=20 there are repeated references to "application performance" as well as = references=20 to "application performance models" (ex. 3.5.3).  These seem = distinct and=20 yet related to QoS and QoE.  Some pundits (including myself) have = begun=20 referring to "quality of application" (QoA) to distinguish between = the=20 effects attributed to the network layers (QoS), the impacts of the = application=20 design and implementation (e.g. codec), and the experience of the = end-user (QoE)=20 which derives from other influences besides QoS and QoA.   QoA = seems=20 most pertinent here insofar as PMOL aims to capture aspects of what may = be=20 considered application design (choice of buffer, codec,=20 protocol).
 
>>> I would=20 suggest considering the addition of QoA and using it as part of the = definition=20 set above.  Again, I can provide some input if=20 desirable.
 
Related point -=20 there is a general suggestion that a proposed metric should = be correlated=20 against one of "quality of service", "quality of experience", or perhaps = "application performance/quality of application" (see 3.2 (ii)) as a = "test of=20 usefulness".   Similarly, 3.4.2 (ii) refers to "how this = relates to=20 the performance of the system being measured".  Also, 4.2 refers to = metric=20 assessment on the basis of "correlation with application = performance/user=20 experience".
 
However there are no=20 further directions on how that correlation is done, what the criteria=20 are, or how correlation should be described within a PE entity=20 definition.  For example using the language referred to above, it = may be=20 that a given metric is considered identical to QoE (e.g. MOS) and thus = directly=20 comparable to end-user experience - correlation would then be exact with = respect=20 to the G.107 implementation and correlate approximately with standard = means for=20 generating user opinion scores.  Alternately, a given = metric may=20 be considered only partially related (e.g. rate of discards given a = fixed=20 buffer size) and could be described as having some well-defined = correlation to=20 QoE or a QoE-specific metric (perhaps simply a graph of discards to=20 MOS).
 
>>> I would=20 recommend a section in the informative part of the metric definition = describing=20 any anticipated relationships or correlations to a quality assessment, = and,=20 where possible, how to confirm that correlation.
 
3.3.1 = - the phrase=20 "each of which has a greater time span that the original metrics" causes = some=20 confusion on first read.  Upon reflection, and by virtue of = the=20 example provided, the meaning of the qualifier can be determined=20 correctly.  However, it can be incorrectly read that (each or all=20 of)  the summarized metrics span a greater time than the = source=20 metrics that generated the summary - which of course they don't - at = best they=20 span the same overall period.  What is intended was something = like=20 "each individual metric value within the summarized set spans a period = of time=20 greater than or equal to each metric value from the original=20 set".  However, that still may not be the case where the periods = for each=20 metric value are unequal within the original set and/or where the = summarized=20 values may aggregate those original values=20 unequally.
 
3.3.2 = - The=20 reference to an index would benefit from an example.  An obvious = one would=20 be MOS or R-value from the Emodel.
 
3.4.2 = (iii)=20 Measurement Method - The second line suggests "It is important to also = define=20 exception cases...".   I suggest that this should be replaced = with=20 "This SHOULD also define exception cases and how these are=20 handled".
 
3.4.2 = (iv) Units of=20 Measurement - "must" --> "MUST"
 
3.4.2 = (v)=20 Measurement Timing - "must" --> "MUST"
 
3.4.3 = (i)=20 Implementation - "may" --> "MAY"
 
3.4.3 = (iv) Reporting=20 Model - the initial statement should rephrased as a "SHOULD"=20 statement.  Such as "The Reporting Model definition SHOULD describe = any=20 relationship(s) between the metric and the reporting = model"
 
3.4.4. = The=20 "Verification" section described in 3.4.3 (ii) is = missing.
 
3.4.4  The=20 layout could be improved for readability - the "Normative" and = "Informative"=20 headers appear as peers of the other aspects.
 
3.4.5 = Examples - the=20 "Verification" section appears named as "Conformance Testing" - this = should be=20 made consistent with the balance of the document.
 
3.5.3 = Relationship=20 .... - as mentioned above, this section seems centrally important and = yet=20 under-represented in the definition of a PE.  Simply listing this = as a=20 "dependency" seems inconsistent with the other statements throughout the = document.  I would recommend that QoS/QoE be more explicitly = defined, with=20 appropriate examples, possibly with addition of QoA (if there is support = for=20 this), and some sketch at least of how correlation may be established or = can be=20 described.

Loki Jorgenson
Chief Scientist
Apparent = Networks
The=20 Hudson House
Suite 400 - 321 Water Street
Vancouver, BC, Canada, = V6B=20 1B8

e   = ljorgenson@ApparentNetworks.com
t   604=20 433 2333 ext 105
f   604 433 2311
m   604=20 250-4642
w   www.ApparentNetworks.com

 
------_=_NextPart_001_01C99D0F.48731D46-- Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D0328C1C3 for ; Wed, 4 Mar 2009 19:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.067 X-Spam-Level: X-Spam-Status: No, score=-105.067 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-syh-9CkeXU for ; Wed, 4 Mar 2009 19:33:59 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 45CEB28C1BA for ; Wed, 4 Mar 2009 19:33:59 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1236224068!10585620!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 21680 invoked from network); 5 Mar 2009 03:34:28 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-8.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 5 Mar 2009 03:34:28 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n253YPJq022326 for ; Wed, 4 Mar 2009 19:34:25 -0800 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n253YJjX022283 for ; Wed, 4 Mar 2009 19:34:20 -0800 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n253YJlV004156 for ; Wed, 4 Mar 2009 21:34:19 -0600 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n253YDHt004128 for ; Wed, 4 Mar 2009 21:34:13 -0600 Message-Id: <200903050334.n253YDHt004128@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-16-154.vpn.west.att.com[135.70.16.154](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090305033412gw1000u6cte>; Thu, 5 Mar 2009 03:34:12 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Mar 2009 22:34:09 -0500 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [PMOL] Fwd: comments on Framework Metrics draft X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 03:34:01 -0000 Forwarded on behalf of Loki,

Subject: comments on Framework Metrics draft
Date: Wed, 4 Mar 2009 13:26:09 -0800
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: comments on Framework Metrics draft
thread-index: Acmc6yDA5SVndh2KQbGG9V2tieZapgAJIcGQ
From: "Loki Jorgenson" <ljorgenson@apparentnetworks.com>
To: <pmol@ietf.org>
Cc: "Alan Clark" <alan.d.clark@telchemy.com>, "Al Morton" <acmorton@att.com>
X-Brightmail-Tracker: AAAAAA==

All - I am aware that the WG last call closed January 2, 2009 for the Framework for Performance Metrics Development draft (v0.1).   I am not sure of the utility of any comments past the expiry time.  I have not seen any mention of it being submitted.
 
Regardless, on a recent re-reading, I noted some additional concerns.   I am posting them in brief for consideration:
 
-------------------------------------
 
Quality of Service/Experience:
 
There are a variety of references within the document to "quality of service" (QoS) and several more for "quality of experience" (QoE).  Further, there are references to "application performance".  None of these have been defined and therefore have been accepted with denotative meaning.  However, these words have broader connotative meaning within the field and it would be difficult to interpret certain passages without additional reference.
 
>>> I would suggest that they should be more precisely defined.  I can provide some input to this if it is seen as desirable.
 
Related point - there are repeated references to "application performance" as well as references to "application performance models" (ex. 3.5.3).  These seem distinct and yet related to QoS and QoE.  Some pundits (including myself) have begun referring to "quality of application" (QoA) to distinguish between the effects attributed to the network layers (QoS), the impacts of the application design and implementation (e.g. codec), and the experience of the end-user (QoE) which derives from other influences besides QoS and QoA.   QoA seems most pertinent here insofar as PMOL aims to capture aspects of what may be considered application design (choice of buffer, codec, protocol).
 
>>> I would suggest considering the addition of QoA and using it as part of the definition set above.  Again, I can provide some input if desirable.
 
Related point - there is a general suggestion that a proposed metric should be correlated against one of "quality of service", "quality of experience", or perhaps "application performance/quality of application" (see 3.2 (ii)) as a "test of usefulness".   Similarly, 3.4.2 (ii) refers to "how this relates to the performance of the system being measured".  Also, 4.2 refers to metric assessment on the basis of "correlation with application performance/user experience".
 
However there are no further directions on how that correlation is done, what the criteria are, or how correlation should be described within a PE entity definition.  For example using the language referred to above, it may be that a given metric is considered identical to QoE (e.g. MOS) and thus directly comparable to end-user experience - correlation would then be exact with respect to the G.107 implementation and correlate approximately with standard means for generating user opinion scores.  Alternately, a given metric may be considered only partially related (e.g. rate of discards given a fixed buffer size) and could be described as having some well-defined correlation to QoE or a QoE-specific metric (perhaps simply a graph of discards to MOS).
 
>>> I would recommend a section in the informative part of the metric definition describing any anticipated relationships or correlations to a quality assessment, and, where possible, how to confirm that correlation.
 
3.3.1 - the phrase "each of which has a greater time span that the original metrics" causes some confusion on first read.  Upon reflection, and by virtue of the example provided, the meaning of the qualifier can be determined correctly.  However, it can be incorrectly read that (each or all of)  the summarized metrics span a greater time than the source metrics that generated the summary - which of course they don't - at best they span the same overall period.  What is intended was something like "each individual metric value within the summarized set spans a period of time greater than or equal to each metric value from the original set".  However, that still may not be the case where the periods for each metric value are unequal within the original set and/or where the summarized values may aggregate those original values unequally.
 
3.3.2 - The reference to an index would benefit from an example.  An obvious one would be MOS or R-value from the Emodel.
 
3.4.2 (iii) Measurement Method - The second line suggests "It is important to also define exception cases...".   I suggest that this should be replaced with "This SHOULD also define exception cases and how these are handled".
 
3.4.2 (iv) Units of Measurement - "must" --> "MUST"
 
3.4.2 (v) Measurement Timing - "must" --> "MUST"
 
3.4.3 (i) Implementation - "may" --> "MAY"
 
3.4.3 (iv) Reporting Model - the initial statement should rephrased as a "SHOULD" statement.  Such as "The Reporting Model definition SHOULD describe any relationship(s) between the metric and the reporting model"
 
3.4.4. The "Verification" section described in 3.4.3 (ii) is missing.
 
3.4.4  The layout could be improved for readability - the "Normative" and "Informative" headers appear as peers of the other aspects.
 
3.4.5 Examples - the "Verification" section appears named as "Conformance Testing" - this should be made consistent with the balance of the document.
 
3.5.3 Relationship .... - as mentioned above, this section seems centrally important and yet under-represented in the definition of a PE.  Simply listing this as a "dependency" seems inconsistent with the other statements throughout the document.  I would recommend that QoS/QoE be more explicitly defined, with appropriate examples, possibly with addition of QoA (if there is support for this), and some sketch at least of how correlation may be established or can be described.

Loki Jorgenson
Chief Scientist
Apparent Networks
The Hudson House
Suite 400 - 321 Water Street
Vancouver, BC, Canada, V6B 1B8

e   ljorgenson@ApparentNetworks.com
t   604 433 2333 ext 105
f   604 433 2311
m   604 250-4642
w   www.ApparentNetworks.com

 
Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A201228C399 for ; Wed, 4 Mar 2009 07:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAA6e3cBzgfE for ; Wed, 4 Mar 2009 07:51:42 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id AC5A828C39D for ; Wed, 4 Mar 2009 07:51:42 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n24Fq6tV029571; Wed, 4 Mar 2009 08:52:07 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 4 Mar 2009 08:52:07 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.4.10.99 ([10.4.10.99]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Mar 2009 15:52:07 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 04 Mar 2009 08:52:13 -0700 From: Daryl Malas To: Marian Delkinov , Al Morton , Message-ID: Thread-Topic: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 Thread-Index: AcmcRO+eQKNzdV1sSKaHAXAV262ligAXoyFQAA9sw64= In-Reply-To: <40D78CDB69283744A4B07581DDFDEB55020A4956@esealmw106.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 15:51:44 -0000 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" wrote: > Thanks Al! > > IMO, the definitions you proposed are accurate and in accordance with > RFC 2330. > > Best regards! > Mario. > > -----Original Message----- > From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of > Al Morton > Sent: Tuesday, 03 March, 2009 22:13 > To: Daryl Malas; pmol@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@cablelabs.com >> >> >>> -----Original Message----- >>> From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] >>> Sent: Friday, February 20, 2009 3:43 AM >>> To: Daryl Malas >>> Cc: pmol@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@ietf.org >> https://www.ietf.org/mailman/listinfo/pmol > > _______________________________________________ > PMOL mailing list > PMOL@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@cablelabs.com Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769AA28C2BC for ; Wed, 4 Mar 2009 00:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSIxqUNwHXkV for ; Wed, 4 Mar 2009 00:40:55 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1AC673A6B76 for ; Wed, 4 Mar 2009 00:40:55 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 18CCA220EE; Wed, 4 Mar 2009 09:40:02 +0100 (CET) X-AuditID: c1b4fb3c-ad80abb000001b43-e0-49ae3e61dad7 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB4F821E98; Wed, 4 Mar 2009 09:40:01 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 09:40:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 09:39:58 +0100 Message-ID: <40D78CDB69283744A4B07581DDFDEB55020A4956@esealmw106.eemea.ericsson.se> In-Reply-To: <200903032113.n23LDPus018556@klph001.kcdc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 thread-index: AcmcRO+eQKNzdV1sSKaHAXAV262ligAXoyFQ References: <160DE07A1C4F8E4AA2715DEC577DA491B1B13B@srvxchg3.cablelabs.com> <200903032113.n23LDPus018556@klph001.kcdc.att.com> From: "Marian Delkinov" To: "Al Morton" , "Daryl Malas" , X-OriginalArrivalTime: 04 Mar 2009 08:40:01.0828 (UTC) FILETIME=[CF00DE40:01C99CA4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 08:40:56 -0000 Thanks Al!=20 IMO, the definitions you proposed are accurate and in accordance with RFC 2330.=20 Best regards! Mario. -----Original Message----- From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of Al Morton Sent: Tuesday, 03 March, 2009 22:13 To: Daryl Malas; pmol@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 =3D 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=20 >the mailing list... > > >---------------- >Daryl Malas >CableLabs >(o) +1 303 661 3302 >(f) +1 303 661 9199 >mailto:d.malas@cablelabs.com > > > > -----Original Message----- > > From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] > > Sent: Friday, February 20, 2009 3:43 AM > > To: Daryl Malas > > Cc: pmol@ietf.org > > Subject: RE: IETF Draft: SIP Performance Metrics-03 > > > > > > Daryl, > > > > Sorry, for my perhaps delayed feedback! (I'm back after a long=20 > > absence). > > > > I checked the new version (03) of the draft. All the texts that I=20 > > had comments before are fine. > > > > However, I found some changes in other texts, based on other=20 > > 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 =3D T1- UTC). > > > > Instead of using the term "time offset" above, I suggest "clock's=20 > > offset". Thus the text will comply with the terminology used in=20 > > 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=20 > > 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=20 > > 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=20 > > 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=20 > > 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@ietf.org >https://www.ietf.org/mailman/listinfo/pmol _______________________________________________ PMOL mailing list PMOL@ietf.org https://www.ietf.org/mailman/listinfo/pmol Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641CA3A691A for ; Tue, 3 Mar 2009 13:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.597 X-Spam-Level: X-Spam-Status: No, score=-105.597 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BY8fO+99iRo for ; Tue, 3 Mar 2009 13:13:12 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 3ADBC3A6818 for ; Tue, 3 Mar 2009 13:13:12 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1236114818!47515561!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 22584 invoked from network); 3 Mar 2009 21:13:39 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-12.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 3 Mar 2009 21:13:39 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n23LDcS6028053 for ; Tue, 3 Mar 2009 13:13:38 -0800 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n23LDV5I027966 for ; Tue, 3 Mar 2009 13:13:31 -0800 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n23LDVmh018644 for ; Tue, 3 Mar 2009 15:13:31 -0600 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n23LDPus018556 for ; Tue, 3 Mar 2009 15:13:26 -0600 Message-Id: <200903032113.n23LDPus018556@klph001.kcdc.att.com> Received: from acmt.att.com (dyp004275dys.mt.att.com[135.16.251.250](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090303211325gw1000u6tre>; Tue, 3 Mar 2009 21:13:25 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Mar 2009 16:13:24 -0500 To: "Daryl Malas" , From: Al Morton In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B13B@srvxchg3.cablelabs. com> References: <160DE07A1C4F8E4AA2715DEC577DA491B1B13B@srvxchg3.cablelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 21:13:13 -0000 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@cablelabs.com > > > > -----Original Message----- > > From: Marian Delkinov [mailto:marian.delkinov@ericsson.com] > > Sent: Friday, February 20, 2009 3:43 AM > > To: Daryl Malas > > Cc: pmol@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@ietf.org >https://www.ietf.org/mailman/listinfo/pmol