From ippm-admin@advanced.org Wed Jan 3 17:50:37 2001 Received: from mailhost.advanced.org (root@webmail.advanced.org [209.211.239.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07401 for ; Wed, 3 Jan 2001 17:50:37 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f03Mm3j18556; Wed, 3 Jan 2001 17:48:03 -0500 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.230]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f03Mlxj18526; Wed, 3 Jan 2001 17:47:59 -0500 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id RAA24626; Wed, 3 Jan 2001 17:47:58 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f03Mlwj18514; Wed, 3 Jan 2001 17:47:58 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Cc: "Matt Zekauskas" , "Merike Kaeo" Date: Wed, 3 Jan 2001 17:55:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] [ADMIN] IPPM Mailing List Changes Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The changes I mentioned earlier have now been implemented. You should continue to send new mail to ippm@advanced.org. These changes should be "relatively transparent" -- however, you will get an [ippm] tag added to the subject of mail sent to this list. * The mail server has moved to a new machine (off of IRIX) * The mailing list is now managed by mailman (similar to other ietf.org lists). As with the previous setup, mail that does not have ippm in the To: or Cc: lines is rejected (to me). I will forward anything that is remotely relevant. This is simply a crude way to catch some unsolicited commercial email ("spam"). You can also access your own subscription information through the web interface, http://mailhost.advanced.org/mailman/listinfo/ippm/ . Once a month you will get a reminder that you are on the list, with directions on how to remove yourself. * There is a "virus scanner" that runs on the mail server to try and prevent people from sending well-known viruses out over the list. Again, this is not a guarantee; you should still be circumspect when opening messages. Mail archives are still be available off of http://www.advanced.org/IPPM/ ; we started a fresh Hypermail archive, though. (In addition, there is a copy of all mail sent since September 1999 kept at ietf.org; ftp://ftp.ietf.org/ietf-mail-archive/ippm/ should get you a series of flat files by month.) As before, you may send subscribe and unsubscribe requests to ippm-request@advanced.org. Please let me know directly if you discover any problems. --Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jan 5 09:16:35 2001 Received: from mailhost.advanced.org (root@webmail.advanced.org [209.211.239.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13128 for ; Fri, 5 Jan 2001 09:16:35 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f05ED3j07964; Fri, 5 Jan 2001 09:13:03 -0500 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.230]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f05ED0j07937; Fri, 5 Jan 2001 09:13:00 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id JAA27463; Fri, 5 Jan 2001 09:12:58 -0500 (EST) From: vilho.raisanen@nokia.com Received: from esvir06nok.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f05ECvo14182; Fri, 5 Jan 2001 16:12:57 +0200 (EET) Received: from esebh11nok.ntc.nokia.com (unverified) by esvir06nok.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 5 Jan 2001 16:12:57 +0200 Received: by esebh11nok with Internet Mail Service (5.5.2652.78) id ; Fri, 5 Jan 2001 16:12:57 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10520A8E5@eseis04nok> To: ippm@advanced.org Cc: matt@advanced.org, kaeo@merike.com, g.grotefeld@motorola.com, vilho.raisanen@nokia.com Date: Fri, 5 Jan 2001 16:12:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [ippm] official submission of -04 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Dear IPPMers, following Matt's advice, I sent the present version of the npmps draft to internet-drafts@ietf.org so that an official WG version is available. The official version -04.txt is the same as 04bis.txt sent to the list, except that dates & contact information have been updated. BR, Vilho _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jan 8 07:30:03 2001 Received: from mailhost.advanced.org (root@webmail.advanced.org [209.211.239.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00803 for ; Mon, 8 Jan 2001 07:30:02 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f08CS3j09933; Mon, 8 Jan 2001 07:28:03 -0500 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.230]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f08CRaj09903 for ; Mon, 8 Jan 2001 07:27:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id HAA09574 for ; Mon, 8 Jan 2001 07:27:35 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00306; Mon, 8 Jan 2001 07:27:29 -0500 (EST) Message-Id: <200101081227.HAA00306@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Date: Mon, 08 Jan 2001 07:27:29 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-npmps-04.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Network performance measurement for periodic streams Author(s) : V. Raisanen, G. Grotefeld Filename : draft-ietf-ippm-npmps-04.txt Pages : 19 Date : 05-Jan-01 This document describes a sample metric suitable for application- level IP network transport measurement for periodic streams, such as VoIP or streaming multimedia over IP. In this document, the reader is assumed to be familiar with the terminology of the Framework for IP Performance Metrics RFC 2330 [1]. This document is parallel to A One-way Delay Metric for IPPM RFC 2679 [2]. Although this document is based on the delay metrics, other characteristics can be measured with this approach, too. For example, packet loss rate, reordering / out-of sequence, and successive delay variation are all additional metrics which can be built from this baseline set of measurements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-npmps-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-npmps-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010105145623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-npmps-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-npmps-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010105145623.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jan 25 13:15:06 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05389 for ; Thu, 25 Jan 2001 13:15:00 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0PIB3h12581; Thu, 25 Jan 2001 13:11:03 -0500 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0PIAxh12555 for ; Thu, 25 Jan 2001 13:11:00 -0500 Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA22144; Thu, 25 Jan 2001 10:11:01 -0800 (PST) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.1/8.11.1) id f0PIAw197716; Thu, 25 Jan 2001 10:10:58 -0800 (PST) (envelope-from bmah) Message-Id: <200101251810.f0PIAw197716@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4 To: ippm@advanced.org Cc: bmah@cisco.com From: bmah@cisco.com (Bruce A. Mah) X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1752695882P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 25 Jan 2001 10:10:58 -0800 Subject: [ippm] pchar-1.3 available Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List --==_Exmh_-1752695882P Content-Type: text/plain; charset=us-ascii Hi ippm-ers-- I apologize if this message isn't exactly working group business, but some of you may be interested to know that.... I'm most pleased to announce the release of pchar-1.3, a utility for characterizing the individual links along a path between two network hosts. pchar has been tested on various versions of FreeBSD, NetBSD, OpenBSD, Linux, Solaris, OSF/1, and IRIX, with the primary development on FreeBSD and Solaris. pchar is written is C++, primarily using recent versions of gcc, but with some testing also on the SparcWorks C++ compiler. pchar supports IPv4 and, where applicable, IPv6. Recent additions to pchar include: New analysis algorithms based on the least median of squares linear fit method, new probe types (ICMP and ICMPv6), the ability to set the outgoing interface of probes, and a new "tiny traceroute" mode. A number of bugs have been fixed as well; most notably, IPv6 probes will now return (more) correct values for the last hop of a path. The CHANGES file included in the pchar distribution provides more details. The file format used for tracefiles has changed, unfortunately in an incompatable way. Files from pchar-1.2 and earlier are incompatible with pchar-1.3 and vice versa. Conversion between file formats is a possibility, but has not been implemented yet. More information, as well as downloadable source code, can be found at: http://www.employees.org/~bmah/Software/pchar/ Questions and comments are welcome, and can be emailed to or . --==_Exmh_-1752695882P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE6cGwy2MoxcVugUsMRAqVEAJ9dTkOKjJMo+2f+6zx+F23wXWJbPgCgx7vg 7y77IP6RoCKP8KAoscsles0= =tGNK -----END PGP SIGNATURE----- --==_Exmh_-1752695882P-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jan 26 02:44:25 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02339 for ; Fri, 26 Jan 2001 02:44:24 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0Q7h3h20248; Fri, 26 Jan 2001 02:43:03 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f0Q7gSh20204; Fri, 26 Jan 2001 02:42:28 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: , Cc: "Merike Kaeo" , "Matt Zekauskas" , Date: Fri, 26 Jan 2001 02:52:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] thoughts on draft-ietf-ippm-btc-framework-04.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit I did a thorough read of the document, and have one point that might be worth a discussion. In section 1, you define BTC as data_sent / elapsed_time, where data_sent represents the unique "data" bytes transferred. To me, this means BTC is bytes/sec. I believe Treno and cap both report(ed?) in bits/sec. I think the units should explicitly be bits/sec (as you do in section 3.1 for congestion avoidance capacity). Some other nits: In section 3.1, at the end of the first paragraph you mention "(except the single segment Slow-Start that is permitted to follow recovery, as discussed in section 2.3)". It's not section 2.3 of this document; I assume there should be a reference here. In section 2, the first two bulleted points are implicit MUSTs; the final three are explicit MUSTs. The wording in the first two should probably change. Similarly, I think the "should" should be uppercased in the final sentence of section 2. --Matt Z. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jan 26 03:11:31 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02444 for ; Fri, 26 Jan 2001 03:11:30 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0Q893h21259; Fri, 26 Jan 2001 03:09:03 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f0Q88Yh21227 for ; Fri, 26 Jan 2001 03:08:34 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Date: Fri, 26 Jan 2001 03:18:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Minutes & presentations from IETF 49 in San Diego Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The minutes & presentations that were submitted to the proceedings editor are available at http://www.advanced.org/IPPM/Meetings/ietf49/ --Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 09:33:45 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15040 for ; Wed, 31 Jan 2001 09:33:44 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VEW3h21437; Wed, 31 Jan 2001 09:32:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VEVFh21391; Wed, 31 Jan 2001 09:31:16 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id PAA14625; Wed, 31 Jan 2001 15:30:41 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id PAA13045; Wed, 31 Jan 2001 15:30:40 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 31 Jan 2001 15:30:39 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Matthew J Zekauskas , ippm@advanced.org, stanislav shalunov In-Reply-To: <87r933d95d.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] Re: draft-ietf-ippm-owdp: optional fields Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Stanislav, Matt, others, > You said you'd clarify your suggestion about introducing optional > fields and give us a list of desired fields. Could you do that? Two fields are essential, IMHO: * Experimental error. This follows from RFC2330 which indicates that experimental errors for OWD should be reported. Reporting errors becomes even more important when OWD sessions can be set up between different devices operated/manufactured by different organizations. (Typical example, if one sync's his clock from a nearby NTP server, there will be a large statistical error on the time compared to a situation where one has a GPS receiver inside the device. These errors propagate into the result, and should be quoted in order to fully appreciate the final result for a OWD measurement). This number can be expressed using the same format as an NTP timestamp. * Clock status. This word should indicate whether the clock is sychronized or not. This is typically necessary during startup and to detect experimental problems. How one deals with unsynchronized clocks, is up to the application. What we do, is to simply record the clock status when a packet is sent and received, and only in our offline analysis decide if a data-point should be included in the analysis. This is simple and has the advantage that one continues to measure packet losses even if the clock becomes unsynchronized. (We measure packet losses by counting the number of sent and received delay packages). It also saves the hassle of stopping the session and having to restart it in case of short hickup in the GPS receiver. The alternative is to let the OWDP control program check the status of the sending and receiving clock as it is taking data, then, when one of the clocks becomes unsynchronized, stop the session. NTP use 13 bits for this, see /usr/local/include/time.h on your unix box for the definition. In order to accomodate other time keeping mechanisms, we could use 1 word of the send message, and split that into a few bytes to indicate the time keeping method, followed by 13 others if that's NTP or N others for any other timekeeping mechanism. (For example, if one directly reads from the GPS clock, one probably only wants to use points when the receiver actually sees something). Combining these two, I can see something like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp Error | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Clock Type | Clock status bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Packet padding For the unauthenticated packet mode, and similar for the other modes. Henk PS. While reading draft-ietf-owdp-01.txt Page 6: "In unautheniticated mode, KID, ..." but KID is only defined in the next paragraph Page 6: The response message: I think the text should specify here that YES==0 and NO != 0 Page 8/9, creating sessions: I'm not sure how the sender can say anything about the receiver precision during setup of a session. Related to this, precision may vary during a session as clocks tend to drift. Packet length: this does not seem to deal with sessions where one sends packets of varying length. Packets: there should a value for infinite. Page 11/12: Why do the 1st and 3rd message have a specific value in the first 8 bytes, while the second 1 only has 0 or non-zero. Wouldn't it be easier to simply use values for the different messages (for example 1=start, 2=ack, 3=stop, 4=... ). Page 16: Shouldn't we specify that the sequence numbers increase by 1? If not, then why start at 0? Page 18: RFC958 is obsolete and has been replaced by 1305. Page 19: " [RIPE] Ripe Test-Traffic home... " should be " [RIPE] RIPE NCC Test-TRaffic Measurements home..." Page 19: [RIPE-NLUUG] : The URL should be: http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz (This one is guaranteed, the other is filesystem dependend). And the file is now gzip'd ps. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 09:35:12 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15080 for ; Wed, 31 Jan 2001 09:35:11 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VEX1h21501; Wed, 31 Jan 2001 09:33:01 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VEVFh21391; Wed, 31 Jan 2001 09:31:16 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id PAA14625; Wed, 31 Jan 2001 15:30:41 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id PAA13045; Wed, 31 Jan 2001 15:30:40 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 31 Jan 2001 15:30:39 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Matthew J Zekauskas , ippm@advanced.org, stanislav shalunov In-Reply-To: <87r933d95d.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] Re: draft-ietf-ippm-owdp: optional fields Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Stanislav, Matt, others, > You said you'd clarify your suggestion about introducing optional > fields and give us a list of desired fields. Could you do that? Two fields are essential, IMHO: * Experimental error. This follows from RFC2330 which indicates that experimental errors for OWD should be reported. Reporting errors becomes even more important when OWD sessions can be set up between different devices operated/manufactured by different organizations. (Typical example, if one sync's his clock from a nearby NTP server, there will be a large statistical error on the time compared to a situation where one has a GPS receiver inside the device. These errors propagate into the result, and should be quoted in order to fully appreciate the final result for a OWD measurement). This number can be expressed using the same format as an NTP timestamp. * Clock status. This word should indicate whether the clock is sychronized or not. This is typically necessary during startup and to detect experimental problems. How one deals with unsynchronized clocks, is up to the application. What we do, is to simply record the clock status when a packet is sent and received, and only in our offline analysis decide if a data-point should be included in the analysis. This is simple and has the advantage that one continues to measure packet losses even if the clock becomes unsynchronized. (We measure packet losses by counting the number of sent and received delay packages). It also saves the hassle of stopping the session and having to restart it in case of short hickup in the GPS receiver. The alternative is to let the OWDP control program check the status of the sending and receiving clock as it is taking data, then, when one of the clocks becomes unsynchronized, stop the session. NTP use 13 bits for this, see /usr/local/include/time.h on your unix box for the definition. In order to accomodate other time keeping mechanisms, we could use 1 word of the send message, and split that into a few bytes to indicate the time keeping method, followed by 13 others if that's NTP or N others for any other timekeeping mechanism. (For example, if one directly reads from the GPS clock, one probably only wants to use points when the receiver actually sees something). Combining these two, I can see something like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp Error | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Clock Type | Clock status bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Packet padding For the unauthenticated packet mode, and similar for the other modes. Henk PS. While reading draft-ietf-owdp-01.txt Page 6: "In unautheniticated mode, KID, ..." but KID is only defined in the next paragraph Page 6: The response message: I think the text should specify here that YES==0 and NO != 0 Page 8/9, creating sessions: I'm not sure how the sender can say anything about the receiver precision during setup of a session. Related to this, precision may vary during a session as clocks tend to drift. Packet length: this does not seem to deal with sessions where one sends packets of varying length. Packets: there should a value for infinite. Page 11/12: Why do the 1st and 3rd message have a specific value in the first 8 bytes, while the second 1 only has 0 or non-zero. Wouldn't it be easier to simply use values for the different messages (for example 1=start, 2=ack, 3=stop, 4=... ). Page 16: Shouldn't we specify that the sequence numbers increase by 1? If not, then why start at 0? Page 18: RFC958 is obsolete and has been replaced by 1305. Page 19: " [RIPE] Ripe Test-Traffic home... " should be " [RIPE] RIPE NCC Test-TRaffic Measurements home..." Page 19: [RIPE-NLUUG] : The URL should be: http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz (This one is guaranteed, the other is filesystem dependend). And the file is now gzip'd ps. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 09:37:44 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15177 for ; Wed, 31 Jan 2001 09:37:43 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VEb3h21986; Wed, 31 Jan 2001 09:37:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VEaih21940 for ; Wed, 31 Jan 2001 09:36:45 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id PAA16088; Wed, 31 Jan 2001 15:36:45 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id PAA13075; Wed, 31 Jan 2001 15:36:45 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 31 Jan 2001 15:36:45 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: stanislav shalunov cc: ippm@advanced.org In-Reply-To: <8766khjv2z.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] Re: draft-ietf-ippm-owdp: should it be split? Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List On 18 Dec 2000, stanislav shalunov wrote: > There was a suggestion made during physical IPPM WG meeting that the > draft be split into two: one describing OWDP-Control, the other one > describing OWDP-Test. > > What is everybody's opinion on this suggestion? IMHO, split. > NOTE: Split or not split, you *can* use OWDP-Test without OWDP-Control. If OWDP-test can be used without OWDP-control, then two documents documents, with the OWDP-T pointing to OWDP-C as a possibility but not a necessity, sounds a lot more logical than a single document with a remark "yes, we're describing OWDP-C here but you don't need that if you prefer something else". I can see that one can easily extend the OWDP-C protocol to accomodate other measurements, with a program on each measurement node talking OWDP-C to the other nodes and setting up measurement sessions for delay, loss, ... as necessary. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 14:07:27 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23713 for ; Wed, 31 Jan 2001 14:07:26 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VJ6Nh07096; Wed, 31 Jan 2001 14:06:33 -0500 Received: from brixcorp2.brixnet.com ([216.91.233.5]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VJ4mh07020 for ; Wed, 31 Jan 2001 14:05:13 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [216.91.233.5] claimed to be brixcorp2.brixnet.com Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 Jan 2001 14:04:44 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7F2F@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'ippm@advanced.org'" , stanislav shalunov Cc: "'henk@ripe.net'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? Date: Wed, 31 Jan 2001 14:04:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Hello Henk, I do not see the benefit of splitting this one document into two for a couple of reasons: 1) if two different vendors want to support OWDP, then aren't both the control and test needed in order for the vendors to interoperate? If that is true, then shouldn't both halves of this protocol remain in the same document? 2) As you point out, it is quite possible that the control portion of the document is enhanced, but this would lead to confusion because then a vendor would have to specify which control versions and which test versions and which combinations of these they support. I think that pointing to a single document and specifying which revs of the document are supported would be much clearer. Thanks, -Joan > -----Original Message----- > From: Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] > Sent: Wednesday, January 31, 2001 9:37 AM > To: stanislav shalunov > Cc: ippm@advanced.org > Subject: [ippm] Re: draft-ietf-ippm-owdp: should it be split? > > > On 18 Dec 2000, stanislav shalunov wrote: > > > There was a suggestion made during physical IPPM WG meeting that the > > draft be split into two: one describing OWDP-Control, the other one > > describing OWDP-Test. > > > > What is everybody's opinion on this suggestion? > > IMHO, split. > > > NOTE: Split or not split, you *can* use OWDP-Test without > OWDP-Control. > > If OWDP-test can be used without OWDP-control, then two documents > documents, with the OWDP-T pointing to OWDP-C as a > possibility but not a > necessity, sounds a lot more logical than a single document > with a remark > "yes, we're describing OWDP-C here but you don't need that if > you prefer > something else". > > I can see that one can easily extend the OWDP-C protocol to accomodate > other measurements, with a program on each measurement node > talking OWDP-C > to the other nodes and setting up measurement sessions for > delay, loss, > ... as necessary. > > Henk > > -------------------------------------------------------------- > ---------------- > Henk Uijterwaal Email: henk.uijterwaal@ripe.net > RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------- -- As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 14:34:05 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24268 for ; Wed, 31 Jan 2001 14:34:04 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VJW3h09056; Wed, 31 Jan 2001 14:32:03 -0500 Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VJW0h09035 for ; Wed, 31 Jan 2001 14:32:00 -0500 X-Authentication-Warning: mailhost.advanced.org: Host almso1.att.com [192.128.167.69] claimed to be almso1.proxy.att.com Received: from flf960r1.ems.att.com ([135.71.244.37]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f0VJVGO09707; Wed, 31 Jan 2001 14:31:17 -0500 (EST) Received: from njb140bh1.ems.att.com by flf960r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA18936; Wed, 31 Jan 2001 14:29:33 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jan 2001 14:31:16 -0500 Message-ID: From: "Cole, Robert G (Bob), ALSVC" To: ippm@advanced.org, stanislav shalunov Cc: "'henk@ripe.net'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? Date: Wed, 31 Jan 2001 14:31:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Joan, Stanislav, I agree with Henk's request to split the document into two seperate documents. In fact I thought that the discussion at the San Diego meeting was more of an agreement to split rather than a suggestion. But .... There are other activities being worked on that would provide an alternative means to control the OWDP, e.g., draft-kalbfleisch-sspm-00.txt. There may be other methods to achieve OWDP-Control functions as well. Therefore, some vendors may not implement OWDP-Control at all. Because there are alternative methods to achieve the OWDP-Control functions, I think it is much cleaner to work seperate documents. Thanks, Bob > -----Original Message----- > From: Cucchiara, Joan [SMTP:JCucchiara@Brixnet.com] > Sent: Wednesday, January 31, 2001 7:05 PM > To: 'ippm@advanced.org'; stanislav shalunov > Cc: 'henk@ripe.net' > Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? > > > Hello Henk, > > I do not see the benefit of splitting this > one document into two for a couple of reasons: > > 1) if two different vendors want to > support OWDP, then aren't both the control and > test needed in order for the vendors to interoperate? > > If that is true, then shouldn't both halves of this > protocol remain in the same document? > > 2) As you point out, it is quite possible that the control portion > of the document is enhanced, but this would lead > to confusion because then a vendor would > have to specify which control versions and which test versions > and which combinations of these they support. I think > that pointing to a single document and specifying which > revs of the document are supported would be much clearer. > > Thanks, > -Joan > > > -----Original Message----- > > From: Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] > > Sent: Wednesday, January 31, 2001 9:37 AM > > To: stanislav shalunov > > Cc: ippm@advanced.org > > Subject: [ippm] Re: draft-ietf-ippm-owdp: should it be split? > > > > > > On 18 Dec 2000, stanislav shalunov wrote: > > > > > There was a suggestion made during physical IPPM WG meeting that the > > > draft be split into two: one describing OWDP-Control, the other one > > > describing OWDP-Test. > > > > > > What is everybody's opinion on this suggestion? > > > > IMHO, split. > > > > > NOTE: Split or not split, you *can* use OWDP-Test without > > OWDP-Control. > > > > If OWDP-test can be used without OWDP-control, then two documents > > documents, with the OWDP-T pointing to OWDP-C as a > > possibility but not a > > necessity, sounds a lot more logical than a single document > > with a remark > > "yes, we're describing OWDP-C here but you don't need that if > > you prefer > > something else". > > > > I can see that one can easily extend the OWDP-C protocol to accomodate > > other measurements, with a program on each measurement node > > talking OWDP-C > > to the other nodes and setting up measurement sessions for > > delay, loss, > > ... as necessary. > > > > Henk > > > > -------------------------------------------------------------- > > ---------------- > > Henk Uijterwaal Email: henk.uijterwaal@ripe.net > > RIPE Network Coordination Centre WWW: > http://www.ripe.net/home/henk > Singel 258 Phone: +31.20.5354414 > 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------------------- > -- > -- > > As long as you don't tell your friends how I played the hand, > then I won't tell my friends how you defended it. > (Anonymous) > > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 15:34:57 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25309 for ; Wed, 31 Jan 2001 15:34:56 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VKU4h13016; Wed, 31 Jan 2001 15:30:04 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VKTZh12976 for ; Wed, 31 Jan 2001 15:29:36 -0500 Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id VAA23650 for ; Wed, 31 Jan 2001 21:29:36 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id VAA28135 for ; Wed, 31 Jan 2001 21:29:36 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Wed, 31 Jan 2001 21:29:36 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: "'ippm@advanced.org'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7F2F@brixcorp2.brixnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Joan, > 1) if two different vendors want to support OWDP, then aren't both the > control and test needed in order for the vendors to interoperate? No, you need _a_ control mechanism, not necessarily OWDP-C, to set up a measurement session. This has been pointed out by Stanislav and is mentioned in the document. I think it is much cleaner to keep them separate. > 2) As you point out, it is quite possible that the control portion of > the document is enhanced, but this would lead to confusion because > then a vendor would have to specify which control versions and which > test versions and which combinations of these they support. I think > that pointing to a single document and specifying which revs of the > document are supported would be much clearer. If OWDP is specified in this doc and another measurement is introduced, then a vendor for the new measurement will still have to specify which version of OWDP is being used and point to the appropriate version of the OWDP document. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 15:37:21 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25334 for ; Wed, 31 Jan 2001 15:37:21 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VKV1h13082; Wed, 31 Jan 2001 15:31:01 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VKTZh12976 for ; Wed, 31 Jan 2001 15:29:36 -0500 Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id VAA23650 for ; Wed, 31 Jan 2001 21:29:36 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id VAA28135 for ; Wed, 31 Jan 2001 21:29:36 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Wed, 31 Jan 2001 21:29:36 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: "'ippm@advanced.org'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7F2F@brixcorp2.brixnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Joan, > 1) if two different vendors want to support OWDP, then aren't both the > control and test needed in order for the vendors to interoperate? No, you need _a_ control mechanism, not necessarily OWDP-C, to set up a measurement session. This has been pointed out by Stanislav and is mentioned in the document. I think it is much cleaner to keep them separate. > 2) As you point out, it is quite possible that the control portion of > the document is enhanced, but this would lead to confusion because > then a vendor would have to specify which control versions and which > test versions and which combinations of these they support. I think > that pointing to a single document and specifying which revs of the > document are supported would be much clearer. If OWDP is specified in this doc and another measurement is introduced, then a vendor for the new measurement will still have to specify which version of OWDP is being used and point to the appropriate version of the OWDP document. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 16:48:20 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26342 for ; Wed, 31 Jan 2001 16:48:19 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VLl2h18535; Wed, 31 Jan 2001 16:47:02 -0500 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VLjeh18445 for ; Wed, 31 Jan 2001 16:45:40 -0500 Received: from research.telcordia.com (wel2-pc [192.4.8.137]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f0VLjeO21325; Wed, 31 Jan 2001 16:45:41 -0500 (EST) Message-ID: <3A788789.15E766BE@research.telcordia.com> Date: Wed, 31 Jan 2001 16:45:45 -0500 From: "Will E. Leland" Organization: Telcordia Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org CC: stanislav shalunov Subject: Re: [ippm] Re: draft-ietf-ippm-owdp: should it be split? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit I definitely agree with Henk: splitting the documents is the best approach, and is essential for a smooth evolution to using OWDP-Control in a wider context. -- Will _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 16:48:24 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26353 for ; Wed, 31 Jan 2001 16:48:23 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VLk2h18480; Wed, 31 Jan 2001 16:46:02 -0500 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VLjeh18445 for ; Wed, 31 Jan 2001 16:45:40 -0500 Received: from research.telcordia.com (wel2-pc [192.4.8.137]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f0VLjeO21325; Wed, 31 Jan 2001 16:45:41 -0500 (EST) Message-ID: <3A788789.15E766BE@research.telcordia.com> Date: Wed, 31 Jan 2001 16:45:45 -0500 From: "Will E. Leland" Organization: Telcordia Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org CC: stanislav shalunov Subject: Re: [ippm] Re: draft-ietf-ippm-owdp: should it be split? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit I definitely agree with Henk: splitting the documents is the best approach, and is essential for a smooth evolution to using OWDP-Control in a wider context. -- Will _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 16:54:26 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26406 for ; Wed, 31 Jan 2001 16:54:26 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VLr3h19043; Wed, 31 Jan 2001 16:53:03 -0500 Received: from brixcorp2.brixnet.com ([216.91.233.5]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f0VLqth19015 for ; Wed, 31 Jan 2001 16:52:55 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [216.91.233.5] claimed to be brixcorp2.brixnet.com Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 Jan 2001 16:52:56 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7F33@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'ippm@advanced.org'" , stanislav shalunov Cc: "'henk@ripe.net'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? Date: Wed, 31 Jan 2001 16:52:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Hi Bob and Henk, > > Joan, > Stanislav, > > I agree with Henk's request to split the document into two seperate > documents. In fact I thought that the discussion at the San > Diego meeting > was more of an agreement to split rather than a suggestion. But .... > > There are other activities being worked on that would provide > an alternative > means to control the OWDP, e.g., draft-kalbfleisch-sspm-00.txt. > There may be other methods to achieve OWDP-Control functions as well. I agree. In fact, Brix has developed a one-way delay (GPS-based) protocol which is being deployed in our SLA Verification System. > Therefore, some vendors may not implement OWDP-Control at all. I disagree here. The control-plane (at least as far as the draft-ietf-ippm-owdp-01.txt is concerned) sets up parameters for the test-plane. Whether the control information is done via TCP or SNMPConf or COPS+ or something else, it is still necessary to set up the test from sender to receiver. Don't you agree that this has to be done somehow? > > Because there are alternative methods to achieve the OWDP-Control > functions, I think it is much cleaner to work seperate documents. I have trouble accepting this for a standard document which says that its motivation is to have OWDP be as "commonplace" as PING. What other standard has multiple control-planes? I don't know of any. NOTE: this does not mean that other control-plane's cannot be supported, and it does not mean that other control-planes can't be developed, but for a standard, isn't it better to adopt one and work to get that one perfected? I admit I may be missing something here, but how exactly does having multiple control-planes benefit an IETF Standard which is supposed to be the basis for interoperability? Aren't you really saying that in order to interoperate you will need to now support this subset of control planes? Do we really want that? I would agree that the document should definitely have a section discussing how the control-plane needs to be implemented such that it could be replaced (or superseded) by another control-plane, but I'd prefer to adopt one control-plane for the basis of a standard. Thanks, Joan > > Thanks, > Bob > > > > -----Original Message----- > > From: Cucchiara, Joan [SMTP:JCucchiara@Brixnet.com] > > Sent: Wednesday, January 31, 2001 7:05 PM > > To: 'ippm@advanced.org'; stanislav shalunov > > Cc: 'henk@ripe.net' > > Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? > > > > > > Hello Henk, > > > > I do not see the benefit of splitting this > > one document into two for a couple of reasons: > > > > 1) if two different vendors want to > > support OWDP, then aren't both the control and > > test needed in order for the vendors to interoperate? > > > > If that is true, then shouldn't both halves of this > > protocol remain in the same document? > > > > 2) As you point out, it is quite possible that the control portion > > of the document is enhanced, but this would lead > > to confusion because then a vendor would > > have to specify which control versions and which test versions > > and which combinations of these they support. I think > > that pointing to a single document and specifying which > > revs of the document are supported would be much clearer. > > > > Thanks, > > -Joan > > > > > -----Original Message----- > > > From: Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] > > > Sent: Wednesday, January 31, 2001 9:37 AM > > > To: stanislav shalunov > > > Cc: ippm@advanced.org > > > Subject: [ippm] Re: draft-ietf-ippm-owdp: should it be split? > > > > > > > > > On 18 Dec 2000, stanislav shalunov wrote: > > > > > > > There was a suggestion made during physical IPPM WG > meeting that the > > > > draft be split into two: one describing OWDP-Control, > the other one > > > > describing OWDP-Test. > > > > > > > > What is everybody's opinion on this suggestion? > > > > > > IMHO, split. > > > > > > > NOTE: Split or not split, you *can* use OWDP-Test without > > > OWDP-Control. > > > > > > If OWDP-test can be used without OWDP-control, then two documents > > > documents, with the OWDP-T pointing to OWDP-C as a > > > possibility but not a > > > necessity, sounds a lot more logical than a single document > > > with a remark > > > "yes, we're describing OWDP-C here but you don't need that if > > > you prefer > > > something else". > > > > > > I can see that one can easily extend the OWDP-C protocol > to accomodate > > > other measurements, with a program on each measurement node > > > talking OWDP-C > > > to the other nodes and setting up measurement sessions for > > > delay, loss, > > > ... as necessary. > > > > > > Henk > > > > > > -------------------------------------------------------------- > > > ---------------- > > > Henk Uijterwaal Email: henk.uijterwaal@ripe.net > > > RIPE Network Coordination Centre WWW: > > http://www.ripe.net/home/henk > > Singel 258 Phone: +31.20.5354414 > > 1016 AB Amsterdam Fax: +31.20.5354445 > > The Netherlands Mobile: +31.6.55861746 > > > -------------------------------------------------------------- > ------------ > > -- > > -- > > > > As long as you don't tell your friends how I played the hand, > > then I won't tell my friends how you defended it. > > (Anonymous) > > > > > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jan 31 19:29:29 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28785 for ; Wed, 31 Jan 2001 19:29:28 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f110R3h27676; Wed, 31 Jan 2001 19:27:03 -0500 Received: from bacardi.torrentnet.com ([198.78.51.104]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f110QMh27636 for ; Wed, 31 Jan 2001 19:26:23 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [198.78.51.104] claimed to be bacardi.torrentnet.com Received: from torrentnet.com (campari.torrentnet.com [198.78.51.107]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id f110PnL09705 for ; Wed, 31 Jan 2001 19:25:49 -0500 (EST) Message-ID: <3A78AD0D.13214834@torrentnet.com> Date: Wed, 31 Jan 2001 19:25:49 -0500 From: "P.F. Chimento" Organization: Ericsson IP Infrastructure X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Content-Type: multipart/mixed; boundary="------------F74DCDABD70D3C4BA7BC508F" Subject: [ippm] New ipdv draft (attached) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. --------------F74DCDABD70D3C4BA7BC508F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all: I have attached a new ipdv draft which has been modified according to many of the comments that I received on the mailing list in November. I did not submit it as an ID yet, because I wanted to get comments from the mailing list before officially submitting it as a new draft. I hope that it has improved significantly over the old version and I hope that the new formulation of ipdv encompasses the various suggestions made. Just a note on timeliness. The deadline for IDs is 2 March 1700 EST. Please give me your comments well before then. I have to make time to do modifications and getting major comments the day before the deadline won't work. Regards, Phil Chimento -- Phil Chimento Ericsson IPI Phone: 240-314-3597 7301 Calhoun Place chimento@torrentnet.com Rockville, Md. 20855 ----------------------------------------------------- --------------F74DCDABD70D3C4BA7BC508F Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ippm-ipdv-06.txt" Content-Disposition: inline; filename="draft-ietf-ippm-ipdv-06.txt" Content-Transfer-Encoding: 7bit Network Working Group C. Demichelis INTERNET-DRAFT CSELT Expiration Date: August 2001 P. Chimento Ericsson IPI February 2001 IP Packet Delay Variation Metric for IPPM 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft shadow directories can be accessed at http://www.ietf.org/shadow.html This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Demichelis and Chimento Expires August 2001 [Page 1] INTERNET-DRAFT IP Packet Delay Variation February 2001 2. Abstract This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in the One-Way- Delay of selected packets. This difference in delay is called "IP Packet Delay variation." The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this draft. 3. Introduction This memo is based on "A One-Way-Delay metric for IPPM", RFC 2679 [2]. Part of the text in this memo is taken directly from that document. This memo defines a metric for variation in delay of packets that flow from one host to another one through an IP path. This quantity is sometimes called "jitter". This term, however, causes confusion because it is used in different ways by different groups of people. "Jitter" commonly has two meanings: The first meaning is the variation of a signal with respect to some clock signal, where the arrival time of the signal is expected to coincide with the arrival of the clock signal. The second meaning has to do with the variation of a metric (e.g. delay) with respect to some reference metric (e.g. average delay or minimum delay). The first meaning is used with reference to synchronous signals and might be used to measure the quality of circuit emulation, for example. There is also a metric called "wander" used in this context. The second meaning is frequently used by computer scientists and frequently (but not always) refers to variation in delay. In this document we will avoid the term "jitter" whenever possible and stick to delay variation which is more precise. Demichelis and Chimento Expires August 2001 [Page 2] INTERNET-DRAFT IP Packet Delay Variation February 2001 3.1. Definition A definition of the IP Packet Delay Variation (ipdv) can be given for packets inside a stream of packets. The IP Packet Delay Variation (ipdv) of a pair of packets within a stream of packets is defined for a selected pair of packets in the stream going from measurement point MP1 to measurement point MP2 is the difference between the one-way-delay of the first of the selected packets and the one-way-delay of the second of the selected packets. 3.2. Motivation One important use of delay variation is the sizing of playout buffers for applications requiring the regular delivery of packets (for example, voice or video playout). What is normally important in this case is the maximum delay variation, which is used to size playout buffers for such applications [6]. Other uses of a delay variation metric are, for example, to determine the dynamics of queues within a network (or router) where the changes in delay variation can be linked to changes in the queue length process at a given link or a combination of links. In addition, this type of metric is particularly robust with respect differences and variations of the clocks of the two hosts. This allows the use of the metric even if the two hosts that support the measurement points are not synchronized. In the latter case indications of reciprocal skew of the clocks can be derived from the measurement and corrections are possible. The related precision is often comparable with the one that can be achieved with synchronized clocks, being of the same order of magnitude of synchronization errors. This will be discussed below. The scope of this document is to provide a way to measure the ipdv delivered on a path. Our goal is to provide a metric which can be parameterized so that it can be used for various purposes. Any report of the metric MUST include all the parameters associated with it so that the conditions and meaning of the metric can be determined exactly. We specifically do not specify particular values of the metrics that IP networks must meet. The flexibility of the metric can be viewed as a disadvantage but there are some arguments for making it flexible. First, though there are some uses of ipdv mentioned above, to some degree the uses of ipdv are still a research topic and some room should be left for experimentation. Secondly, there are different views in the community of what precisely the definition should be (e.g. [7],[8],[9]). The Demichelis and Chimento Expires August 2001 [Page 3] INTERNET-DRAFT IP Packet Delay Variation February 2001 idea here is to parameterize the definition, rather than write a different draft for each proposed definition. As long as all the parameters are reported, it will be clear what is meant by a particular use of ipdv. All the remarks in the draft hold, no matter which parameters are chosen. 3.3. General Issues Regarding Time Everything contained in the Section 2.2. of [2] applies also in this case. To summarize: As in [1] we define "skew" as the first derivative of the offset of a clock with respect to "true time" and define "drift" as the second derivative of the offset of a clock with respect to "true time". From there, we can construct "relative skew" and "relative drift" for two clocks C1 and C2 with respect to one another. These are natural extensions of the basic framework definitions of these quantities: + Relative offset = difference in clock times + Relative skew = first derivative of the difference in clock times + Relative drift = second derivative of the difference in clock times NOTE: The drift of a clock, as it is above defined over a long period must have an average value that tends to zero while the period becomes large since the frequency of the clock has a finite (and small) range. In order to underline the order of magnitude of this effect,it is considered that the maximum range of drift for commercial crystals is about 50 part per million (ppm). Since it is mainly connected with variations in operating temperature (from 0 to 70 degrees Celsius), it is expected that a host will have a nearly constant temperature during its operation period, and variations in temperature, even if quick, could be less than one Celsius per second, and range in the order of few degrees. The total range of the drift is usually related to variations from 0 to 70 Celsius. These are important points for evaluation of precision of ipdv measurements, as will be seen below. Demichelis and Chimento Expires August 2001 [Page 4] INTERNET-DRAFT IP Packet Delay Variation February 2001 4. A singleton definition of a One-way ipdv metric The purpose of the singleton metric is to define what a single instance of an ipdv measurement is. Note that it can only be statistically significant in combination with other instances. It is not intended to be meaningful as a singleton, in the sense of being able to draw inferences from it. This definition makes use of the corresponding definition of type-P- One-Way-Delay metric [2]. This section makes use of those parts of the One-Way-Delay Draft that directly apply to the One-Way-ipdv metric, or makes direct references to that Draft. 4.1. Metric name Type-P-One-way-ipdv 4.2. Metric parameters + Src, the IP address of a host + Dst, the IP address of a host + T1, a time + T2, a time + L, a packet length in bits. The packets of a Type P packet stream from which the singleton ipdv metric is taken MUST all be of the same length. + F, a selection function defining unambiguously the two packets from the stream selected for the metric. + I1,I2, times which mark that beginning and ending of the interval in which the packet stream from which the singleton measurement is taken occurs. + P, the specification of the packet type, over and above the source and destination addresses Demichelis and Chimento Expires August 2001 [Page 5] INTERNET-DRAFT IP Packet Delay Variation February 2001 4.3. Metric unit The value of a Type-P-One-way-ipdv is either a real number of seconds (positive, zero or negative) or an undefined number of seconds. 4.4. Definition We are given a Type P packet stream and I1 and I2 such that the first Type P packet to pass measurement point MP2 after I1 is given index 0 and the last Type P packet to pass measurement point MP2 before I2 is given the highest index number. Type-P-One-way-ipdv is defined for two packets from Src to Dst selected by the selection function F, as the difference between the value of the type-P-One-way- delay from Src to Dst at T2 and the value of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the wire-time at which Scr sent the first bit of the first packet, and T2 is the wire-time at which Src sent the first bit of the second packet. This metric is derived from the One-Way-Delay metric. T2 denote the wire times of the packets sent from Src to Dst. Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to Dst at T1, T2 is ddT" means that Src sent two packets, the first at wire-time T1 (first bit), and the second at wire-time T2 (first bit) and the packets were received by Dst at wire-time dT1+T1 (last bit of the first packet), and at wire-time dT2+T2 (last bit of the second packet), and that dT2-dT1=ddT. "The type-P-one-way-ipdv from Src to Dst at T1,T2 is undefined" means that Src sent the first bit of a packet at T1 and the first bit of a second packet at T2 and that Dst did not receive one or both packets. 4.5. Discussion This metric definition depends on a stream of Type-P-One-Way-Delay packets that have been measured. In general this can be a stream of two or more packets, delimited by the interval endpoints I1 and I2. There must be a stream of at least two packets in order for a singleton ipdv measurement to take place. The purpose of the selection function is to specify exactly which two packets from the stream are to be used for the singleton measurement. Note that the selection function may involve observing the one-way-delay of all the Type P packets of the stream in the specified interval. Examples of a selection function are: Demichelis and Chimento Expires August 2001 [Page 6] INTERNET-DRAFT IP Packet Delay Variation February 2001 + Consecutive Type-P packets within the specified interval + Type-P packets with specified indices within the specified interval + Type-P packets with the min and max one-way-delays within the specified interval + Type-P packets with specified indices from the set of all defined (i.e. non-infinite) one-way-delays Type-P packets within the specified interval. The following practical issues have to be considered: + Being a differential measurement, this metric is less sensitive to clock synchronization problems. This issue will be more carefully examined in section 7 of this memo. It is pointed out that, if the relative clock conditions change in time, the accuracy of the measurement will depend on the time interval I2-I1 and the magnitude of possible errors will be discussed below. + A given methodology will have to include a way to determine whether a delay value is infinite or whether it is merely very large (and the packet is yet to arrive at Dst). As noted by Mahdavi and Paxson, simple upper bounds (such as the 255 seconds theoretical upper bound on the lifetimes of IP packets [Postel: RFC 791]) could be used, but good engineering, including an understanding of packet lifetimes, will be needed in practice. Comment: Note that, for many applications of these metrics, the harm in treating a large delay as infinite might be zero or very small. A TCP data packet, for example, that arrives only after several multiples of the RTT may as well have been lost. + As with other 'type-P' metrics, the value of the metric may depend on such properties of the packet as protocol,(UDP or TCP) port number, size, and arrangement for special treatment (as with IP precedence or with RSVP). + If the packet is duplicated along the path (or paths!) so that multiple non-corrupt copies arrive at the destination, then the packet is counted as received, and the first copy to arrive determines the packet's One-Way-Delay. + If the packet is fragmented and if, for whatever reason, reassembly does not occur, then the packet will be deemed lost. Demichelis and Chimento Expires August 2001 [Page 7] INTERNET-DRAFT IP Packet Delay Variation February 2001 It is assumed that the Type-P packet stream is generated according to the Poisson sampling methodology described in [1]. 4.6. Methodologies As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). The measurement methodology described in this section asssumes the measurement and determination of ipdv in real-time as part of an active measurement. Note that this can equally well be done a posteriori, i.e. after the one-way-delay measurement is completed. Generally, for a given Type-P, the methodology would proceed as follows: + The need of synchronized clocks for Src and Dst will be discussed later. Here a methodology is supposed that is based on synchronized clocks. + After time I1, start. At the Src host, select Src and Dst IP addresses, and form test packets of Type-P with these addresses according to a given technique (e.g. the Poisson sampling technique). Any 'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is lower than it would otherwise be due to compression techniques along the path. + At the Dst host, arrange to receive the packets. + At the Src host, place a timestamp in the Type-P packet, and send it towards Dst. + If the packet arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of One-Way-Delay can be computed. + If the packet meets the selection function criterion for the first packet, record this first delay value. Otherwise, continue generating the Type-P packet stream as above until the criterion is met or I2, whichever comes first. + At the Src host, packets continue to be generated according to the given methodology. The Src host places a timestamp in the Type-P packet, and send it towards Dst. Demichelis and Chimento Expires August 2001 [Page 8] INTERNET-DRAFT IP Packet Delay Variation February 2001 + If the packet arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of One-Way-Delay can be computed. + If the packet meets the criterion for the second packet for the second packet, then by subtracting the second value of One-Way- Delay from the first value the ipdv value of the pair of packets is obtained. Otherwise, packets continue to be generated until the criterion for the second packet is fulfilled or I2, whichever comes first. + If one or both packets fail to arrive within a reasonable period of time, the ipdv is taken to be undefined. 4.7. Errors and Uncertainties In the singleton metric of ipdv, factors that affect the measurement are the same as those affecting the One-Way-Delay measurement, even if, in this case, the influence is different. The Framework document [1] provides general guidance on this point, but we note here the following specifics related to delay metrics: + Errors/uncertainties due to uncertainties in the clocks of the Src and Dst hosts. + Errors/uncertainties due to the difference between 'wire time' and 'host time'. Each of these errors is discussed in more detail in the following paragraphs. 4.7.1. Errors/Uncertainties related to Clocks If, as a first approximation, the error that affects the first measurement of One-Way-Delay were the same as the one affecting the second measurement, they will cancel each other when calculating ipdv. The residual error related to clocks is the difference of the errors that are supposed to change from time T1, at which the first measurement is performed, to time T2 at which the second measurement is performed. Synchronization, skew, accuracy and resolution are here considered with the following notes: + Errors in synchronization between source and destination clocks contribute to errors in both of the delay measurements required for calculating ipdv. Demichelis and Chimento Expires August 2001 [Page 9] INTERNET-DRAFT IP Packet Delay Variation February 2001 + The effect of drift and skew errors on ipdv measurements can be quantified as follows: Suppose that the skew and drift functions are known. Assume first that the skew function is linear in time. Clock offset if then also a function of time and the error evolves as e(t) = K*t + O, where K is a constant and O is the offset at time 0. In this case, the error added to the subtraction two different time stamps (t2 > t1) is e(t2)-e(t1) = K*(t2 - t1) which will be added to the time difference (t2 - t1). If the drift cannot be ignored, but we assume that the drift is a linear function of time, then the skew is given by s(t) = M*(t**2) + N*t + S0, where M and N are constants and S0 is the skew at time 0. The error added by the variable skew/drift process in this case becomes e(t) = O + s(t) and the error added to the difference in time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}. It is the claim here (see remarks in section 3.3) that the effects of skew are rather small over the time scales that we are discussing here, since temperature variations in a system tend to be slow relative to packet inter-transmission times and the range of drift is so small. + As far as accuracy and resolution are concerned, what is noted in the one-way-delay document [2] in section 3.7.1, applies also in this case, with the further consideration, about resolution, that in this case the uncertainty introduced is two times the one of a single delay measurement. Errors introduced by these effects are often larger than the ones introduced by the drift. 4.7.2. Errors/uncertainties related to Wire-time vs Host-time The content of sec. 3.7.2 of [2] applies also in this case, with the following further consideration: The difference between Host-time and Wire-time can be in general decomposed into two components, of which one is constant and the other is variable. Only the variable components will produce measurement errors, while the constant one will be canceled while calculating ipdv. However, in most cases, the fixed and variable components are not known exactly. Demichelis and Chimento Expires August 2001 [Page 10] INTERNET-DRAFT IP Packet Delay Variation February 2001 5. Definitions for Samples of One-way ipdv The goal of the sample definition is to make it possible to compute the statistics of sequences of ipdv measurements. The singleton definition is applied to a stream of test packets generated according to a pseudo-random Poisson process with average arrival rate lambda. If necessary, the interval in which the stream is generated can be divided into sub-intervals on which the singleton definition of ipdv can be applied. The result of this is a sequence of ipdv measurements that can be analyzed by various statistical procedures. Starting from the definition of the singleton metric of one-way ipdv, we define a sample of such singletons. In the following, the two packets needed for a singleton measurement will be called a "pair". 5.1. Metric name Type-P-One-way-ipdv-stream 5.2. Parameters + Src, the IP address of a host + Dst, the IP address of a host + T0, a time + Tf, a time + lambda, a rate in reciprocal seconds + L, a packet length in bits. The packets of a Type P packet stream from which the sample ipdv metric is taken MUST all be of the same length. + F, a selection function defining unambiguously the packets from the stream selected for the metric. + I(i),I(i+1), i >=0, pairs of times which mark the beginning and ending of the intervals in which the packet stream from which the measurement is taken occurs. I(0) >= T0 and assuming that n is the largest index, I(n) <= Tf. + P, the specification of the packet type, over and above the source and destination addresses Demichelis and Chimento Expires August 2001 [Page 11] INTERNET-DRAFT IP Packet Delay Variation February 2001 5.3. Metric Units: A sequence of triples whose elements are: + T1, T2,times + dT a real number or an undefined number of seconds 5.4. Definition A pseudo-random Poisson process is defined such that it begins at or before T0, with average arrival rate lambda, and ends at or after Tf. Those time values T(i) greater than or equal to T0 and less than or equal to Tf are then selected for packet generation times. Each packet falling within one of the sub-intervals I(i), I(i+1) is tested to determine whether it meets the criteria of the selection function F as the first or second of a packet pair needed to compute ipdv. The sub-intervals can be defined such that a sufficient number of singleton samples for valid statistical estimates can be obtained. The triples defined above consist of the transmission times of the first and second packets of each singleton included in the sample, and the ipdv in seconds. 5.5. Discussion Note first that, since a pseudo-random number sequence is employed, the sequence of times, and hence the value of the sample, is not fully specified. Pseudo-random number generators of good quality will be needed to achieve the desired qualities. The sample is defined in terms of a Poisson process both to avoid the effects of self-synchronization and also capture a sample that is statistically as unbiased as possible. There is, of course, no claim that real Internet traffic arrives according to a Poisson arrival process. The sample metric can best be explained with a couple of examples: For the first example, assume that the selection function specifies the "non-infinite" max and min one-way-delays over each sub-interval. We can define contiguous sub-intervals of fixed specifiec length and produce a sequence each of whose elements is the triple which is collected for each sub-interval. A second example is the selection function that specifies packets whose Demichelis and Chimento Expires August 2001 [Page 12] INTERNET-DRAFT IP Packet Delay Variation February 2001 indices (sequence numbers) are just the integers below a certain bound. In this case, the sub-intervals are defined by the transmission times of the generated packets and the sequence produced is just where D(i) denotes the one-way delay of the ith packet of a stream. This definition of the sample metric encompasses both the definition proposed in [9] and the one proposed in [9]. 5.6. Methodology Since packets can be lost or duplicated or can arrive in a different order than the order sent, in order to recognize the pairs of test packets, they should be marked with a sequence number. For duplicated packets only the first received copy should be considered. Otherwise, the methodology is the same as for the singleton measurement, with the exception that the singleton measurement is repeated a number of times. 5.7. Errors and uncertainties The same considerations apply that have been made about the singleton metric. Additional error can be introduced by the pseudo-random Poisson process as discussed in [2]. Further considerations will be given in section 7. 6. Statistics for One-way-ipdv Some statistics are suggested which can provide useful information in analyzing the behavior of the packets flowing from Src to Dst. The statistics are assumed to be computed from an ipdv sample of reasonable size. The purpose is not to define every possible statistic for ipdv, but ones which have been proposed or used. 6.1. Lost Packets and ipdv statistics The treatment of lost packets as having "infinite" or "undefined" delay complicates the derivation of statistics for ipdv. Specifically, when packets in the measurement sequence are lost, simple statistics such as sample mean cannot be computed. One possible approach to handling this problem is to reduce the event space by conditioning. That is, we consider conditional statistics; Demichelis and Chimento Expires August 2001 [Page 13] INTERNET-DRAFT IP Packet Delay Variation February 2001 namely we estimate the mean ipdv (or other derivative statistic) conditioned on the event that selected packet pairs arrive at the destination (within the given timeout). While this itself is not without problems (what happens, for example, when every other packet is lost), it offers a way to make some (valid) statements about ipdv, at the same time avoiding events with undefined outcomes. In practical terms, what this means is throwing out the samples where one or both of the selected packets has an undefined delay. The sample space is reduced (conditioned) and we can compute the usual statistics, understanding that formally they are conditional. 6.2. Distribution of One-way-ipdv values The one-way-ipdv values are limited by virtue of the fact that there are upper and lower bounds on the one-way-delay values. Specifically, one-way-delay is upper bounded by the value chosen as the maximum beyond which a packet is counted as lost. It is lower bounded by propagation, transmission and nodal transit delays assuming that there are no queues or variable nodal delays in the path. Denote the upper bound of one-way-delay by U and the lower bound by L and we see that one-way-ipdv can only take on values in the (open) interval (L- U, U-L). In any finite interval, the one-way-delay can vary monotonically (non-increasing or non-decreasing) or of course it can vary in both directions in the interval, within the limits of the half-open interval [L,U). Accordingly, within that interval, the one-way-ipdv values can be positive, negative, or a mixture (including 0). Since the range of values is limited, the one-way-ipdv cannot increase or decrease indefinitely. Suppose, for example, that the ipdv has a positive 'run' (i.e. a long sequence of positive values). At some point in this 'run', the positive values must approach 0 (or become negative) if the one-way-delay remains finite. Otherwise, the one-way-delay bounds would be violated. If such a run were to continue infinitely long, the sample mean (assuming no packets are lost) would approach 0 (because the one-way-ipdv values must approach 0). Note, however, that this says nothing about the shape of the distribution, or whether it is symmetric. Note further that over significant intervals, depending on the width of the interval [L,U), that the sample mean one-way-ipdv could be positive, negative or 0. There are basically two ways to represent the distribution of values of an ipdv sample: an empirical pdf and an empirical cdf. The empirical pdf is most often represented as a histogram where the range of values of an ipdv sample is divided into bins of a given Demichelis and Chimento Expires August 2001 [Page 14] INTERNET-DRAFT IP Packet Delay Variation February 2001 length and each bin contains the proportion of values falling between the two limits of the bin. (Sometimes instead the number of values falling between the two limits is used). The empirical cdf is simply the proportion of ipdv sample values less than a given value, for a sequence of values selected from the range of ipdv values. 6.3. Type-P-One-way-ipdv-percentile Given a Type-P One-Way-ipdv sample and a percent X between 0% and 100%, the Xth percentile of all ipdv values in the sample. The 50th percentile is the median. 6.4. Type-P-One-way-ipdv-inverse-percentile Given a Type-P-One-way-ipdv sample and a given value Y, the percent of ipdv sample values less than or equal to Y. 6.5. Type-P-One-way-ipdv-jitter Although the use of the term "jitter" is deprecated, we use it here following the authors in [7]. In that document, the selection function specifies that consecutive packets of the Type-P stream are to be selected for the packet pairs used in ipdv computation. They then take the absolute value of the ipdv values in the sample. The authors in [7] use the resulting sample to compare the behavior of two different scheduling algorithms. 6.6. Type-P-One-way-ipdv-jitter In this case, the selection function used in collecting the Type-P- One-Way-ipdv sample specifies that the first packet of each pair to be the packet with the maximum Type-P-One-Way-Delay in each sub- interval and the second packet of each pair to be the packet with the minimum Type-P-One-Way-Delay in each sub-interval. The resulting sequence of values is the peak-to-peak delay variation in each sub- interval of the measurement interval. Demichelis and Chimento Expires August 2001 [Page 15] INTERNET-DRAFT IP Packet Delay Variation February 2001 7. Discussion of clock synchronization This section gives some considerations about the need of having synchronized clocks at the source and destination. These considerations are given as a basis for discussion and they require further investigation. 7.1. Effects of synchronization errors Clock errors can be generated by two processes: the relative drift and the relative skew of two given clocks. We should note that drift is physically limited and so the total relative skew of two clocks can vary between an upper and a lower bound. Suppose then that we have a measurement between two systems such that the clocks in the source and destination systems have at time 0 a relative skew of s(0) and after a measurement interval T have skew s(T). We assume that the two clocks have an initial offset of O (that is letter O). Now suppose that the packets travel from source to destination in constant time, in which case the ipdv is zero and the difference in the timestamps of the two clocks is actually just the relative offset of the clocks. Suppose further that at the beginning of the measurement interval the ipdv value is calculated from a packet pair and at the end of the measurement interval another ipdv value is calculated from another packet pair. Assume that the time interval covered by the first measurement is t1 and that covered by the second measurement is t2. Then ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T assuming that the change is skew is linear in time. In most practical cases, it is claimed that the drift will be close to zero in which case the second (correction) term in the above equations disappears. Note that in the above discussion, other errors, including the differences between host time and wire time, and externally-caused clock discontinuities (e.g. clock corrections) were ignored. Under these assumptions the maximum clock errors will be due to the maximum relative skew acting on the largest interval between packets. Demichelis and Chimento Expires August 2001 [Page 16] INTERNET-DRAFT IP Packet Delay Variation February 2001 7.2. Estimating the skew of unsynchronized clocks If the skew is linear (that is, if s(t) = S * t for constant S), the error in ipdv values will depend on the time between the packets used in calculating the value. If ti is the time between the packet pair, then let Ti denote the sample mean time between packets and the average skew is s(Ti) = S * Ti. In the event that the delays are constant, the skew parameter S can be estimated from the estimate Ti of the time between packets and the sample mean ipdv value. Under these assumptions, the ipdv values can be corrected by subtracting the estimated S * ti. We observe that the displacement due to the skew does not change the shape of the distribution, and, for example the Standard Deviation remains the same. What introduces a distortion is the effect of the drift, also when the mean value of this effect is zero at the end of the measurement. The value of this distortion is limited to the effect of the total skew variation on the emission interval. 8. Security Considerations The one-way-ipdv metric has the same security properties as the one- way-delay metric [2]. The packets contain no user information, and so privacy of user data is not a concern. It is still possible that there could be an attempt at a denial of service attack by sending many measurement packets into the network; there could also be attempts to disrupt measurements by diverting packets or corrupting them. In general, legitimate measurements must have their parameters selected carefully in order to avoid interfering with normal traffic in the network. Such measurements should also be authorized and authenticated in some way so that attacks can be identified and intercepted. 9. Acknowledgements This major revision of the draft resulted from e-mail discussions with and suggestions from Mike Pierce, Ruediger Geib, Glenn Grotefeld, and Al Morton. For previous revisions of this document, discussions with Ruediger Geib, Matt Zekaukas and Andy Scherer were very helpful. Demichelis and Chimento Expires August 2001 [Page 17] INTERNET-DRAFT IP Packet Delay Variation February 2001 10. References [1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP Performance Metrics", RFC 2330 Feb. 1998 [2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC 2679, September 1999 [3] ITU-T Recommendation Y.1540 (formerly numbered I.380) "Internet Protocol Data Communication Service - IP Packet Transfer and Availability Performance Parameters", February 1999 [4] Demichelis, Carlo - "Packet Delay Variation Comparison between ITU-T and IETF Draft Definitions" November 2000 (in the IPPM mail archives) [5] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer Performance" [6] S. Keshav - "An Engineering Approach to Computer Networking", Addison-Wesley 1997, ISBN 0-201-63442-2 [7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding PHB", RFC 2598, June 1999 [8] ITU-T Draft Recommendation Y.1541 - "Internet Protocol Communication Service - IP Performance and Availability Objectives and Allocations", April 2000 [9] Demichelis, Carlo - "Improvement of the Instantaneous Packet Delay Variation (IPDV) Concept and Applications", World Telecommunications Congress 2000, 7-12 May 2000 11. Authors' Addresses Carlo Demichelis CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A Via G. Reiss Romoli 274 10148 - TORINO Italy Phone +39 11 228 5057 Fax. +39 11 228 5069 Demichelis and Chimento Expires August 2001 [Page 18] INTERNET-DRAFT IP Packet Delay Variation February 2001 Philip Chimento Ericsson IPI 7301 Calhoun Place Rockville, Maryland 20855 USA Phone +1-240-314-3597 Expiration date: August 2001 Demichelis and Chimento Expires August 2001 [Page 19] --------------F74DCDABD70D3C4BA7BC508F-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm