From ippm-admin@advanced.org Mon Jul 1 06:36:43 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21751 for ; Mon, 1 Jul 2002 06:36:43 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g61Aa4TY009351; Mon, 1 Jul 2002 06:36:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g61AZqTY009163 for ; Mon, 1 Jul 2002 06:35:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21307; Mon, 1 Jul 2002 06:35:04 -0400 (EDT) Message-Id: <200207011035.GAA21307@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 01 Jul 2002 06:35:04 -0400 Subject: [ippm] I-D ACTION:draft-ietf-ippm-owmetric-as-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk 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 : One-Way Metric Applicability Statement Author(s) : H. Uijterwaal, M. Kaeo Filename : draft-ietf-ippm-owmetric-as-00.txt Pages : 7 Date : 28-Jun-02 Active traffic measurements are starting to become more widely used to ascertain network performance characteristics. All active measurement systems have the capability to measure one-way delay and one-way loss metrics, as defined in RFC2679 [1] A One- way Delay Metric for IPPM and RFC 2680 [2] A One-way Packet Loss Metric for IPPM, respectively. To ensure that the resulting numbers have some meaning, we attempt to characterize how the measurements are taken and what would ensure that the end numbers are indeed meaningful. This document describes an applicability statement (formerly known as best current practices) for measuring the one-way delay and one-way loss metrics in operational networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owmetric-as-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-owmetric-as-00.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-owmetric-as-00.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: <20020628141923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-owmetric-as-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-owmetric-as-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628141923.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From netbackup-admin@advanced.org Mon Jul 1 06:51:26 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24025 for ; Mon, 1 Jul 2002 06:51:25 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g61AqDTY012621 for ; Mon, 1 Jul 2002 06:52:13 -0400 Date: Mon, 1 Jul 2002 06:52:13 -0400 Message-Id: <200207011052.g61AqDTY012621@mailhost.advanced.org> Subject: advanced.org mailing list memberships reminder From: mailman-owner@advanced.org To: ippm-archive@ietf.org X-No-Archive: yes Sender: netbackup-admin@advanced.org Errors-To: netbackup-admin@advanced.org X-BeenThere: netbackup@mailhost.advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Netbackup logs This is a reminder, sent out once a month, about your advanced.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@advanced.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@advanced.org. Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@advanced.org jTPE http://mailhost.advanced.org/mailman/options/ippm/ippm-archive@lists.ietf.org From ippm-admin@advanced.org Wed Jul 3 06:29:42 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03605 for ; Wed, 3 Jul 2002 06:29:41 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g63AT3TY001414; Wed, 3 Jul 2002 06:29:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g63ASWTY001222 for ; Wed, 3 Jul 2002 06:28:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03251; Wed, 3 Jul 2002 06:27:42 -0400 (EDT) Message-Id: <200207031027.GAA03251@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Jul 2002 06:27:42 -0400 Subject: [ippm] I-D ACTION:draft-ietf-ippm-owdp-reqs-02.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk 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 : A One-way Active Measurement Protocol Requirements Author(s) : S. Shalunov, B. Teitelbaum Filename : draft-ietf-ippm-owdp-reqs-02.txt Pages : 10 Date : 02-Jul-02 With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-reqs-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-owdp-reqs-02.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-owdp-reqs-02.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: <20020702150937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-owdp-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-owdp-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702150937.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 3 14:34:50 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27192 for ; Wed, 3 Jul 2002 14:34:50 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g63GZ4TY009624; Wed, 3 Jul 2002 12:35:04 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g63GYXTY009434 for ; Wed, 3 Jul 2002 12:34:33 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id D3DB05ECF1 for ; Wed, 3 Jul 2002 12:34:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 286525EC56 for ; Wed, 3 Jul 2002 12:34:33 -0400 (EDT) To: ippm@advanced.org References: <200207011035.GAA21307@ietf.org> From: stanislav shalunov Date: 03 Jul 2002 12:35:04 -0400 In-Reply-To: <200207011035.GAA21307@ietf.org> Message-ID: <8765zw4vnr.fsf@cain.internet2.edu> Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.4 Subject: [ippm] Re: draft-ietf-ippm-owmetric-as-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List I have a few nit-picks about the document: Section 3.4 `Test duration' makes an assertion about desirability of continuous monitoring that on the surface is obvious but in fact involves a subtle trade-off with ability to differentiate between losses and measurement device failures when periods of extended losses are involved. Section 3.5 `Data volumes' appears to fail to explain why the measurement traffic needs to be low volume. In fact, for some measurements it needs to be low and for some it must be comparable with link capacity. It should be made clear that specific metrics (such as one-way loss and delay) and specific methodology is discussed. Further, the number 3% is pulled out of the hat: 300Mb/s of active delay and loss measurement traffic on a 10Gb/s network is surely excessive, isn't it? Section 5.0 `Reporting the IPDV metric' says that `the distribution generally is not Gaussian and the sigma is not well defined'. Many non-Gaussian distributions happen to have finite standard deviation. Reporting standard deviation makes sense for more than Gaussian distribution, too. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Letters in this message are closer than they appear. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jul 4 04:43:58 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11667 for ; Thu, 4 Jul 2002 04:43:57 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g648f3TY020185; Thu, 4 Jul 2002 04:41:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g648eXTY020004 for ; Thu, 4 Jul 2002 04:40:33 -0400 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id g648eWC18139; Thu, 4 Jul 2002 10:40:32 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.11.6/8.11.6) with ESMTP id g648eVc23008; Thu, 4 Jul 2002 10:40:32 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Thu, 4 Jul 2002 10:40:31 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: stanislav shalunov cc: ippm@advanced.org Subject: Re: [ippm] Re: draft-ietf-ippm-owmetric-as-00.txt In-Reply-To: <8765zw4vnr.fsf@cain.internet2.edu> 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 List-Id: IETF IP Performance Metrics Working Group List Hi Stas, > Section 3.4 `Test duration' makes an assertion about desirability of > continuous monitoring that on the surface is obvious but in fact > involves a subtle trade-off with ability to differentiate between > losses and measurement device failures when periods of extended losses > are involved. I'm not quite sure if I understand this comment. > Section 3.5 `Data volumes' appears to fail to explain why the > measurement traffic needs to be low volume. In fact, for some > measurements it needs to be low and for some it must be comparable > with link capacity. Such as? > It should be made clear that specific metrics (such as one-way loss and > delay) and specific methodology is discussed. Further, the number 3% is > pulled out of the hat: 300Mb/s of active delay and loss measurement > traffic on a 10Gb/s network is surely excessive, isn't it? Yes and no. The 3% number comes from discussions with providers, who typically claim that "using a few percent" of the total capacity to monitor the performance of their equipment. If you have a better number, then I'd like to hear it. Also see section 3.1, if we send 3% of 10 Gb/s measurement traffic, will we see all interesting variations in traffic? > Section 5.0 `Reporting the IPDV metric' says that `the distribution > generally is not Gaussian and the sigma is not well defined'. Many > non-Gaussian distributions happen to have finite standard deviation. > Reporting standard deviation makes sense for more than Gaussian > distribution, too. Yes. However, look in our latest PAM paper (or wait until my Yokohama presentation) to see some of the typical IPDV distributions. Reporting sigma for these distributions simply doesn't make sense. 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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk@ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 5 06:35:01 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17192 for ; Fri, 5 Jul 2002 06:35:00 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65AY3TY024757; Fri, 5 Jul 2002 06:34:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65AXrTY024563 for ; Fri, 5 Jul 2002 06:33:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16882; Fri, 5 Jul 2002 06:33:03 -0400 (EDT) Message-Id: <200207051033.GAA16882@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 05 Jul 2002 06:33:03 -0400 Subject: [ippm] I-D ACTION:draft-ietf-ippm-owdp-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 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 : A One-way Active Measurement Protocol Author(s) : S. Shalunov, B. Teitelbaum, M. Zekauskas Filename : draft-ietf-ippm-owdp-04.txt Pages : 23 Date : 03-Jul-02 The IETF IP Performance Metrics (IPPM) working group has proposed draft standard metrics for one-way packet delay [RFC2679] and loss [RFC 2680] across Internet paths. Although there are now several measurement platforms that implement collection of these metrics [SURVEYOR], [RIPE], there is not currently a standard that would permit initiation of test streams or exchange of packets to collect singleton metrics in an interoperable manner. With the increasingly wide availability of affordable global positioning system (GPS) and CDMA based time sources, hosts increasingly have available to them very accurate time sources--either directly or through their proximity to NTP primary (stratum 1) time servers. By standardizing a technique for collecting IPPM one-way active measurements, we hope to create an environment where IPPM metrics may be collected across a far broader mesh of Internet paths than is currently possible. One particularly compelling vision is of widespread deployment of open OWAMP servers that would make measurement of one-way delay as commonplace as measurement of round-trip time using an ICMP-based tool like ping. Additional design goals of OWAMP include being hard to detect and manipulate, security, logical separation of control and test functionality, and support for small test packets. OWAMP test traffic is hard to detect, because it is simply a stream of UDP packets from and to negotiated port numbers with potentially nothing static in the packets (size is negotiated, too). Additionally, OWAMP supports an encrypted mode, that further obscures the traffic, at the same time making it impossible to alter timestamps undetectably. Security features include optional authentication and/or encryption of control and test messages. These features may be useful to prevent unauthorized access to results or man-in-the-middle attackers who attempt to provide special treatment to OWAMP test streams or who attempt to modify sender A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-owdp-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-owdp-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: <20020703131639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-owdp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-owdp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131639.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 5 11:19:30 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29223 for ; Fri, 5 Jul 2002 11:19:30 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65FG3TY029138; Fri, 5 Jul 2002 11:16:03 -0400 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g63HMNTY017036 for ; Wed, 3 Jul 2002 13:22:24 -0400 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g63HMKU20860 for ; Wed, 3 Jul 2002 13:22:20 -0400 Received: from scarpia.watson.ibm.com (scarpia.watson.ibm.com [9.2.9.124]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g63HMJL28806 for ; Wed, 3 Jul 2002 13:22:19 -0400 Received: (from ayoussef@localhost) by scarpia.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id NAA31876 for ippm@advanced.org; Wed, 3 Jul 2002 13:22:08 -0400 Date: Wed, 3 Jul 2002 13:22:08 -0400 From: Alaa Youssef Message-Id: <200207031722.NAA31876@scarpia.watson.ibm.com> To: ippm@advanced.org Subject: [ippm] IEEE Infocom 2003 CFP Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List [Please accept our appologies if you receive duplicates of this announcement] ************************************************* ******* CALL FOR PAPERS ********* ************************************************* * IEEE INFOCOM 2003 * * The Conference on Computer Communications * * * * March 30 - April 3, 2003, San Francisco * * * * The 22nd Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2003 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 22nd anniversary in San Francisco, California, during the week of March 30 - April 3, 2003. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Ad hoc & sensor networks * Addressing & location management * Admission control * Cellular networks * Content distribution & web caching * Flow & congestion control * Multicast * Network applications & services * Network architectures * Network control by pricing * Network design & planning * Network management & control * Optical networks * Power control * Pricing & billing mechanisms * Quality of service * Queueing/performance evaluation * Resource allocation * Routing algorithms * Scheduling & buffer management * Security & denial of service * Switches & switching * Topology inference * Traffic & performance measurement * Traffic engineering * Web performance * Wireless LANs SCHEDULE (STRICTLY ENFORCED) Full paper due July 10, 2002 Notification of acceptance October 25, 2002 Final version due December 19, 2002 CONFERENCE SCHEDULE Tutorials March 30-31, 2003 Conference April 1-3, 2003 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2003 For general information please contact the Genaral Chair, Fred Bauer (fredbauer@ieee.org) PROGRAM COMMITTEE CO-CHAIRS =========================== Jim Roberts, France Telecom R&D, France (james.roberts@francetelecom.com) Ness Shroff, Purdue University, USA (shroff@ecn.purdue.edu) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 5 16:18:09 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15531 for ; Fri, 5 Jul 2002 16:18:09 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65KI5TY018024; Fri, 5 Jul 2002 16:18:05 -0400 Received: from mainserver.surfnetusa.com (mainserver.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65G2NTY006182 for ; Fri, 5 Jul 2002 12:02:23 -0400 Received: from [63.67.14.34] by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id bfmqfcaa for ippm@advanced.org; Fri, 5 Jul 2002 09:02:21 -0700 Message-Id: <5.1.0.14.2.20020705090017.00b68548@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Jul 2002 09:02:10 -0700 To: ippm@advanced.org From: Merike Kaeo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] ippm agenda Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List The following is our agenda at the upcoming IETF meeting. There are a few minutes spare so we have a slight buffer in time. - Matt and Merike IP Performance Metrics WG (ippm) Monday, July 15 at 13:00 - 15:00 ==================================== CHAIRS: Merike Kaeo , Matt Zekauskas AGENDA: 1. Agenda bashing (<= 5 min) 2. Working Group Milestones Status (5 min) -- Matt Zekauskas, Merike Kaeo 3. IPPM Reporting MIB and Metrics Registry discussion (30 min) -- Emile Stephan http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-mib-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-00.txt ?? 4. Discussion on Packet Reordering (20 min) -- Al Morton http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-00.txt 5. Discussion on One-Way Active Measurements Protocol Requirements (20 min) -- Stanislav Shalunov http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-reqs-02.txt see also http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-04.txt 6. One-Way Metric Applicability Statement (25 min) -- Henk Uijterwaal http://www.ietf.org/internet-drafts/draft-ietf-ippm-owmetric-as-00.txt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 5 16:18:11 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15555 for ; Fri, 5 Jul 2002 16:18:11 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65KIGTY018557; Fri, 5 Jul 2002 16:18:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65JVDTY010441 for ; Fri, 5 Jul 2002 15:31:13 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12528; Fri, 5 Jul 2002 15:30:22 -0400 (EDT) Message-Id: <200207051930.PAA12528@ietf.org> To: IETF-Announce: ; Cc: ippm@advanced.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 05 Jul 2002 15:30:21 -0400 Subject: [ippm] Last Call: IP Packet Delay Variation Metric for IPPM to Proposed Standard Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List The IESG has received a request from the IP Performance Metrics Working Group to consider IP Packet Delay Variation Metric for IPPM as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 2, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-09.txt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 5 17:10:00 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15532 for ; Fri, 5 Jul 2002 16:18:09 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65KIATY018145; Fri, 5 Jul 2002 16:18:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65IokTY004807 for ; Fri, 5 Jul 2002 14:50:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10413; Fri, 5 Jul 2002 14:49:55 -0400 (EDT) Message-Id: <200207051849.OAA10413@ietf.org> To: IETF-Announce: ; Cc: ippm@advanced.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 05 Jul 2002 14:49:54 -0400 Subject: [ippm] Last Call: Network performance measurement for periodic streams to Proposed Standard Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List The IESG has received a request from the IP Performance Metrics Working Group to consider Network performance measurement for periodic streams as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 2, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-07.txt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jul 9 07:22:32 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19843 for ; Tue, 9 Jul 2002 07:22:32 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g69BI3Q9030096; Tue, 9 Jul 2002 07:18:03 -0400 Received: from urda.heanet.ie (urda.heanet.ie [193.1.219.124]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g69BHhQ9030002 for ; Tue, 9 Jul 2002 07:17:56 -0400 Received: from heanet.ie (vreijs.heanet.ie [193.1.219.219] (may be forged)) by urda.heanet.ie (8.9.3/8.9.3) with ESMTP id MAA21329 for ; Tue, 9 Jul 2002 12:17:42 +0100 Message-ID: <3D2AC5EC.A63AC2D8@heanet.ie> Date: Tue, 09 Jul 2002 12:15:56 +0100 From: Victor Reijs Organization: HEAnet Ltd X-Sender: "Victor Reijs" X-Mailer: Mozilla 4.77 [en]C-CCK-MCD SURFKITV4 (Windows NT 5.0; U) X-Accept-Language: nl,en MIME-Version: 1.0 To: ippm@advanced.org References: <3D2AC179.2979ABEB@heanet.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] One-Way Metric Applicability Statement Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello Henk, A few remarks to the document: Victor Reijs wrote: > > Internet Draft Henk Uijterwaal > Document: draft-ietf-ippm-owmetric-as-00.txt Merike Kaeo > Expires: December 2002 July 2002 > > One-Way Metric Applicability Statement > > Uijterwaal et al. Expires December 2001 > [Page 1] Should this not be 'Expires December 2002' > 3. Recommendations for one way delay and loss measurements. > > [Question: Can we benefit from packet sampling BOF work here? > Ideally, > math to calculate that if an effect occurs with a rate of N Hz > and we > send traffic with M Hz, there is a probability >X that one packet > will > see this effect.] Sorry I have no answers, but this info is indeed important. In general we need for every reported value an accuracy range (by default). Although this is can problematic, e.g. if measuring the ipdv, the two time stamps could be inaccurate looking at the 'atomic/synchronized time', but the ipdv calculated of these values could be accurate enough (due to the strong correlation between the two errors). > When packets are sent larger than the minimum size required by > the > measurement device, the remainder of the packet should be padded > with > random bits in order to avoid compression being applied to any > measurement packets. Perhaps 'Packet content' is also worth a section. (which could include the above section). I know of new interface types that had some flaw depending on the packet content. And indeed compression is another one. I hope that tools have configurable 'packet content' by the way (because of the mentioned reason). > In the case of IPDV, there are 2 timestamps and initial > errors > can be huge. Perhaps this sentence needs some explanation. I assume you mean here that if the clock has been changed between the two measurement packets, the ipdv result can/will be inaccurate. Do you mean this circumstance? > > How to report intermediate results? Don't fully understand this question. I would say that reporting intermediate values is a level higher (e.g. the publishing software). But I think I misunderstand this statement. > Lastly, make > sure that > the total test traffic volume sent or received by a machine is > small > compared to total link capacity, a number of 3% of the total > capacity > seems reasonable. Is it in principle not 3% of the available bandwidth? Also when the link is being used, I still don't want accessive load looking from the available bandwidth standpoint. > 4.3. Average/Sigma versus 2.5/median/97.5% > > Since Average/Sigma for a one-way delay distribution is not well > defined, and percentiles are,we should use the latter. And for packet loss metric? What should we use? Perhaps we need sections for each metric 'Reporting the '. Hope this is helpful. All the best, Victor -- PGP public key: http://www.heanet.ie/heanet/projects/nat_infrastruct/pubkey.html H.323 GDS: +00353 01101001 H.323 ViDiNet: +61330060909 01101001 _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jul 9 08:55:11 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23100 for ; Tue, 9 Jul 2002 08:55:11 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g69Ct4Q9019292; Tue, 9 Jul 2002 08:55:04 -0400 Received: from urda.heanet.ie (urda.heanet.ie [193.1.219.124]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g69CsGQ9018647 for ; Tue, 9 Jul 2002 08:54:16 -0400 Received: from heanet.ie (vreijs.heanet.ie [193.1.219.219] (may be forged)) by urda.heanet.ie (8.9.3/8.9.3) with ESMTP id NAA28791 for ; Tue, 9 Jul 2002 13:54:15 +0100 Message-ID: <3D2ADC8D.91C91D45@heanet.ie> Date: Tue, 09 Jul 2002 13:52:29 +0100 From: Victor Reijs Organization: HEAnet Ltd X-Sender: "Victor Reijs" X-Mailer: Mozilla 4.77 [en]C-CCK-MCD SURFKITV4 (Windows NT 5.0; U) X-Accept-Language: nl,en MIME-Version: 1.0 To: IPPM IETF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] IPFIX Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello all of you, I know this is not really part of IPPM (active measurements), but in the passive measurement group they are going to finalize the information model for IPFIX. I still have some idea (or is it a dream;-) that active and passive measurements can in some way utilize perhaps the same (or partially the same) information model. If you also think the same, please try to review the IPFIX information model from such a standpoint. The model can be found at: http://ipfix.doit.wisc.edu/req/draft-ietf-ipfix-reqs-04.txt All the best, Victor -- PGP public key: http://www.heanet.ie/heanet/projects/nat_infrastruct/pubkey.html H.323 GDS: +00353 01101001 H.323 ViDiNet: +61330060909 01101001 _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 12 05:38:54 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13764 for ; Fri, 12 Jul 2002 05:38:54 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g6C9R3Q9015913; Fri, 12 Jul 2002 05:27:03 -0400 Received: from tid.tid.es (tidos.tid.es [193.145.240.2]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g6C9Q7Q9015725 for ; Fri, 12 Jul 2002 05:26:08 -0400 Received: from holland.tid.es ([10.95.15.187]) by tid.tid.es (Netscape Messaging Server 4.15) with ESMTP id GZ4Q7400.Y2D for ; Fri, 12 Jul 2002 11:26:05 +0200 Message-Id: <5.1.0.14.2.20020712112147.0292dca8@tid.cpd.hi.inet> X-Sender: holland@tid.cpd.hi.inet X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Jul 2002 11:27:05 +0200 To: IPPM IETF From: Henrik Holland In-Reply-To: <3D2ADC8D.91C91D45@heanet.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] availability Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Dear all, This may not be directly IPPM but maybe some of you can help me. In http://netperformance.genuity.com/documents/Methodology1.pdf I find: "The Internet Engineering Task Force (IETF) specifies that a network element is "available" if it responds successfully to a minimum of 15 pings out of 20 it receives." Can anyone tell me where (in what doc) the IETF specifies this? Regards, Henrik. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 12 06:01:21 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14533 for ; Fri, 12 Jul 2002 06:01:21 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g6C9l3Q9020962; Fri, 12 Jul 2002 05:47:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g6C9juQ9020723 for ; Fri, 12 Jul 2002 05:45:56 -0400 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id g6C9jsB13461; Fri, 12 Jul 2002 11:45:54 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.11.6/8.11.6) with ESMTP id g6C9jnM15442; Fri, 12 Jul 2002 11:45:54 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 12 Jul 2002 11:45:49 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Henrik Holland cc: IPPM IETF Subject: Re: [ippm] availability In-Reply-To: <5.1.0.14.2.20020712112147.0292dca8@tid.cpd.hi.inet> 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 List-Id: IETF IP Performance Metrics Working Group List Hi Henrik, > This may not be directly IPPM but maybe some of you can help me. In > http://netperformance.genuity.com/documents/Methodology1.pdf I find: > > "The Internet Engineering Task Force (IETF) specifies that a network > element is "available" if it responds successfully to a minimum of 15 pings > out of 20 it receives." > > Can anyone tell me where (in what doc) the IETF specifies this? It is definitely not in any IPPM document. It would also be a very silly metric: if I'm accessing a device through protocol X, I want to know if it responds to that protocol, not if it responds to another protocol. 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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk@ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 15 07:58:46 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26846 for ; Mon, 15 Jul 2002 07:58:45 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6FBnDE8032247; Mon, 15 Jul 2002 07:49:13 -0400 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g69IsNQ9006143 for ; Tue, 9 Jul 2002 14:54:24 -0400 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g69IsMC15770 for ; Tue, 9 Jul 2002 14:54:22 -0400 Received: from scarpia.watson.ibm.com (scarpia.watson.ibm.com [9.2.9.124]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g69IsLL38086 for ; Tue, 9 Jul 2002 14:54:21 -0400 Received: (from ayoussef@localhost) by scarpia.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA26784 for ippm@advanced.org; Tue, 9 Jul 2002 14:54:12 -0400 Date: Tue, 9 Jul 2002 14:54:12 -0400 From: Alaa Youssef Message-Id: <200207091854.OAA26784@scarpia.watson.ibm.com> To: ippm@advanced.org Subject: [ippm] IEEE Infocom 2003 Final Call For Papers Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-Virus-Scanned: by amavisd-milter (http://amavis.org/) [Please accept our appologies if you receive duplicates of this announcement] ************************************************* ******* FINAL CALL FOR PAPERS ********* ************************************************* * IEEE INFOCOM 2003 * * The Conference on Computer Communications * * * * March 30 - April 3, 2003, San Francisco * * * * The 22nd Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2003 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 22nd anniversary in San Francisco, California, during the week of March 30 - April 3, 2003. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Ad hoc & sensor networks * Addressing & location management * Admission control * Cellular networks * Content distribution & web caching * Flow & congestion control * Multicast * Network applications & services * Network architectures * Network control by pricing * Network design & planning * Network management & control * Optical networks * Power control * Pricing & billing mechanisms * Quality of service * Queueing/performance evaluation * Resource allocation * Routing algorithms * Scheduling & buffer management * Security & denial of service * Switches & switching * Topology inference * Traffic & performance measurement * Traffic engineering * Web performance * Wireless LANs SCHEDULE (STRICTLY ENFORCED) Full paper due July 10, 2002 Tutorial proposals due September 30, 2002 Notification of acceptance October 25, 2002 Final version due December 19, 2002 CONFERENCE SCHEDULE Tutorials March 30-31, 2003 Conference April 1-3, 2003 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2003 For general information please contact the Genaral Chair, Fred Bauer (fredbauer@ieee.org) PROGRAM COMMITTEE CO-CHAIRS =========================== Jim Roberts, France Telecom R&D, France (james.roberts@francetelecom.com) Ness Shroff, Purdue University, USA (shroff@ecn.purdue.edu) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 15 08:49:20 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02226 for ; Mon, 15 Jul 2002 08:49:20 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6FChrkG011455; Mon, 15 Jul 2002 08:43:53 -0400 Received: from cse.cuhk.edu.hk ([137.189.91.190]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65HWsTY024565 for ; Fri, 5 Jul 2002 13:32:55 -0400 Received: from daffodil (cslui@daffodil.cs.cuhk.hk [137.189.91.37]) by cse.cuhk.edu.hk with ESMTP id g65HWeW01064; Sat, 6 Jul 2002 01:32:41 +0800 (HKT) Received: by daffodil (8.8.8+Sun/SMI-SVR4) id BAA27195; Sat, 6 Jul 2002 01:32:40 +0800 (HKT) From: cslui@cse.cuhk.edu.hk Message-Id: <200207051732.BAA27195@daffodil> To: ippm@advanced.org Date: Sat, 6 Jul 2002 01:32:40 +0800 (HKT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] call for participation: IFIP WG7.3 Performance 2002 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi: How are you? We need to ask you for a favor. The IFIP WG 7.3 Performance'2002 conference is approaching. Can you help us to distribute the following call for participatinon in the IFIP WG7.3 mailing list. Many thanks for your consideration. Regards, John C.S. Lui =====================CALL FOR PARTICIPATION ============================ ---------Please accept our apologies for multiple copies.----------------- Call For Participation IFIP WG7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation Rome, Italy September 23 - 27, 2002 The IFIP WG7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation will be held in Rome, Italy on September 23-27, 2002. The tutorials will be held on June 23 and 24, 2002. The advance program, hotel and conference registration forms, tutorials, STUDENT TRAVEL SUPPORT can be found on the following web page: http://perf2002.uniroma2.it/ **********Student Travel Grant: ************ A number of student grants will be available. The grants will cover the registration fees of the conference and of the tutorials. Full time students can apply for a grant by sending an application, in Postscript or PDF format, to grants@perf2002.uniroma2.it no later than July 15, 2002. Applications, not exceeding 3 pages, should include a cv and a brief description of the research interests of the applicants. *********************************************************************** Deadline for early conference registration: on or before July 25, 2002 Hotel reservation: on or before July 30, 2002. PLEASE MAKE SURE TO MAKE YOUR HOTEL RESERVATIONS AS SOON AS POSSIBLE. SEPTEMBER IS A VERY VERY HIGH SEASON AND IT MIGHT BE VERY DIFFICULT TO FIND AN ACCOMMODATION AT THE LAST MINUTE!!!!!!!!! *********************************************************************** Papers for the Technical Program: Output Models of MAP/PH/1(/K) Queues for an Efficient Network Decomposition Armin Heindl, Miklos Telek Second Order Stochastic Fluid Models with Fluid Dependent Flow Rates Dongyan Chen, Yiguang Hong, Kishor S. Trivedi Solving Dimensioning Tasks for Proportionally Fair Networks Carrying Elastic Traffic Pal Nilsson, Michal Pioro Non-Cooperative Routing in Loss Networks Eitan Altman, Rachid El Azouzi, Vyacheslav Abramov Service Differentiation for Delay-Sensitive Applications: An Optimisation-Based Approach Peter Key, Larent Massoulie, Jonathan K. Shapiro Forwarders vs. Centralized Server: An Evaluation of Two Approaches for Locating Mobile Agents Sara Alouf, Fabrice Huet, Philippe Nain User-level performance of elastic traffic in integrated-services networks S.C. Borst, R. Nunez-Queija, M.J.G. van Uitert Analysis of Two Competing TCP/IP Connections E. Altman, T. Jimenez, R. Nunez-Queija Asymptotic Convergence of Scheduling Policies with respect to Slowdown Mor Harchol-Balter, Karl Sigman, Adam Wierman Insensitivity in processor-sharing networks T. Bonald, A. Proutiere Worst Case Burstiness Increase due to FIFO Vicent Cholvi, Juan Echague, Jean-Yves Le Boudec An Iterative Bounding Method for Stochastic Automata Networks Peter Buchholz A Closed Form Formula for Long-Lived TCP Connections Throughput Augustin Chaintreau, Danny De Vleeschauwer The Combined Gated-Exhaustive Vacation System in Discrete-time Dieter Fiems, Stijn De Vuyst, Herwig Bruneel A MAP-based Poisson cluster model for Web traffic Guy Latouche, Marie-Ange Remiche Open-loop Video Distribution with Support of VCR Functionality Ernst W. Biersack, Alain Jean-Marie, Philippe Nain A Case Study of Web Server Benchmarking Using Parallel WAN Emulation R. Simmonds, C. Williamson, M. Arlitt, R. Bradford, B. Unger Multi-path Continuous Media Streaming: What are the Benefits? L. Golubchik, J.C.S. Lui, T.F. Tung, A.H.H. Chow, W.J. Lee, G. Franceschinis, C. Anglano A mean-field model for multiple TCP connections through a buffer Francois Baccelli, David McDonald, Julien Reynier Continuous-time Hidden Markov Models for Network Performance Evaluation Wei Wei, Bing Wang, Donald Towsley Capturing the spatio-temporal behavior of real traffic data Mengzhi Wang, Anastassia Ailamaki, Christos Faloutsos Direct Measurement Versus Indirect Inference for Determining Network Internal Delays Kostas G. Anagnostakis, Michael B. Greenwald A Comparative Performance Analysis of Reliable Group Rekey Transport Protocols for Secure Multicast Sanjeev Setia, Sencun Zhu, Sushil Jajodia Comparison of Inter-Area Rekeying Algorithms Chun Zhang, Brian Decleene, Jim Kurose, Don Towsley Shared Cache Architecture for Decision Support Systems Michel Dubois, Jaeheon Jeong, Ashwini Nanda Response Times in a Two-Node Queueing Network with Feedback R.D. van der Mei, B.M.M. Gijsen, N. in `t Veld, J.L. van den Berg G-Networks with Resets Erol Gelenbe, Jean-Michel Fourneau Asymptotic shape of the Erlang capacity region of a multi-service shared resource John A. Morrison, Debasis Mitra Calculating Mean Throughputs in a multi-service system supporting Elastic and Rate Adaptive Traffic Sandor Racz, Balazs Peter Gero, Gabor Fodor Delimiting the Range of Effectiveness of Scalable On-Demand Streaming Haonan Tan, Derek Eager, Mary Vernon ****************************************************************************** Tutorials : please refer to http://perf2002.uniroma2.it/tutorials_program.html ****************************************************************************** General Chair: Salvatore Tucci, University of Roma "Tor Vergata" (tucci@torvergata.it) Pogram Chairs: Lorenzo Donatiello, University of Bologna (donat@cs.unibo.it) Mark Squillante, IBM Research Lab (mss@watson.ibm.com) Don Towsley, University of Massachusetts (towsley@cs.umass.edu) Tutorial Chair: Maria Carla Calzarossa, University of Pavia (mcc@alice.unipv.it) Corporate sponsors: * Wind * Microsoft Italia * IBM Italia * Banca di Roma * Nova Systems Roma * Promozione Castelli Romani * Bnl Multiservizi * Universit degli Studi di Roma ''Tor Vergata'' * Associazione Italiana per l'Informatica ed il Calcolo Automatico _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 15 08:50:27 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02303 for ; Mon, 15 Jul 2002 08:50:27 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6FChvkG011685; Mon, 15 Jul 2002 08:43:57 -0400 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g69IsNQ9006143 for ; Tue, 9 Jul 2002 14:54:24 -0400 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g69IsMC15770 for ; Tue, 9 Jul 2002 14:54:22 -0400 Received: from scarpia.watson.ibm.com (scarpia.watson.ibm.com [9.2.9.124]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g69IsLL38086 for ; Tue, 9 Jul 2002 14:54:21 -0400 Received: (from ayoussef@localhost) by scarpia.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA26784 for ippm@advanced.org; Tue, 9 Jul 2002 14:54:12 -0400 Date: Tue, 9 Jul 2002 14:54:12 -0400 From: Alaa Youssef Message-Id: <200207091854.OAA26784@scarpia.watson.ibm.com> To: ippm@advanced.org Subject: [ippm] IEEE Infocom 2003 Final Call For Papers Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List [Please accept our appologies if you receive duplicates of this announcement] ************************************************* ******* FINAL CALL FOR PAPERS ********* ************************************************* * IEEE INFOCOM 2003 * * The Conference on Computer Communications * * * * March 30 - April 3, 2003, San Francisco * * * * The 22nd Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2003 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 22nd anniversary in San Francisco, California, during the week of March 30 - April 3, 2003. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Ad hoc & sensor networks * Addressing & location management * Admission control * Cellular networks * Content distribution & web caching * Flow & congestion control * Multicast * Network applications & services * Network architectures * Network control by pricing * Network design & planning * Network management & control * Optical networks * Power control * Pricing & billing mechanisms * Quality of service * Queueing/performance evaluation * Resource allocation * Routing algorithms * Scheduling & buffer management * Security & denial of service * Switches & switching * Topology inference * Traffic & performance measurement * Traffic engineering * Web performance * Wireless LANs SCHEDULE (STRICTLY ENFORCED) Full paper due July 10, 2002 Tutorial proposals due September 30, 2002 Notification of acceptance October 25, 2002 Final version due December 19, 2002 CONFERENCE SCHEDULE Tutorials March 30-31, 2003 Conference April 1-3, 2003 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2003 For general information please contact the Genaral Chair, Fred Bauer (fredbauer@ieee.org) PROGRAM COMMITTEE CO-CHAIRS =========================== Jim Roberts, France Telecom R&D, France (james.roberts@francetelecom.com) Ness Shroff, Purdue University, USA (shroff@ecn.purdue.edu) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 15 08:50:30 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02320 for ; Mon, 15 Jul 2002 08:50:30 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6FCiXkG013691; Mon, 15 Jul 2002 08:44:33 -0400 Received: from mail.dsi.uniroma1.it ([151.100.17.45]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g6EG06Q9002829 for ; Sun, 14 Jul 2002 12:00:06 -0400 Received: from flashnet.it (Petrioli.dsi.uniroma1.it [151.100.17.132]) by mail.dsi.uniroma1.it (8.9.3/8.9.3) with ESMTP id SAA08907; Sun, 14 Jul 2002 18:33:31 +0200 (CEST) Message-ID: <3D319FD2.1841B8A9@flashnet.it> Date: Sun, 14 Jul 2002 17:59:14 +0200 From: Chiara Petrioli X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org, petrioli@dsi.uniroma1.it Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [ippm] IEEE PERCOM 2003 CFP Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit [Sincere apologies if you receive multiple copies of this announcement.] Preliminary Call for Papers ---------------------------------------------------------------------- P E R C O M 2 0 0 3 IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONS Dallas-Fort Worth Metroplex, Texas March 23-26, 2003 Sponsored by the IEEE Computer Society University of Texas at Arlington ---------------------------------------------------------------------- URL: http://www.percom.org PAPER SUBMISSION DEADLINE: October 1, 2002 Pervasive computing and communications is emerging as an exciting new paradigm with a goal to provide computing and communication services all the time everywhere. This is a natural outcome of research and technological advances in wireless networks, mobile computing, distributed computing and agent technologies. PerCom is the annual IEEE conference on pervasive computing and communications. PerCom2003 will provide a high profile, leading edge forum for researchers and engineers alike to present their latest advances in the field of pervasive computing and communications. PerCom 2003 will also feature two special tracks on intelligent environments and mobile agents. TOPICS: ---------------- Contributions are solicited in all areas of pervasive computing research. These include, but are not limited to the following feature topics: · Pervasive computing architectures · Intelligent environments · Wearable computers · Smart devices and smart spaces · Location-dependent / personalized applications · Service discovery mechanisms · Agent technologies · Sensors and actuators · Positioning and tracking technologies · Identification and authentication technologies · Integration of wired and wireless networks · Personal area networks · Enabling technologies such as Bluetooth, 802.11 and 802.15 · Software coordination models · Mobile / wireless computing systems and services · Context based and implicit computing · Speech processing / advanced computer vision · User interfaces and interaction models · Wireless/mobile service management and delivery · Ad hoc networking protocols and service discovery · Resource management in pervasive computing platforms · Security and privacy issues for pervasive computing systems SUBMISSION GUIDELINES: Papers must be unpublished and must not be submitted for publication elsewhere. Authors are encouraged to submit papers in electronic form, postscript or PDF only. The page limit for submissions is 15 pages (1.5 line spaced, excluding references, figures and tables). More details on submission procedures are posted on the official PerCom website: http://www.percom.org. All submitted papers will undergo a rigorous review process managed by the technical program committee. Conference proceedings will be published by IEEE. Papers of particular merit will be considered for publication in a special issue of a leading journal. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% IMPORTANT DATES/DEADLINES: Paper Submissions: October 1, 2002 Acceptance Notification: December 10, 2002 Camera Ready Manuscripts: January 10, 2003 Conference Dates: March 23-26, 2003 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ORGANIZING COMMITTEE: GENERAL CHAIR Behrooz A. Shirazi, University of Texas at Arlington GENERAL VICE CHAIR Sajal K. Das, University of Texas at Arlington TECHNICAL PROGRAM COMMITTEE CHAIR Mohan Kumar, University of Texas at Arlington LOCAL CHAIR Gergely V. Záruba, University of Texas at Arlington FINANCE CHAIR David Levine, University of Texas at Arlington INTELLIGENT ENVIRONMENTS TRACK CHAIR Diane Cook, University of Texas at Arlington MOBILE AGENTS TRACK CHAIR Anand Tripathi, University of Minnesota TUTORIALS CHAIR Azzedine Boukerche, University of North Texas INDUSTRY LIAISON Kalyan Basu, University of Texas at Arlington PUBLICITY CHAIRS Stefano Basagni, Northeastern University, Boston Chiara Petrioli, University of Rome, Italy Albert Zomaya, University of Sydney, Australia TECHNICAL PROGRAM COMMITTEE: (Under Creation) Giuseppe Anastasi, University of Pisa, Italy Jean Bacon, University of Cambridge, UK Chatschik Bisdikian, IBM, USA Lisa Burnell, Texas Christian University, USA Liang Cheng, Lehigh University, USA Marco Conti, National Research Council, Italy Diane Cook, University of Texas at Arlington, USA Antonio Corradi, University of Bologna, Italy Jason Flinn, Carnegie Mellon University, USA Robert Gray, Dartmouth College, USA Liviu Iftode, Rutgers University, USA Archan Misra, IBM Center, USA Yannis Labrou, Fujitsu, USA Mohan Kumar, University of Texas at Arlington, USA Phil McKinley, Michigan State University, USA Paddy Nixon, The University of Strathclyde, UK Gian Pietro Picco, Politecnico di Milano, Italy Cauligi S. Raghavendra, University of Southern California, USA Ichiro Satoh, National Institute of Informatics, Japan Steven Shafer, Microsoft Corporation, USA HJ Siegel, Colorado State University, USA Anand Tripathi, University of Minnesota, USA Mohan Trivedi, University of California, San Diego, USA Taieb Znati, University of Pittsburgh, USA -------------------------------------------------------- -- Prof. Chiara Petrioli Dipartimento di Informatica Rome University 'La Sapienza' Via Salaria 113, 00198 Roma ITALY E-mail: petrioli@dsi.uniroma1.it _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 15 08:51:33 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02366 for ; Mon, 15 Jul 2002 08:51:32 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6FCi3kG012045; Mon, 15 Jul 2002 08:44:03 -0400 Received: from cse.cuhk.edu.hk ([137.189.91.190]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g65HWsTY024565 for ; Fri, 5 Jul 2002 13:32:55 -0400 Received: from daffodil (cslui@daffodil.cs.cuhk.hk [137.189.91.37]) by cse.cuhk.edu.hk with ESMTP id g65HWeW01064; Sat, 6 Jul 2002 01:32:41 +0800 (HKT) Received: by daffodil (8.8.8+Sun/SMI-SVR4) id BAA27195; Sat, 6 Jul 2002 01:32:40 +0800 (HKT) From: cslui@cse.cuhk.edu.hk Message-Id: <200207051732.BAA27195@daffodil> To: ippm@advanced.org Date: Sat, 6 Jul 2002 01:32:40 +0800 (HKT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] call for participation: IFIP WG7.3 Performance 2002 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi: How are you? We need to ask you for a favor. The IFIP WG 7.3 Performance'2002 conference is approaching. Can you help us to distribute the following call for participatinon in the IFIP WG7.3 mailing list. Many thanks for your consideration. Regards, John C.S. Lui =====================CALL FOR PARTICIPATION ============================ ---------Please accept our apologies for multiple copies.----------------- Call For Participation IFIP WG7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation Rome, Italy September 23 - 27, 2002 The IFIP WG7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation will be held in Rome, Italy on September 23-27, 2002. The tutorials will be held on June 23 and 24, 2002. The advance program, hotel and conference registration forms, tutorials, STUDENT TRAVEL SUPPORT can be found on the following web page: http://perf2002.uniroma2.it/ **********Student Travel Grant: ************ A number of student grants will be available. The grants will cover the registration fees of the conference and of the tutorials. Full time students can apply for a grant by sending an application, in Postscript or PDF format, to grants@perf2002.uniroma2.it no later than July 15, 2002. Applications, not exceeding 3 pages, should include a cv and a brief description of the research interests of the applicants. *********************************************************************** Deadline for early conference registration: on or before July 25, 2002 Hotel reservation: on or before July 30, 2002. PLEASE MAKE SURE TO MAKE YOUR HOTEL RESERVATIONS AS SOON AS POSSIBLE. SEPTEMBER IS A VERY VERY HIGH SEASON AND IT MIGHT BE VERY DIFFICULT TO FIND AN ACCOMMODATION AT THE LAST MINUTE!!!!!!!!! *********************************************************************** Papers for the Technical Program: Output Models of MAP/PH/1(/K) Queues for an Efficient Network Decomposition Armin Heindl, Miklos Telek Second Order Stochastic Fluid Models with Fluid Dependent Flow Rates Dongyan Chen, Yiguang Hong, Kishor S. Trivedi Solving Dimensioning Tasks for Proportionally Fair Networks Carrying Elastic Traffic Pal Nilsson, Michal Pioro Non-Cooperative Routing in Loss Networks Eitan Altman, Rachid El Azouzi, Vyacheslav Abramov Service Differentiation for Delay-Sensitive Applications: An Optimisation-Based Approach Peter Key, Larent Massoulie, Jonathan K. Shapiro Forwarders vs. Centralized Server: An Evaluation of Two Approaches for Locating Mobile Agents Sara Alouf, Fabrice Huet, Philippe Nain User-level performance of elastic traffic in integrated-services networks S.C. Borst, R. Nunez-Queija, M.J.G. van Uitert Analysis of Two Competing TCP/IP Connections E. Altman, T. Jimenez, R. Nunez-Queija Asymptotic Convergence of Scheduling Policies with respect to Slowdown Mor Harchol-Balter, Karl Sigman, Adam Wierman Insensitivity in processor-sharing networks T. Bonald, A. Proutiere Worst Case Burstiness Increase due to FIFO Vicent Cholvi, Juan Echague, Jean-Yves Le Boudec An Iterative Bounding Method for Stochastic Automata Networks Peter Buchholz A Closed Form Formula for Long-Lived TCP Connections Throughput Augustin Chaintreau, Danny De Vleeschauwer The Combined Gated-Exhaustive Vacation System in Discrete-time Dieter Fiems, Stijn De Vuyst, Herwig Bruneel A MAP-based Poisson cluster model for Web traffic Guy Latouche, Marie-Ange Remiche Open-loop Video Distribution with Support of VCR Functionality Ernst W. Biersack, Alain Jean-Marie, Philippe Nain A Case Study of Web Server Benchmarking Using Parallel WAN Emulation R. Simmonds, C. Williamson, M. Arlitt, R. Bradford, B. Unger Multi-path Continuous Media Streaming: What are the Benefits? L. Golubchik, J.C.S. Lui, T.F. Tung, A.H.H. Chow, W.J. Lee, G. Franceschinis, C. Anglano A mean-field model for multiple TCP connections through a buffer Francois Baccelli, David McDonald, Julien Reynier Continuous-time Hidden Markov Models for Network Performance Evaluation Wei Wei, Bing Wang, Donald Towsley Capturing the spatio-temporal behavior of real traffic data Mengzhi Wang, Anastassia Ailamaki, Christos Faloutsos Direct Measurement Versus Indirect Inference for Determining Network Internal Delays Kostas G. Anagnostakis, Michael B. Greenwald A Comparative Performance Analysis of Reliable Group Rekey Transport Protocols for Secure Multicast Sanjeev Setia, Sencun Zhu, Sushil Jajodia Comparison of Inter-Area Rekeying Algorithms Chun Zhang, Brian Decleene, Jim Kurose, Don Towsley Shared Cache Architecture for Decision Support Systems Michel Dubois, Jaeheon Jeong, Ashwini Nanda Response Times in a Two-Node Queueing Network with Feedback R.D. van der Mei, B.M.M. Gijsen, N. in `t Veld, J.L. van den Berg G-Networks with Resets Erol Gelenbe, Jean-Michel Fourneau Asymptotic shape of the Erlang capacity region of a multi-service shared resource John A. Morrison, Debasis Mitra Calculating Mean Throughputs in a multi-service system supporting Elastic and Rate Adaptive Traffic Sandor Racz, Balazs Peter Gero, Gabor Fodor Delimiting the Range of Effectiveness of Scalable On-Demand Streaming Haonan Tan, Derek Eager, Mary Vernon ****************************************************************************** Tutorials : please refer to http://perf2002.uniroma2.it/tutorials_program.html ****************************************************************************** General Chair: Salvatore Tucci, University of Roma "Tor Vergata" (tucci@torvergata.it) Pogram Chairs: Lorenzo Donatiello, University of Bologna (donat@cs.unibo.it) Mark Squillante, IBM Research Lab (mss@watson.ibm.com) Don Towsley, University of Massachusetts (towsley@cs.umass.edu) Tutorial Chair: Maria Carla Calzarossa, University of Pavia (mcc@alice.unipv.it) Corporate sponsors: * Wind * Microsoft Italia * IBM Italia * Banca di Roma * Nova Systems Roma * Promozione Castelli Romani * Bnl Multiservizi * Universit degli Studi di Roma ''Tor Vergata'' * Associazione Italiana per l'Informatica ed il Calcolo Automatico _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 15 08:52:17 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02405 for ; Mon, 15 Jul 2002 08:52:17 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6FChlkG011270; Mon, 15 Jul 2002 08:43:47 -0400 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g69IsNQ9006143 for ; Tue, 9 Jul 2002 14:54:24 -0400 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g69IsMC15770 for ; Tue, 9 Jul 2002 14:54:22 -0400 Received: from scarpia.watson.ibm.com (scarpia.watson.ibm.com [9.2.9.124]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g69IsLL38086 for ; Tue, 9 Jul 2002 14:54:21 -0400 Received: (from ayoussef@localhost) by scarpia.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA26784 for ippm@advanced.org; Tue, 9 Jul 2002 14:54:12 -0400 Date: Tue, 9 Jul 2002 14:54:12 -0400 From: Alaa Youssef Message-Id: <200207091854.OAA26784@scarpia.watson.ibm.com> To: ippm@advanced.org Subject: [ippm] IEEE Infocom 2003 Final Call For Papers Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List [Please accept our appologies if you receive duplicates of this announcement] ************************************************* ******* FINAL CALL FOR PAPERS ********* ************************************************* * IEEE INFOCOM 2003 * * The Conference on Computer Communications * * * * March 30 - April 3, 2003, San Francisco * * * * The 22nd Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2003 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 22nd anniversary in San Francisco, California, during the week of March 30 - April 3, 2003. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Ad hoc & sensor networks * Addressing & location management * Admission control * Cellular networks * Content distribution & web caching * Flow & congestion control * Multicast * Network applications & services * Network architectures * Network control by pricing * Network design & planning * Network management & control * Optical networks * Power control * Pricing & billing mechanisms * Quality of service * Queueing/performance evaluation * Resource allocation * Routing algorithms * Scheduling & buffer management * Security & denial of service * Switches & switching * Topology inference * Traffic & performance measurement * Traffic engineering * Web performance * Wireless LANs SCHEDULE (STRICTLY ENFORCED) Full paper due July 10, 2002 Tutorial proposals due September 30, 2002 Notification of acceptance October 25, 2002 Final version due December 19, 2002 CONFERENCE SCHEDULE Tutorials March 30-31, 2003 Conference April 1-3, 2003 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2003 For general information please contact the Genaral Chair, Fred Bauer (fredbauer@ieee.org) PROGRAM COMMITTEE CO-CHAIRS =========================== Jim Roberts, France Telecom R&D, France (james.roberts@francetelecom.com) Ness Shroff, Purdue University, USA (shroff@ecn.purdue.edu) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 15 09:05:39 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02996 for ; Mon, 15 Jul 2002 09:05:39 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6FCiQkG013332; Mon, 15 Jul 2002 08:44:26 -0400 Received: from mail.dsi.uniroma1.it ([151.100.17.45]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g6EG06Q9002829 for ; Sun, 14 Jul 2002 12:00:06 -0400 Received: from flashnet.it (Petrioli.dsi.uniroma1.it [151.100.17.132]) by mail.dsi.uniroma1.it (8.9.3/8.9.3) with ESMTP id SAA08907; Sun, 14 Jul 2002 18:33:31 +0200 (CEST) Message-ID: <3D319FD2.1841B8A9@flashnet.it> Date: Sun, 14 Jul 2002 17:59:14 +0200 From: Chiara Petrioli X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org, petrioli@dsi.uniroma1.it Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [ippm] IEEE PERCOM 2003 CFP Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit [Sincere apologies if you receive multiple copies of this announcement.] Preliminary Call for Papers ---------------------------------------------------------------------- P E R C O M 2 0 0 3 IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONS Dallas-Fort Worth Metroplex, Texas March 23-26, 2003 Sponsored by the IEEE Computer Society University of Texas at Arlington ---------------------------------------------------------------------- URL: http://www.percom.org PAPER SUBMISSION DEADLINE: October 1, 2002 Pervasive computing and communications is emerging as an exciting new paradigm with a goal to provide computing and communication services all the time everywhere. This is a natural outcome of research and technological advances in wireless networks, mobile computing, distributed computing and agent technologies. PerCom is the annual IEEE conference on pervasive computing and communications. PerCom2003 will provide a high profile, leading edge forum for researchers and engineers alike to present their latest advances in the field of pervasive computing and communications. PerCom 2003 will also feature two special tracks on intelligent environments and mobile agents. TOPICS: ---------------- Contributions are solicited in all areas of pervasive computing research. These include, but are not limited to the following feature topics: · Pervasive computing architectures · Intelligent environments · Wearable computers · Smart devices and smart spaces · Location-dependent / personalized applications · Service discovery mechanisms · Agent technologies · Sensors and actuators · Positioning and tracking technologies · Identification and authentication technologies · Integration of wired and wireless networks · Personal area networks · Enabling technologies such as Bluetooth, 802.11 and 802.15 · Software coordination models · Mobile / wireless computing systems and services · Context based and implicit computing · Speech processing / advanced computer vision · User interfaces and interaction models · Wireless/mobile service management and delivery · Ad hoc networking protocols and service discovery · Resource management in pervasive computing platforms · Security and privacy issues for pervasive computing systems SUBMISSION GUIDELINES: Papers must be unpublished and must not be submitted for publication elsewhere. Authors are encouraged to submit papers in electronic form, postscript or PDF only. The page limit for submissions is 15 pages (1.5 line spaced, excluding references, figures and tables). More details on submission procedures are posted on the official PerCom website: http://www.percom.org. All submitted papers will undergo a rigorous review process managed by the technical program committee. Conference proceedings will be published by IEEE. Papers of particular merit will be considered for publication in a special issue of a leading journal. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% IMPORTANT DATES/DEADLINES: Paper Submissions: October 1, 2002 Acceptance Notification: December 10, 2002 Camera Ready Manuscripts: January 10, 2003 Conference Dates: March 23-26, 2003 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ORGANIZING COMMITTEE: GENERAL CHAIR Behrooz A. Shirazi, University of Texas at Arlington GENERAL VICE CHAIR Sajal K. Das, University of Texas at Arlington TECHNICAL PROGRAM COMMITTEE CHAIR Mohan Kumar, University of Texas at Arlington LOCAL CHAIR Gergely V. Záruba, University of Texas at Arlington FINANCE CHAIR David Levine, University of Texas at Arlington INTELLIGENT ENVIRONMENTS TRACK CHAIR Diane Cook, University of Texas at Arlington MOBILE AGENTS TRACK CHAIR Anand Tripathi, University of Minnesota TUTORIALS CHAIR Azzedine Boukerche, University of North Texas INDUSTRY LIAISON Kalyan Basu, University of Texas at Arlington PUBLICITY CHAIRS Stefano Basagni, Northeastern University, Boston Chiara Petrioli, University of Rome, Italy Albert Zomaya, University of Sydney, Australia TECHNICAL PROGRAM COMMITTEE: (Under Creation) Giuseppe Anastasi, University of Pisa, Italy Jean Bacon, University of Cambridge, UK Chatschik Bisdikian, IBM, USA Lisa Burnell, Texas Christian University, USA Liang Cheng, Lehigh University, USA Marco Conti, National Research Council, Italy Diane Cook, University of Texas at Arlington, USA Antonio Corradi, University of Bologna, Italy Jason Flinn, Carnegie Mellon University, USA Robert Gray, Dartmouth College, USA Liviu Iftode, Rutgers University, USA Archan Misra, IBM Center, USA Yannis Labrou, Fujitsu, USA Mohan Kumar, University of Texas at Arlington, USA Phil McKinley, Michigan State University, USA Paddy Nixon, The University of Strathclyde, UK Gian Pietro Picco, Politecnico di Milano, Italy Cauligi S. Raghavendra, University of Southern California, USA Ichiro Satoh, National Institute of Informatics, Japan Steven Shafer, Microsoft Corporation, USA HJ Siegel, Colorado State University, USA Anand Tripathi, University of Minnesota, USA Mohan Trivedi, University of California, San Diego, USA Taieb Znati, University of Pittsburgh, USA -------------------------------------------------------- -- Prof. Chiara Petrioli Dipartimento di Informatica Rome University 'La Sapienza' Via Salaria 113, 00198 Roma ITALY E-mail: petrioli@dsi.uniroma1.it _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jul 18 02:35:18 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23463 for ; Thu, 18 Jul 2002 02:35:18 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6I6X3Te022717; Thu, 18 Jul 2002 02:33:03 -0400 Received: from BMW (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6I6WZTe022532; Thu, 18 Jul 2002 02:32:35 -0400 Date: Thu, 18 Jul 2002 02:32:23 -0400 From: Matthew J Zekauskas To: ippm@advanced.org cc: Merike Kaeo , Matt Zekauskas Message-ID: <280165767.1026959543@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [ippm] Working Group Last Call: draft-ietf-ippm-owdp-reqs-02.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The latest draft of "A One-way Active Measurement Protocol Requirements" has all the fixes and changes suggested on this list as well as previous IETF meetings. Since there have been no substantive changes suggested to this document since the last version, the co-chairs propose a Working Group last-call for this document, draft-ietf-ippm-owdp-reqs-02.txt. Assuming no major objections or changes, we will submit this document to the IESG for consideration as an Informational RFC. Please submit your comments to the IPPM mailing list or to the chairs or I-D authors as you feel appropriate (although public comments are preferred). Because this is the end of IETF week, the Working Group last-call period for this document will be extended from the customary two-week period, and will end on Monday, August 12, 2002 at 5pm EST. One pointer for the document is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-reqs-02.txt --Matt Zekauskas & Merike Kaeo _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 22 16:45:11 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07522 for ; Mon, 22 Jul 2002 16:45:11 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6MKf3Te008774; Mon, 22 Jul 2002 16:41:03 -0400 Received: from BMW (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6MKewTe008590; Mon, 22 Jul 2002 16:40:58 -0400 Date: Mon, 22 Jul 2002 16:40:45 -0400 From: Matthew J Zekauskas To: ippm@advanced.org cc: Matt Zekauskas Message-ID: <676667886.1027356045@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [ippm] Draft minutes and slide presentations from the IPPM Meeting 15-July-2002 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Draft meeting minutes and all the slide presentations from the IPPM meeting in Yokhohama on 15-July-2002 are now available at http://www.advanced.org/IPPM/Meeting/ietf54/ If anyone has any comments or concerns, let the chairs know. These will be submitted to the minutes editor in about two weeks. --Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 22 16:46:26 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07639 for ; Mon, 22 Jul 2002 16:46:25 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6MKi3Te009610; Mon, 22 Jul 2002 16:44:03 -0400 Received: from BMW (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6MKhRTe009306; Mon, 22 Jul 2002 16:43:27 -0400 Date: Mon, 22 Jul 2002 16:43:15 -0400 From: Matthew J Zekauskas To: ippm@advanced.org cc: Matt Zekauskas Subject: Re: [ippm] Draft minutes and slide presentations from the IPPM Meeting 15-July-2002 Message-ID: <676817802.1027356195@localhost> In-Reply-To: <676667886.1027356045@localhost> References: <676667886.1027356045@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit --On Monday, July 22, 2002 4:40 PM -0400 Matthew J Zekauskas wrote: > http://www.advanced.org/IPPM/Meeting/ietf54/ Ugh, typo. http://www.advanced.org/IPPM/Meetings/ietf54/ Sorry for the confusion. --Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jul 22 18:39:16 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17104 for ; Mon, 22 Jul 2002 18:39:16 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6MMZ4Te024440; Mon, 22 Jul 2002 18:35:04 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6LIqXTf027323 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 21 Jul 2002 14:52:34 -0400 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6LIqWCT061012; Sun, 21 Jul 2002 14:52:32 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6LIqPk50405; Sun, 21 Jul 2002 14:52:26 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by jessie.research.bell-labs.com (8.12.2/8.12.2) with SMTP id g6LIqOoF004498; Sun, 21 Jul 2002 14:52:24 -0400 (EDT) Message-Id: <200207211852.g6LIqOoF004498@jessie.research.bell-labs.com> Date: Sun, 21 Jul 2002 14:52:24 -0400 (EDT) From: "W. S. Cleveland" Reply-To: "W. S. Cleveland" To: te-wg@UU.NET, jshen@cad.zju.edu.cn Cc: mpls@UU.NET, ippm@advanced.org, irtf-rr@puck.nether.net, end2end-interest@postel.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8cbG27/jfAv/k75zEbHTew== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Subject: [ippm] Re: Where can I find statistics data on traffic over current high speed internet? Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List The old but still relevant query below made its way to me. Conventional wisdom until recently had it that the LRD of Internet traffic occurred from the edges to the core. The conventional is false in the sense that is relevant for network engineering of the core. We showed that packet inter-arrival times tend from LRD toward Poisson and the packet size process tends from LRD toward independent as the traffic load increases, both due to increased statistical multiplexing. There is always an LRD component in the inter-arrivals and the sizes, but the contribution of the component to the variability of each time process gets less and less. Packet and byte counts in fixed intervals maintain their LRD but their standard deviation relative to the mean decreases toward zero, so the LRD becomes irrelevant because the long excursions due to LRD above and below the mean traffic rate are so small that the excursions are irrelevant for traffic engineering. One might immediately question this on the basis that there is a contradiction. The counts maintain their LRD but the sizes and inter-arrivals do not, even though the former two come from the latter two. The explanation is this. As the traffic load increases, the smaller and smaller LRD components in the sizes and inter-arrivals are magnified more and more in forming the counts because going from sizes and inter-arrivals to counts is an aggregation process across traffic sources, which gets greater as the load increases, and magnifies more. Should we care? The answer is yes. The queueing on links tends to that of Poisson and independent as the load increases. We are in the process of a careful study of queueing and of the utilization (as a function of load) that a link can bear and drop only a very small fraction of packets. We have found so far that for very high traffic rates, say 200 mbps 3-minute average and above (from OC48 traffic measurement), the queueing results (1) for the real data, (2) for our FSD models which fit the real data very well, and (3) for a Poisson/independent model, give identical results for practical purposes. Utilizations can be quite high, around 90%, going higher or lower depending on the strictness of the QoS criterion. The traffic results can be found at stat.bell-labs.com/InternetTraffic/webpapers.html. The latest paper (to be published in a Springer book) is the most readable on this because we are getting better at explaining results. The queueing/utilization results will be available in a few weeks. William S. Cleveland http://www.stat.bell-labs.com/wsc Bell Labs, 600 Mountain Av., Murray Hill, NJ 07974 908-582-6861 (phone) 908-582-3340 (fax) > From: "Jing Shen" > To: > Cc: , , , > > Date: Sun, 17 Mar 2002 15:26:05 +0800 > Subject: [ippm] Where can I find statistics data on traffic over current high > speed internet? > Precedence: bulk > Hi, > I've read some books and papers on network traffic characteristics . But, all > of them seem to be measured before 1999 when > internet is not such a high speed one. ( As I know, from 1996 to 2001 > ChinaNet has involved from 45Mbps to 10Gbps, the subdomain of > it involved from 2Mbps to 2.Gbps , more and more people start to enjoy stream > media, multiuser game > other than only static web pages) . > I'm sure the self-similar character of internet traffic mainteins with the > network speed improvement, > But the distribution of these traffic between different protocols, the size > distribution must have changed > much. ( It seems to no measurement done with ChinaNet) > So, I want to know where I can find statistics data on current high speed > internet? > Thank you very much. > Jing Shen > State Key Lab of CAD&CG > ZheJiang University > P.R.China _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 24 10:09:42 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18000 for ; Wed, 24 Jul 2002 10:09:42 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6OE73Nt022693; Wed, 24 Jul 2002 10:07:03 -0400 Received: from BMW (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6OE6vNt022514; Wed, 24 Jul 2002 10:06:57 -0400 Date: Wed, 24 Jul 2002 10:06:40 -0400 From: Matthew J Zekauskas To: ippm@advanced.org cc: Matt Zekauskas Message-ID: <825822680.1027505200@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [ippm] Reminder: IPDV and NPMPS in IESG last-call Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Just a reminder... The periodic streams draft, draft-ietf-ippm-npmps-07.txt, and the IP delay variation draft, draft-ietf-ippm-ipdv-09.txt are in IESG last call through 02-August-2002. Both are requested to be proposed standards. Any comments you may have are welcome to iesg@ietf.org or ietf@ietf.org (here too, but make sure you cc one of those other lists). http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-09.txt --Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 24 12:20:54 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22828 for ; Wed, 24 Jul 2002 12:20:53 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6OGI2Nt028894; Wed, 24 Jul 2002 12:18:02 -0400 Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6OGHoNt028714; Wed, 24 Jul 2002 12:17:51 -0400 Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 18:17:49 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ippm] Reminder: IPDV and NPMPS in IESG last-call X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 24 Jul 2002 18:17:48 +0200 Message-ID: Thread-Topic: [ippm] Reminder: IPDV and NPMPS in IESG last-call Thread-Index: AcIzHHpK3qlRfgB9TlCvaxz5iCONhwAELjlQ From: "STEPHAN Emile FTRD/DAC/LAN" To: "Matthew J Zekauskas" , X-OriginalArrivalTime: 24 Jul 2002 16:17:49.0215 (UTC) FILETIME=[A73D42F0:01C2332D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g6OGHoNt028714 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit I will create the corresponding metrics OBJECT IDENTIFIER in the 'rfc' tree of the draft-ietf-ippm-metrics-registry-02.txt when they will gain a RFC number. emile > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@advanced.org] > Envoye : mercredi 24 juillet 2002 16:07 > A : ippm@advanced.org > Cc : Matt Zekauskas > Objet : [ippm] Reminder: IPDV and NPMPS in IESG last-call > > > Just a reminder... > > The periodic streams draft, draft-ietf-ippm-npmps-07.txt, and > the IP delay > variation draft, draft-ietf-ippm-ipdv-09.txt are in IESG last > call through > 02-August-2002. Both are requested to be proposed standards. > Any comments > you may have are welcome to iesg@ietf.org or ietf@ietf.org > (here too, but > make sure you cc one of those other lists). > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-07.txt > http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-09.txt > > --Matt > > > _______________________________________________ > 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 Thu Jul 25 10:30:45 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05999 for ; Thu, 25 Jul 2002 10:30:45 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PEN3Nt022510; Thu, 25 Jul 2002 10:23:03 -0400 Received: from entcl9.et.tu-dresden.de (entcl2.et.tu-dresden.de [141.30.128.192]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6GERsTe024367 for ; Tue, 16 Jul 2002 10:27:55 -0400 Received: (from root@localhost) by entcl9.et.tu-dresden.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id g6GEamu03568; Tue, 16 Jul 2002 16:36:48 +0200 Date: Tue, 16 Jul 2002 16:36:48 +0200 Message-Id: <200207161436.g6GEamu03568@entcl9.et.tu-dresden.de> To: ippm@advanced.org From: itc18tcp@ifn.et.tu-dresden.de Subject: [ippm] ITC 18 - Call for papers Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Our apologies for receiving multiple copies of this email.. CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS +-----------------------------------------------+ | 18th International TELETRAFFIC CONGRESS | | Haus am Köllnischen Park, Berlin, Germany | | 31 August - 5 September 2003 | | | | "Providing QoS in Heterogeneous Environments" | | http://www.ITC18.org | +-----------------------------------------------+ CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS ORGANIZATIONS AND HISTORY International Advisory Committee http://www.i-teletraffic.org/ ITG - Information Technology Society in the VDE http://www.vde.com/vde/html/e/fach/itg/itg.htm The ITC, founded in 1955, provides, through regular, now bi-annual congresses, the main international forum for teletraffic research and engineering. The purpose of the ITC is to stimulate the development and application of teletraffic theory for planning, engineering, managing and administrating telecommunication networks. The analysis and control of traffic phenomena in such networks require measurements, forecasts, as well as network management algorithms. The ITC gathers teletraffic experts from research organizations, universities, manufacturers, network operators and international technical organizations yielding a well-balanced contribution from theory and application. ITCs are organized so that researchers, engineers, and administrators from telcos and data network operators can interact and benefit from discussions and exchange of ideas. The ITC also benefits from the social environment which allows for the creation of new personal contacts between delegates. CONFERENCE CITY After 33 years, the ITC community meets again in Germany - in Berlin, the old and new capital, a four million people meeting place of the East and the West in the center of Europe. Berlin is a city in transition, one that is not always easy to understand, and which is often quite difficult to describe. However, no other city of Germany reflects the historical events of the last few years to the extent Berlin does. More information: http://www.berlin.de/english CONFERENCE VENUE Close to the river Spree in the center of Berlin, the "Haus am Köllnischen Park"is located just a few minutes walking distance from famous places such as Alexanderplatz, Humboldt University, Gendarmenmarkt, Reichstag or Brandenburger Tor. "PROVIDING QOS IN HETEROGENEOUS EINVIRONMENTS" The ITC 18 will be held in a transient phase where IP packet-switched architectures migrate from being data networks only to also substituting traditional circuit-switched networks. Papers are welcome tackling the following topics: NETWORK ARCHITECTURES AND TECHNOLOGIES - Next generation networks - Broadband transport networks - Access networks - Wireless networks and wireless LANs - Heterogeneous networks and ubiquitous communication - Web technologies - Voice over IP - Ad hoc and peer to peer networking - Communication protocols TRAFFIC CONTROL AND ENGINEERING - Traffic engineering - Quality of service provisioning - Service pricing - Overload control - Traffic management - QoS in multi-provider networks - Service-aware admission control - Traffic conditioning - Routing - Mobility management and signalling - Network planning and optimization - Network management - Reliability and Survivability METHODS AND TOOLS - Traffic characterization and modelling - Performance evaluation - Queueing theory - Scheduling - Simulation methodology - Traffic and performance measurements IMPORTANT DATES Full paper due : 31 December 2002 Notification of acceptance mailed: 16 April 2003 Camera ready paper due : 1 June 2003 SUBMISSION OF PAPERS Papers should not exceed 15 double-spaced pages (about 5000 words), have an abstract of 100-200 words, and be original material not previously published. The title page should contain the authors' names, affiliation and contact details. The corresponding author must be indicated. Only electronic submission via the ITC18 homepage will be arranged. Further information can be obtained on the ITC18 homepage via http://www.ITC18.org. CONFERENCE ORGANIZATION AND CONTACT ADDRESS ITC 18 VDE Conference Services Stresemannallee 15 D-60596 Frankfurt/Main, Germany Phone: +49 69 6308-202 Fax : +49 69 9631-5213 email: vde-conferences@vde.com COMMITTEES EXECUTIVE COMMITTEE Chair : Joachim Claus, Deutsche Telekom AG, Bonn Secretariat : Volker Schanz, ITG/VDE, Frankfurt Conference Office: Rupert Rompel, VDE, Frankfurt TECHNICAL PROGRAMME COMMITTEE Chairs: Joachim Charzinski, Siemens, Munich Ralf Lehnert, Dresden University of Technology Phuoc Tran-Gia, University of Würzburg Carmelita Görg, University of Bremen (Tutorials Chair) INTERNATIONAL TPC NATIONAL TPC Marco Ajmone Marsan, Italy Dieter Baum, University of Trier Åke Arvidsson, Sweden Matthias Baumann, Dresden University of Technology Khalid Begain, United Kingdom Gunter Bolch, University of Erlangen-Nuremberg Chris Blondia, Belgium Andreas Brandt, Humboldt University Onno Boxma, The Netherlands Joachim Charzinski, Siemens AG Herwig Bruneel, Belgium Jörg Eberspächer, Munich University of Technology Olga Casals, Spain Anja Feldmann, Saarland University Laurie Cuthbert, United Kingdom Wolfgang Fischer, Cisco GmbH Hermann de Meer, United Kingdom Carmelita Görg, University of Bremen Edmundo de Souza e Silva, Brazil Franz Hartleb, T-Systems GmbH Zbigniew Dziong, USA Boudewijn Haverkort, Aachen University of Technology Khaled Elsayed, Egypt Christoph Herrmann, Philips Research Peder Emstad, Norway Ulrich Killat, Technical University of Hamburg-Harburg David Everitt, Australia Udo Krieger, T-Systems GmbH Serge Fdida, France Paul J. Kühn, University of Stuttgart Georges Fiche, France Ralf Lehnert, Dresden University of Technology Markus Fiedler, Sweden Georg Rößler, Tenovis GmbH&Co. KG Luigi Fratta, Italy Stefan Schneeberger, Siemens AG H. Richard Gail, USA Hans-Peter Schwefel, Siemens AG Richard Harris, Australia Michael Söllner, Lucent Technologies GmbH Frank Hübner-Szabo de Bucs, USA Michael Tangemann, Alcatel AG Villy Baek Iversen, Denmark Sandra Tartarelli, NEC GmbH Konosuke Kawashima, Japan Phuoc Tran-Gia, University of Würzburg Peter Key, United Kingdom Kurt Tutschku, University of Würzburg Daniel Kofman, USA Bernhard Walke, Aachen University of Technology Yonathan Levy, USA Ulrich Wellens, Vodafone GmbH Xiong Jiang Liang, China Albert Weller, T-Mobile GmbH Karl Lindberger, Sweden Adam Wolisz, Berlin University of Technology Michel Mandjes, The Netherlands Martina Zitterbart, University of Karlsruhe Ian Marshall, United Kingdom Debasis Mitra, USA Sandor Molnár, Hungary Jorge Moreira de Souza, Brazil Arne A. Nilsson, USA Ilkka Norros, Finland Baron Peterssen, South Africa Michal Pioro, Poland Jim Roberts, France Matthew Roughan, USA Hiroshi Saito, Japan Shohei Sato, Japan Danny Tsang, Hong Kong Hans van den Berg, The Netherlands Rob van der Mei, The Netherlands Manuel Villen-Altamirano, Spain Jorma Virtamo, Finland Y.T. Wang, USA Pat Wirth, USA Jim Yan, Canada Hideaki Yoshino, Japan Moshe Zukerman, Australia _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jul 25 12:06:06 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10067 for ; Thu, 25 Jul 2002 12:06:06 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PG33Nt020153; Thu, 25 Jul 2002 12:03:03 -0400 Received: from sa.infonet.com (sa.infonet.com [192.157.130.21]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PFtnNt018364 for ; Thu, 25 Jul 2002 11:55:50 -0400 Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id g6PFtnd25923 for ; Thu, 25 Jul 2002 15:55:49 GMT Received: from zhangr2.info.net (sfjl13.us.info.net [204.79.139.13]) by delta.info.net with ESMTP id PAA20473 for ; Thu, 25 Jul 2002 15:55:48 GMT Message-Id: <5.1.0.14.0.20020725085250.026c7810@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Jul 2002 08:55:47 -0700 To: ippm@advanced.org From: raymond zhang Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] test packet size over IP network Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hello all, I wonder if anyone can provide some references or input in selecting test packet size for measuring one-way-delay. RFC 2679 or RFC 2330 does not provide any sort of recommendation. Does that mean it is left up to the SPs ? The problem with this leaving upto the service providers is when we need to integrate SLA path should different SPs choose different test packet sizes. Any input would appreciated. Regards, Raymond _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jul 25 12:38:17 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11515 for ; Thu, 25 Jul 2002 12:38:17 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PGa4Nt031488; Thu, 25 Jul 2002 12:36:04 -0400 Received: from BMW (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PGZBNt031023; Thu, 25 Jul 2002 12:35:11 -0400 Date: Thu, 25 Jul 2002 12:35:05 -0400 From: Matthew J Zekauskas To: raymond zhang cc: ippm@advanced.org Subject: Re: [ippm] test packet size over IP network Message-ID: <921127671.1027600505@localhost> In-Reply-To: <5.1.0.14.0.20020725085250.026c7810@delta.info.net> References: <5.1.0.14.0.20020725085250.026c7810@delta.info.net> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit > I wonder if anyone can provide some references or input in selecting test > packet size for measuring one-way-delay. > draft-ietf-ippm-owmetric-as-00.txt is a (very) initial attempt to try to address this, among other issues. As always, "it depends on what you are trying to measure". I can tell you what the two systems I know well do. The Surveyor system used minimal-sized UDP packets, which in our case was 12 bytes (so the physical packet size adds the UDP, IP, and any MAC header). The RIPE-TT system used 100 byte UDP packets the last time I looked. The idea behind small packets was to not send significant traffic, and just get a broad overview of the network's health. I'd be interested in what other vendors use and why (I know there are a few on the list). --Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jul 25 13:00:53 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12572 for ; Thu, 25 Jul 2002 13:00:53 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PGw3Nt004915; Thu, 25 Jul 2002 12:58:03 -0400 Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PGvSNt004810 for ; Thu, 25 Jul 2002 12:57:29 -0400 Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 25 Jul 2002 18:57:28 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 25 Jul 2002 18:57:28 +0200 Message-ID: Thread-Topic: minutes of IPPM in Yokohama Thread-Index: AcIuHsUPSkntekD1T5Og68UnaNLEXAFqRpxg From: "STEPHAN Emile FTRD/DAC/LAN" To: X-OriginalArrivalTime: 25 Jul 2002 16:57:28.0400 (UTC) FILETIME=[5BC1D500:01C233FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g6PGvSNt004810 Subject: [ippm] measurement packet header and OWAMP-test Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit Hi all, To permit the infinite type-Ps, I consider that the test packet must not depend on the type-P and that a solution consists in inserting a block of fields (a measurement packet header, MPH) at the end of a regular packets. The IPPM REPORTING MIB considers all the type-P as valid. OWAMP-test limits the type-P to raw UDP packet. I am absolutely convince that is is possible to define a set of 'measurement packet header' respectful of the test packet format defined in the draft-ietf-ippm-owdp-04.txt. The proposal I made (in progress !) in the memo draft-stephan-ippm-test-packet-00.txt have 3 constraints: + consider the OWAMP-test packet as the basic measurement packet header; + proposes standard extension which integrate OWAMP and IPPM REPORTING MIB needs; + permits proprietary extension; This proposal is not looking for "a single required standardized format" but to standardize the current practices and as far as possible a few of the future need. The section "4.3. Protocol Separation" of the draft-ietf-ippm-owdp-reqs-02.txt recommends separate protocols for the control and the test. I consider that the draft-ietf-ippm-owdp-04.txt should be splitted to garanty that the OWAMP-Control defined in draft-ietf-ippm-owdp-04.txt may be implemented without the OWAMP-Test protocol described in draft-ietf-ippm-owdp-04.txt in a way to measure the performance of the Type-Ps not permitted by the OWAMP-Test used as a packet. OWAMP-Test used a block of measurement fields is at the base of draft format proposed in draft-stephan-ippm-test-packet-00.txt is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | Prec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Pro |Type |Ver|S| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The resolution is ~ 1/4 nanosecond. Prec defines the number of bits (per range of 2)trusted in the fractional part of the second of the timestamp. 'Pro' defines the number of blocks of 8 bytes used for proprietary purposes. 'Type' defines the set of standard extensions for OWAMP-control and IPPM REPORTING MIB security checks, inegrity check, round trip delay... Is the sequence number large enough ? discussion regarding the ietf-ippm-owdp-04.txt: A precision <= to the second should set the bit S to 0. the Precision field may only describes the number of bits in the fractional part of seconds of the timestamp "that the party generating timestamp believes to be correct". It is ambiguous to set the bit S if "there is no notion of external synchronization for the time source (e.g., a cesium oscillator is used directly)". Synchronization refers to a common reference that another party may use too. regards emile > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@advanced.org] > Envoyé : jeudi 18 juillet 2002 07:48 > À : Emile Stephan; Henk Uijterwaal (RIPE-NCC) > Cc : STEPHAN Emile FTRD/DAC/LAN; acmorton@att.com; stanislav shalunov; > Merike Kaeo; Matthew J Zekauskas > Objet : Re: minutes of IPPM in Yokohama > > > Thanks for your comments. The timestamp (and your ideas about > packet formats) is a discussion that should be on the list. > > Do you think any of the text in the minutes is wrong? > > As to packet formats... the idea (I believe) is to have a single > required standardized format (so implementations can > interoperate).. but cooperating entities could have other formats. > I'm not sure you can standardize them all -- there are an infinite > number of valid Type-Ps. Stanislav will no doubt comment more > cogently on the topic, since he's been actively working on owamp > development. I haven't recently... so I need to re-read the > current draft in detail. > > --Matt > > --On Thursday, July 18, 2002 7:39 AM +0200 Emile Stephan > wrote: > > > Hi Matt, > > > > regarding the timestamp definition i proposed, > > actually it try to mixes a SMIv2 TEXTUAL CONVENTION > > which describe a UTC time (with local time offset) and > > NTP timestamp. That will be review taking in account > > the remark of Andy regarding the timefilter use. > > > > Regarding the accuracy of the timestamp, there is a > > need to a very precise timestamp for measuring per hop > > delay or ipdv of multigigabit path. I will make aother > > proposal that will take in account the measurement > > packet timestamp. I notice that the OWDP timestamp > > format has changed too. So this point is an open > > issue. > > > > Owdp proposes only one fixed packet test format. That > > point must be reconsidered. E.G.: It should be > > inserted in an RTP SDU to permit undetectable VoIp > > test packets. This effort may be done aside of OWDP. > > > > PS: having the OID of the metric encoded on less than > > 8 bytes is useful for non SNMP control protocol. > > > > regards > > Emile > > > > > > > > > > > > regards > > > > --- Matthew J Zekauskas a > > écrit : > A new version (-01) with Henk's comment and > > a bunch > >> of text > >> editing by Merike (improving my english) included is > >> now on > >> the web site. ( > >> http://www.advanced.org/IPPM/Meetings/ietf54/ ) > >> > >> --Matt > > > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > > Yahoo! Mail : http://fr.mail.yahoo.com > > > > > > > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jul 25 14:00:32 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14832 for ; Thu, 25 Jul 2002 14:00:32 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PHw2Nt023231; Thu, 25 Jul 2002 13:58:02 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PHv8Nt022770; Thu, 25 Jul 2002 13:57:09 -0400 Received: from mira-sjcd-2.cisco.com (IDENT:mirapoint@mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6PHuqhM024006; Thu, 25 Jul 2002 10:57:07 -0700 (PDT) Received: from vkankipa-nt.cisco.com (dhcp-128-107-165-55.cisco.com [128.107.165.55]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ADL88268; Thu, 25 Jul 2002 10:48:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20020725105426.01e31b10@mira-sjcd-2.cisco.com> X-Sender: vkankipa@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jul 2002 11:00:00 -0700 To: Matthew J Zekauskas From: Venkat Kankipati Subject: Re: [ippm] test packet size over IP network Cc: raymond zhang , ippm@advanced.org In-Reply-To: <921127671.1027600505@localhost> References: <5.1.0.14.0.20020725085250.026c7810@delta.info.net> <5.1.0.14.0.20020725085250.026c7810@delta.info.net> 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 List-Id: IETF IP Performance Metrics Working Group List At 12:35 PM 7/25/02 -0400, Matthew J Zekauskas wrote: >>I wonder if anyone can provide some references or input in selecting test >>packet size for measuring one-way-delay. > >draft-ietf-ippm-owmetric-as-00.txt is a (very) initial attempt to try to >address this, among other issues. > >As always, "it depends on what you are trying to measure". > >I can tell you what the two systems I know well do. The Surveyor system >used minimal-sized UDP packets, which in our case was 12 bytes (so the >physical packet size adds the UDP, IP, and any MAC header). The RIPE-TT >system used 100 byte UDP packets the last time I looked. > >The idea behind small packets was to not send significant traffic, and just >get a broad overview of the network's health. > >I'd be interested in what other vendors use and why (I know there are >a few on the list). We, at Cisco, have a performance monitoring feature in IOS (currently being used by a large customer base) which consists of probes which can measure performance for various domains (web server, voip networks, etc). Depending on the probe type, our measurement packet size varies but we do provide the option for users to configure the packet sizes (payload). Thanks, Venkat >--Matt >_______________________________________________ >ippm mailing list >ippm@advanced.org >http://mailhost.advanced.org/mailman/listinfo/ippm Venkat Kankipati Manager, Software Development IOS Engineering (IOS Technology Division) Cisco Systems, Inc. vkankipa@cisco.com / 408.527.9269 _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jul 25 14:47:16 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16840 for ; Thu, 25 Jul 2002 14:47:16 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PIh4Nt002246; Thu, 25 Jul 2002 14:43:04 -0400 Received: from sa.infonet.com (sa.infonet.com [192.157.130.21]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6PHsYNt021370; Thu, 25 Jul 2002 13:54:35 -0400 Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id g6PHsYd01715; Thu, 25 Jul 2002 17:54:34 GMT Received: from zhangr2.info.net (sfjl13.us.info.net [204.79.139.13]) by delta.info.net with ESMTP id RAA21410; Thu, 25 Jul 2002 17:54:33 GMT Message-Id: <5.1.0.14.0.20020725104538.00abce10@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Jul 2002 10:54:23 -0700 To: Matthew J Zekauskas From: raymond zhang Subject: Re: [ippm] test packet size over IP network Cc: ippm@advanced.org In-Reply-To: <921127671.1027600505@localhost> References: <5.1.0.14.0.20020725085250.026c7810@delta.info.net> <5.1.0.14.0.20020725085250.026c7810@delta.info.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List At 12:35 PM 7/25/2002 -0400, you wrote: >>I wonder if anyone can provide some references or input in selecting test >>packet size for measuring one-way-delay. > >draft-ietf-ippm-owmetric-as-00.txt is a (very) initial attempt to try to >address this, among other issues. > >As always, "it depends on what you are trying to measure". > >I can tell you what the two systems I know well do. The Surveyor system >used minimal-sized UDP packets, which in our case was 12 bytes (so the >physical packet size adds the UDP, IP, and any MAC header). The RIPE-TT >system used 100 byte UDP packets the last time I looked. > >The idea behind small packets was to not send significant traffic, and just >get a broad overview of the network's health. If this is the goal, then the smaller test probe packets seems to be a better choice without putting whole of traffic over the network. Private IP networks seem to have bigger average packet sizes than ones in the public internet so 64 byte packet may be too small so 100 byte (including payload, udp and ip) seems to be the balance. >I'd be interested in what other vendors use and why (I know there are >a few on the list). >' I'd also be interested in what other SPs use as well... >--Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 26 01:04:31 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29770 for ; Fri, 26 Jul 2002 01:04:30 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6Q523Nt030379; Fri, 26 Jul 2002 01:02:03 -0400 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6Q51qNt030061; Fri, 26 Jul 2002 01:01:52 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6Q53xW18413; Fri, 26 Jul 2002 08:03:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Jul 2002 08:01:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 08:01:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ippm] test packet size over IP network Date: Fri, 26 Jul 2002 08:01:41 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757019F6C9C@esebe004.NOE.Nokia.com> Thread-Topic: [ippm] test packet size over IP network Thread-Index: AcI0DE+aXBR2K95uTA+aYTJwUKvJJAAU3ecw From: To: , Cc: X-OriginalArrivalTime: 26 Jul 2002 05:01:42.0192 (UTC) FILETIME=[883C4B00:01C23461] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g6Q51qNt030061 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit Hi, just to provide a further viewpoint in addition to the previous answers: small packet sizes are probably desirable for generic one-way delay tests, whereas a larger packet size may give useful information about performance for a particular application. This issue has been mentioned in the "periodic measurements" (npmps) draft. The two approaches are complementary to each other, and may have different uses. For example, most of the test streams may be performed with Poisson sampling and small packet sizes, but occasionally an "application level performance" test can be conducted with regular test packet spacing & packet size corresponding to a VoIP codec, for example. BR, Vilho > -----Original Message----- > From: ext raymond zhang [mailto:zhangr@info.net] > Sent: 25 July 2002 20:54 > To: Matthew J Zekauskas > Cc: ippm@advanced.org > Subject: Re: [ippm] test packet size over IP network > > > At 12:35 PM 7/25/2002 -0400, you wrote: > >>I wonder if anyone can provide some references or input in > selecting test > >>packet size for measuring one-way-delay. > > > >draft-ietf-ippm-owmetric-as-00.txt is a (very) initial > attempt to try to > >address this, among other issues. > > > >As always, "it depends on what you are trying to measure". > > > >I can tell you what the two systems I know well do. The > Surveyor system > >used minimal-sized UDP packets, which in our case was 12 > bytes (so the > >physical packet size adds the UDP, IP, and any MAC header). > The RIPE-TT > >system used 100 byte UDP packets the last time I looked. > > > >The idea behind small packets was to not send significant > traffic, and just > >get a broad overview of the network's health. > > If this is the goal, then the smaller test probe packets > seems to be a > better choice without putting whole of traffic over the > network. Private > IP networks seem to have bigger average packet sizes than ones in the > public internet so 64 byte packet may be too small so 100 > byte (including > payload, udp and ip) seems to be the balance. > > > >I'd be interested in what other vendors use and why (I know there are > >a few on the list). > >' > > > I'd also be interested in what other SPs use as well... > > > >--Matt > > > _______________________________________________ > 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 Fri Jul 26 03:27:01 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11117 for ; Fri, 26 Jul 2002 03:27:01 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6Q7O2Nt019089; Fri, 26 Jul 2002 03:24:02 -0400 Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6Q7NvNt018994 for ; Fri, 26 Jul 2002 03:23:58 -0400 Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 09:23:56 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ippm] test packet size over IP network X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 26 Jul 2002 09:23:56 +0200 Message-ID: Thread-Topic: [ippm] test packet size over IP network Thread-Index: AcI0DGhWdfgg+VlzTJ2MzSP3Jdmm1AAaLRJQ From: "STEPHAN Emile FTRD/DAC/LAN" To: X-OriginalArrivalTime: 26 Jul 2002 07:23:56.0703 (UTC) FILETIME=[673352F0:01C23475] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g6Q7NvNt018994 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit As far as I am concern you have to use packets sizes corresponding to those send by the application monitored. regards emile > -----Message d'origine----- > De : raymond zhang [mailto:zhangr@info.net] > Envoye : jeudi 25 juillet 2002 19:54 > A : Matthew J Zekauskas > Cc : ippm@advanced.org > Objet : Re: [ippm] test packet size over IP network > > > At 12:35 PM 7/25/2002 -0400, you wrote: > >>I wonder if anyone can provide some references or input in > selecting test > >>packet size for measuring one-way-delay. > > > >draft-ietf-ippm-owmetric-as-00.txt is a (very) initial > attempt to try to > >address this, among other issues. > > > >As always, "it depends on what you are trying to measure". > > > >I can tell you what the two systems I know well do. The > Surveyor system > >used minimal-sized UDP packets, which in our case was 12 > bytes (so the > >physical packet size adds the UDP, IP, and any MAC header). > The RIPE-TT > >system used 100 byte UDP packets the last time I looked. > > > >The idea behind small packets was to not send significant > traffic, and just > >get a broad overview of the network's health. > > If this is the goal, then the smaller test probe packets > seems to be a > better choice without putting whole of traffic over the > network. Private > IP networks seem to have bigger average packet sizes than ones in the > public internet so 64 byte packet may be too small so 100 > byte (including > payload, udp and ip) seems to be the balance. > > > >I'd be interested in what other vendors use and why (I know there are > >a few on the list). > >' > > > I'd also be interested in what other SPs use as well... > > > >--Matt > > > _______________________________________________ > 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 Fri Jul 26 04:16:38 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11726 for ; Fri, 26 Jul 2002 04:16:38 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6Q874Nt024452; Fri, 26 Jul 2002 04:07:04 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6Q866Nt024234 for ; Fri, 26 Jul 2002 04:06:07 -0400 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g6Q865lQ031922; Fri, 26 Jul 2002 10:06:05 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.11.6/8.11.6) with ESMTP id g6Q865m00991; Fri, 26 Jul 2002 10:06:05 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 26 Jul 2002 10:06:05 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN cc: ippm@advanced.org Subject: RE: [ippm] test packet size over IP network In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-104.1 required=15.0 tests=IN_REP_TO,X_AUTH_WARNING,USER_IN_WHITELIST version=2.31 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Fri, 26 Jul 2002, STEPHAN Emile FTRD/DAC/LAN wrote: > As far as I am concern you have to use packets sizes corresponding to > those send by the application monitored. Well, yes and no. The first question is how the network treats big and small packets. When I first started to compare results from Surveyor (40 bytes back then) and our TTM service (100 bytes), I discovered a difference even when both systems measured along the same path. Further investigation showed that the delay a packet takes scales as (as expected): d_0 + B/T with B the size in bytes, for B smaller than the MTU (at which point packets are either fragmented or dropped), d_0 the delay that a packet of 0 bytes would take, and T the throughput of the connection. If this is the case, then there is no reason to vary the packet size for one-way-delay measurements. In fact, it only makes it harder to analyze the data afterwards and/or use it for derived metrics such as IPDV, where all packets have to be of the same size. Most applications send packets of variable size. In case one wants to know the delay distribution for this application, use packet sampling to determine the distribution of the packets sent by this application. Then take the delay distribution for fixed size packets. Then convolute the two. This is fairly straightforward. The opposite operation isn't. However, one of my customers mentioned that in the very recent optical fiber equipment he is using, it appeared as if small packets get preferential treatement over big packets (presumably because it helps overall performance if small ACK packets arrive as fast as possible, while big chunks of data can wait a bit). In this case, it does make sense to do measurements with 2 (or more) sizes, one smaller and one bigger than the threshold for preferential treatement. I haven't been able to verify this claim myself though. BTW. For the draft, I'm still interested to hear what people use and why. Henk > regards > emile > > > -----Message d'origine----- > > De : raymond zhang [mailto:zhangr@info.net] > > Envoye : jeudi 25 juillet 2002 19:54 > > A : Matthew J Zekauskas > > Cc : ippm@advanced.org > > Objet : Re: [ippm] test packet size over IP network > > > > > > At 12:35 PM 7/25/2002 -0400, you wrote: > > >>I wonder if anyone can provide some references or input in > > selecting test > > >>packet size for measuring one-way-delay. > > > > > >draft-ietf-ippm-owmetric-as-00.txt is a (very) initial > > attempt to try to > > >address this, among other issues. > > > > > >As always, "it depends on what you are trying to measure". > > > > > >I can tell you what the two systems I know well do. The > > Surveyor system > > >used minimal-sized UDP packets, which in our case was 12 > > bytes (so the > > >physical packet size adds the UDP, IP, and any MAC header). > > The RIPE-TT > > >system used 100 byte UDP packets the last time I looked. > > > > > >The idea behind small packets was to not send significant > > traffic, and just > > >get a broad overview of the network's health. > > > > If this is the goal, then the smaller test probe packets > > seems to be a > > better choice without putting whole of traffic over the > > network. Private > > IP networks seem to have bigger average packet sizes than ones in the > > public internet so 64 byte packet may be too small so 100 > > byte (including > > payload, udp and ip) seems to be the balance. > > > > > > >I'd be interested in what other vendors use and why (I know there are > > >a few on the list). > > >' > > > > > > I'd also be interested in what other SPs use as well... > > > > > > >--Matt > > > > > > _______________________________________________ > > 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 > ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk@ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 26 07:37:53 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14860 for ; Fri, 26 Jul 2002 07:37:52 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6QBa3Nt023022; Fri, 26 Jul 2002 07:36:03 -0400 Received: from mailhost.iitb.ac.in (mailhost.iitb.ac.in [203.197.74.142]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with SMTP id g6QBZ9Nt022833 for ; Fri, 26 Jul 2002 07:35:10 -0400 Received: (qmail 28289 invoked from network); 26 Jul 2002 11:35:07 -0000 Received: from mailscan1.iitb.ac.in (HELO thisdomain) (144.16.108.201) by mailhost.iitb.ac.in with SMTP; 26 Jul 2002 11:35:07 -0000 Received: from bhairav.ee.iitb.ac.in by iitb.ac.in ; Fri, 26 Jul 2002 17:05:02 +0530 Date: Fri, 26 Jul 2002 17:05:02 +0530 X-Originating-IP: 144.16.100.100 X-Auth-User: balaji@ee.iitb.ac.in Received: from brahmi.ee.iitb.ac.in (sharada.ee.iitb.ac.in [144.16.100.126]) by bhairav.ee.iitb.ac.in (8.12.4/8.12.4) with ESMTP id g6QBYtVP003124; Fri, 26 Jul 2002 17:04:56 +0530 (IST) Received: from localhost (balaji@localhost) by brahmi.ee.iitb.ac.in (8.11.6/8.11.6) with ESMTP id g6QBVXT06974; Fri, 26 Jul 2002 17:01:34 +0530 X-Authentication-Warning: brahmi.ee.iitb.ac.in: balaji owned process doing -bs Date: Fri, 26 Jul 2002 17:01:33 +0530 (IST) From: "Balaji H. Kasal" To: vilho.raisanen@nokia.com cc: zhangr@info.net, , Subject: RE: [ippm] test packet size over IP network In-Reply-To: <009CA59D1752DD448E07F8EB2F911757019F6C9C@esebe004.NOE.Nokia.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 List-Id: IETF IP Performance Metrics Working Group List Dear friends, There is no single packet size which can be used for measurement, bec' of large variation in packet sizes in Internet. To study true application performance one should use different packet sizes and find out the distribution. (That was most appl does... streaming...) Ofcourse, it is not smart to probe large packets of different sizes for measurement. One can findout "optimal" packet size for measurement. We can define "optimal" packet size which represents (almost... median???) overall distribution. With Best Wishes, --Balaji On Fri, 26 Jul 2002 vilho.raisanen@nokia.com wrote: > Hi, > > just to provide a further viewpoint in addition to the previous answers: small packet sizes are probably desirable for generic one-way delay tests, whereas a larger packet size may give useful information about performance for a particular application. This issue has been mentioned in the "periodic measurements" (npmps) draft. > > The two approaches are complementary to each other, and may have different uses. For example, most of the test streams may be performed with Poisson sampling and small packet sizes, but occasionally an "application level performance" test can be conducted with regular test packet spacing & packet size corresponding to a VoIP codec, for example. > > BR, > Vilho > > > -----Original Message----- > > From: ext raymond zhang [mailto:zhangr@info.net] > > Sent: 25 July 2002 20:54 > > To: Matthew J Zekauskas > > Cc: ippm@advanced.org > > Subject: Re: [ippm] test packet size over IP network > > > > > > At 12:35 PM 7/25/2002 -0400, you wrote: > > >>I wonder if anyone can provide some references or input in > > selecting test > > >>packet size for measuring one-way-delay. > > > > > >draft-ietf-ippm-owmetric-as-00.txt is a (very) initial > > attempt to try to > > >address this, among other issues. > > > > > >As always, "it depends on what you are trying to measure". > > > > > >I can tell you what the two systems I know well do. The > > Surveyor system > > >used minimal-sized UDP packets, which in our case was 12 > > bytes (so the > > >physical packet size adds the UDP, IP, and any MAC header). > > The RIPE-TT > > >system used 100 byte UDP packets the last time I looked. > > > > > >The idea behind small packets was to not send significant > > traffic, and just > > >get a broad overview of the network's health. > > > > If this is the goal, then the smaller test probe packets > > seems to be a > > better choice without putting whole of traffic over the > > network. Private > > IP networks seem to have bigger average packet sizes than ones in the > > public internet so 64 byte packet may be too small so 100 > > byte (including > > payload, udp and ip) seems to be the balance. > > > > > > >I'd be interested in what other vendors use and why (I know there are > > >a few on the list). > > >' > > > > > > I'd also be interested in what other SPs use as well... > > > > > > >--Matt > > > > > > _______________________________________________ > > 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 > -- Regards, --Balaji _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 26 08:20:17 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16340 for ; Fri, 26 Jul 2002 08:20:16 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6QCH2Nt029242; Fri, 26 Jul 2002 08:17:02 -0400 Received: from strange-brew.cisco.com (weird-brew.cisco.com [144.254.15.118]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6QCGoNt028976; Fri, 26 Jul 2002 08:16:51 -0400 Received: from banana.cisco.com (banana.cisco.com [144.254.14.18]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g6QCGXh28850; Fri, 26 Jul 2002 14:16:33 +0200 (CEST) Subject: RE: [ippm] test packet size over IP network From: Emmanuel Tychon To: "Balaji H. Kasal" Cc: vilho.raisanen@nokia.com, zhangr@info.net, matt@advanced.org, ippm@advanced.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Jul 2002 14:16:33 +0200 Message-Id: <1027685793.1119.44.camel@banana> Mime-Version: 1.0 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit On Fri, 2002-07-26 at 13:31, Balaji H. Kasal wrote: > Of course, it is not smart to probe large packets of different sizes for > measurement. One can findout "optimal" packet size for measurement. We can > define "optimal" packet size which represents (almost... median???) > overall distribution. I guess that what IMIX distribution[1] try to do. This represents, based on observation, a best model of today's internet most frequent packet size. This is not the panacea, but it's quite interesting anyway. [1] http://advanced.comms.agilent.com/RouterTester/member/journal/1MxdPktSzThroughput.html e. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 26 11:20:46 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24909 for ; Fri, 26 Jul 2002 11:20:46 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6QFI4Nt003571; Fri, 26 Jul 2002 11:18:04 -0400 Received: from hermes.aston.ac.uk (hermes.aston.ac.uk [134.151.79.46]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6Q8tBNt031167 for ; Fri, 26 Jul 2002 04:55:12 -0400 Received: from [134.151.16.72] (helo=lib01pc08) by hermes.aston.ac.uk with smtp (Exim 3.30 #1) id 17Y0sP-0003uG-00 for ippm@advanced.org; Fri, 26 Jul 2002 09:55:09 +0100 Comments: Authenticated sender is From: "mokranis" Organization: aston.ac.uk To: ippm@advanced.org Date: Fri, 26 Jul 2002 09:55:07 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: mokranis@aston.ac.uk Priority: normal X-mailer: Pegasus Mail for Windows (v2.54) Message-Id: Subject: [ippm] Gnutella modelisation Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7BIT Hi all I try to modelise Gnutella (using ns-2). I need to find some statistical models of the internet in order to make some bandwidth measurement. In oher word, is there any good models of the internet ??? If yes any web address or books? _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 26 14:58:07 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04335 for ; Fri, 26 Jul 2002 14:58:07 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6QIu3Nt027484; Fri, 26 Jul 2002 14:56:03 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6QItENt027043 for ; Fri, 26 Jul 2002 14:55:14 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 972A25EE44; Fri, 26 Jul 2002 14:55:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 5C8155ECEF; Fri, 26 Jul 2002 14:55:13 -0400 (EDT) To: "Balaji H. Kasal" Cc: ippm@advanced.org Subject: Re: [ippm] test packet size over IP network References: From: stanislav shalunov Date: 26 Jul 2002 14:55:56 -0400 In-Reply-To: Message-ID: <87it32z5c3.fsf@cain.internet2.edu> Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "Balaji H. Kasal" writes: > We can define "optimal" packet size which represents > (almost... median???) overall distribution. 1. The distribution of packet sizes is different for different networks. 2. The distribution of packet sizes changes over time. 3. What do you care about delay of a median-sized packet if your packets are twice larger (or smaller)? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "You wake me up early in the morning to tell me I am right? Please wait until I am wrong." -- John von Neumann, on being phoned at 10 a.m. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jul 26 15:03:27 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04499 for ; Fri, 26 Jul 2002 15:03:27 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6QIx3Nt028400; Fri, 26 Jul 2002 14:59:03 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6QIwNNt028279 for ; Fri, 26 Jul 2002 14:58:23 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 5FC045EE44; Fri, 26 Jul 2002 14:58:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 7CAF95ECEF; Fri, 26 Jul 2002 14:58:22 -0400 (EDT) To: "Henk Uijterwaal (RIPE-NCC)" Cc: ippm@advanced.org Subject: Re: [ippm] test packet size over IP network References: From: stanislav shalunov Date: 26 Jul 2002 14:59:06 -0400 In-Reply-To: Message-ID: <87fzy6z56t.fsf@cain.internet2.edu> Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > d_0 + B/T A note: Some line cards designs have buffer pools of different sizes. This can lead to loss being different for different packet size. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ All revolutions are bloody. The October Revolution was bloodless, but it was only the beginning. -- Dmitri Volkogonov _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 05:19:47 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18762 for ; Wed, 31 Jul 2002 05:19:47 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6V9E3Nt001548; Wed, 31 Jul 2002 05:14:03 -0400 Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6V9DtNt001448 for ; Wed, 31 Jul 2002 05:13:56 -0400 Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 31 Jul 2002 11:13:54 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 31 Jul 2002 11:13:54 +0200 Message-ID: Thread-Topic: [ippm] test packet size over IP network Thread-Index: AcI0DGhWdfgg+VlzTJ2MzSP3Jdmm1AAaLRJQAOZybMA= From: "STEPHAN Emile FTRD/DAC/LAN" To: Cc: X-OriginalArrivalTime: 31 Jul 2002 09:13:54.0719 (UTC) FILETIME=[97FD6AF0:01C23872] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g6V9DtNt001448 Subject: [ippm] Synchonization state: consistency among owdp and ippm mib Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit Hi Stanislav, all Regarding the clock with "no notion of external synchronization for the time source (e.g., a cesium oscillator is used directly)" what may be the corresponding state ? are there other states to discuss now(e.g. such as 'fail') ? ippmSynchonizationState OBJECT-TYPE SYNTAX INTEGER { other(0), unsynchronized(1), initializing(2), synchronized(4) } MAX-ACCESS read-only STATUS current DESCRIPTION " ippmSynchonizationState describes the state of the clock synchronization. Other(0) The status of the synchronization is unknown. unsynchronized(1) The system is not synchronized. initializing(2) The system is receiving synchronization information but is not yet synchronized. synchronized(4) The system is synchronized. " regards Emile _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 08:55:13 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24278 for ; Wed, 31 Jul 2002 08:55:13 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VCq2Nt001219; Wed, 31 Jul 2002 08:52:02 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VCpRNt000785 for ; Wed, 31 Jul 2002 08:51:28 -0400 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g6VCpMlQ031959; Wed, 31 Jul 2002 14:51:22 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.11.6/8.11.6) with ESMTP id g6VCpLI11817; Wed, 31 Jul 2002 14:51:21 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 31 Jul 2002 14:51:21 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN cc: ippm@advanced.org, Subject: Re: [ippm] Synchonization state: consistency among owdp and ippm mib In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: NONE ; -1041 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Emile, others, > Regarding the clock with "no notion of external synchronization for the > time source (e.g., a cesium oscillator is used directly)" what may be > the corresponding state ? I'd think that the condition for synchronized is that the clocks on both sending and receiving end are synchronized to one and the same source, and it is thus impossible for one to drift away from the other. So, a cesium clock connected to a PC but not to anything else, is unsynchronized, a cesium clock connected to a PC and to (say) a clock at a standards institute, is synchronized. > are there other states to discuss now(e.g. such as 'fail') ? Isn't this implementation dependent? For the MIB/OWDP, we need 3 states: * Unsynchronized * Synchronized * Other Other covering any state not being synchronized or unsynchronized, leaving it up to the implementor to decide what to do next. I don't think that there is a need for a "initializing" state, it is too generic and the behaviour of the clock during initialization varies from one hardware vendor to the other. Or to be more precise, for our equipment, we use GPS clocks from 2 different vendors and they behave completely different from the moment they are switched on until they have synchronized themselves. The same happens when something goes wrong (for example, the cable antenna is cut). Henk > > ippmSynchonizationState OBJECT-TYPE > SYNTAX INTEGER { > other(0), > unsynchronized(1), > initializing(2), > synchronized(4) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > " ippmSynchonizationState describes the state of the clock > synchronization. > > > Other(0) > The status of the synchronization is unknown. > > unsynchronized(1) > The system is not synchronized. > > initializing(2) > The system is receiving synchronization information but is not yet > synchronized. > > synchronized(4) > The system is synchronized. > " > > regards > Emile > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk@ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 11:43:52 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03220 for ; Wed, 31 Jul 2002 11:43:52 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VFg4Nt018357; Wed, 31 Jul 2002 11:42:04 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VFfjNt018263 for ; Wed, 31 Jul 2002 11:41:45 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 3E1735EE1A; Wed, 31 Jul 2002 11:41:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 721C75ED24; Wed, 31 Jul 2002 11:41:44 -0400 (EDT) To: "STEPHAN Emile FTRD/DAC/LAN" Cc: Subject: Re: [ippm] Synchonization state: consistency among owdp and ippm mib References: From: stanislav shalunov Date: 31 Jul 2002 11:42:21 -0400 In-Reply-To: Message-ID: <87wurbj44i.fsf@cain.internet2.edu> Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "STEPHAN Emile FTRD/DAC/LAN" writes: > Regarding the clock with "no notion of external synchronization for the > time source (e.g., a cesium oscillator is used directly)" what may be > the corresponding state ? Currently, draft-ietf-ippm-owdp-04.txt recommends to set the `synchronized' bit for sources of time that do not have a notion of synchronization -- so it would be the `synchronized(4)' state in your case. (Maybe draft-ietf-ippm-owdp-04.txt needs to be changed in this respect.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at sea level. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 11:46:40 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03420 for ; Wed, 31 Jul 2002 11:46:39 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VFj4Nt019349; Wed, 31 Jul 2002 11:45:04 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VFioNt019231 for ; Wed, 31 Jul 2002 11:44:50 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 1E5F25EE1A; Wed, 31 Jul 2002 11:44:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 28F0E5ED24; Wed, 31 Jul 2002 11:44:49 -0400 (EDT) To: "Henk Uijterwaal (RIPE-NCC)" Cc: ippm@advanced.org Subject: Re: [ippm] Synchonization state: consistency among owdp and ippm mib References: From: stanislav shalunov Date: 31 Jul 2002 11:45:34 -0400 In-Reply-To: Message-ID: <87u1mfj3z5.fsf@cain.internet2.edu> Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > I'd think that the condition for synchronized is that the clocks on > both sending and receiving end are synchronized to one and the same > source, and it is thus impossible for one to drift away from the > other. How can a sender possibly know where the receiver gets its time? > So, a cesium clock connected to a PC but not to anything else, is > unsynchronized, a cesium clock connected to a PC and to (say) a > clock at a standards institute, is synchronized. Cesium oscillators, being the current definition of time, can only drift with respect to each other due to relativistic effects, right? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Al your Qaeda are belong to US. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 12:46:03 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06347 for ; Wed, 31 Jul 2002 12:46:03 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VGg3Nt011657; Wed, 31 Jul 2002 12:42:03 -0400 Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VGfpNt011516 for ; Wed, 31 Jul 2002 12:41:51 -0400 Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 31 Jul 2002 18:41:50 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C238B1.2AFC9E3A" Subject: [ippm] Synchonization state: 'initializing' X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 31 Jul 2002 18:41:50 +0200 Message-ID: Thread-Topic: [ippm] Synchonization state: 'initializing' Thread-Index: AcI4sSpllSAAIs0gQ1exJUO8MK4liQ== From: "STEPHAN Emile FTRD/DAC/LAN" To: Cc: X-OriginalArrivalTime: 31 Jul 2002 16:41:50.0671 (UTC) FILETIME=[2B4E3DF0:01C238B1] Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. ------_=_NextPart_001_01C238B1.2AFC9E3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Henk, others, Management systems need generic state to decide when the measure issued = from the probes may be used or not to compute trustable results. the 'initializing' state is generic enough to describe that they are not = yet synchrnized and that they consider to gain the synchronized state = soon.=20 The 'fail' state may be usesul to provide to the system of measure with = the fact that the after a while the 'synchronized' state has not be = reach and that perhaps the GPS signal does not reach the probe. regards emile ------_=_NextPart_001_01C238B1.2AFC9E3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [ippm] Synchonization state: 'initializing'

Henk, others,

        Management systems need generic state to decide = when the measure issued from the probes may be used or not to compute = trustable results.

the 'initializing' state is = generic enough to describe that they are not yet synchrnized and that = they consider to gain the synchronized state soon.

The 'fail' state may be usesul to = provide to the system of measure with the fact that the after a while = the 'synchronized' state has not be reach and that perhaps the GPS = signal does not reach the probe.


regards
emile


------_=_NextPart_001_01C238B1.2AFC9E3A-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 12:47:37 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06442 for ; Wed, 31 Jul 2002 12:47:36 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VGj4Nt013935; Wed, 31 Jul 2002 12:45:04 -0400 Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VGiYNt013648 for ; Wed, 31 Jul 2002 12:44:35 -0400 Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 31 Jul 2002 18:44:34 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ippm] Synchonization state or type ? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 31 Jul 2002 18:44:33 +0200 Message-ID: Thread-Topic: [ippm] Synchonization state: consistency among owdp and ippm mib Thread-Index: AcI4qMemAzb1VAk/QBmDE4+r6Rtt5QACHJ6A From: "STEPHAN Emile FTRD/DAC/LAN" To: "stanislav shalunov" Cc: X-OriginalArrivalTime: 31 Jul 2002 16:44:34.0296 (UTC) FILETIME=[8CD56F80:01C238B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g6VGiYNt013648 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit perhaps a state or a type of synchronisation 'localClock' permit to differentiate such clock from others ? emile > -----Message d'origine----- > De : stanislav shalunov [mailto:shalunov@internet2.edu] > Envoye : mercredi 31 juillet 2002 17:42 > A : STEPHAN Emile FTRD/DAC/LAN > Cc : ippm@advanced.org > Objet : Re: [ippm] Synchonization state: consistency among > owdp and ippm > mib > > > "STEPHAN Emile FTRD/DAC/LAN" > writes: > > > Regarding the clock with "no notion of external > synchronization for the > > time source (e.g., a cesium oscillator is used directly)" > what may be > > the corresponding state ? > > Currently, draft-ietf-ippm-owdp-04.txt recommends to set the > `synchronized' bit for sources of time that do not have a notion of > synchronization -- so it would be the `synchronized(4)' state in your > case. > > (Maybe draft-ietf-ippm-owdp-04.txt needs to be changed in > this respect.) > > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > This message is designed to be viewed at sea level. > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 14:55:00 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13161 for ; Wed, 31 Jul 2002 14:55:00 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VIr4Nt018349; Wed, 31 Jul 2002 14:53:04 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VIqONt018248 for ; Wed, 31 Jul 2002 14:52:25 -0400 Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g6VIqOlQ018727; Wed, 31 Jul 2002 20:52:24 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.11.6/8.10.2) with ESMTP id g6VIqOM06256; Wed, 31 Jul 2002 20:52:24 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Wed, 31 Jul 2002 20:52:24 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: stanislav shalunov cc: ippm@advanced.org Subject: Re: [ippm] Synchonization state: consistency among owdp and ippm mib In-Reply-To: <87u1mfj3z5.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: NONE ; -1041 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On 31 Jul 2002, stanislav shalunov wrote: > "Henk Uijterwaal (RIPE-NCC)" writes: > > > I'd think that the condition for synchronized is that the clocks on > > both sending and receiving end are synchronized to one and the same > > source, and it is thus impossible for one to drift away from the > > other. > > How can a sender possibly know where the receiver gets its time? Without a separate communication channel, it can't. However, to implement this, I'd put a flag in the packet when it is sent indicating the status of the clock at the sender. The packet is then received by the receiver, the receiver looks at its clock and tags the packet accordingly: both clock synchronized so a valid (delay) measurement, one or two clocks unsynchronized and a non-valid (delay) measurement. > > > So, a cesium clock connected to a PC but not to anything else, is > > unsynchronized, a cesium clock connected to a PC and to (say) a > > clock at a standards institute, is synchronized. > > Cesium oscillators, being the current definition of time, can only > drift with respect to each other due to relativistic effects, right? I've no idea what would happen if I switched off my cesium clock and switched it on later. (And yes, that is a silly thing to do). The flag just says "I'm synchronized". Now, a cesium clock needs perhaps one calibration cycle in its life and a cheap GPS receiver a constant signal but that is up to the implementation. 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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk@ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 15:07:23 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13716 for ; Wed, 31 Jul 2002 15:07:22 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VJ44Nt022125; Wed, 31 Jul 2002 15:04:04 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VJ3TNt021151 for ; Wed, 31 Jul 2002 15:03:30 -0400 Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g6VJ3TlQ021379; Wed, 31 Jul 2002 21:03:29 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.11.6/8.10.2) with ESMTP id g6VJ3Sh06490; Wed, 31 Jul 2002 21:03:29 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Wed, 31 Jul 2002 21:03:28 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN cc: ippm@advanced.org Subject: Re: [ippm] Synchonization state: 'initializing' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: NONE ; -1041 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Emile, > Management systems need generic state to decide when the measure > issued from the probes may be used or not to compute trustable results. > > the 'initializing' state is generic enough to describe that they are not > yet synchrnized and that they consider to gain the synchronized state > soon. Define "soon". Depending on conditions, the various GPS clock can initialize in a few minutes to half an hour (and it might take longer to synchronize the PC clock). Now, suppose I have such hardware and want to do an operation measurement now, what does init tell me? > The 'fail' state may be usesul to provide to the system of measure with > the fact that the after a while the 'synchronized' state has not be > reach and that perhaps the GPS signal does not reach the probe. For a reporting system, I think it is sufficient to monitor "synchronized" over time, if a clock is unsynchronized for a long time, then one has to log in to the device and look at what is going wrong. (For example, has somebody unplugged a cable, switched of the power supply, did lightning struck, did somebody trip over the antenna while doing repair works on the roof). A single bit doesn't tell you anything useful here, 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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk@ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jul 31 15:17:50 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14140 for ; Wed, 31 Jul 2002 15:17:50 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VJD3Nt024952; Wed, 31 Jul 2002 15:13:03 -0400 Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VJCZNt024843 for ; Wed, 31 Jul 2002 15:12:36 -0400 Received: from RHOLLEYW2K1 (rtp-vpn1-57.cisco.com [10.82.224.57]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA28840; Wed, 31 Jul 2002 15:12:33 -0400 (EDT) From: "Robert Holley" To: "Henk Uijterwaal \(RIPE-NCC\)" , "stanislav shalunov" Cc: Subject: RE: [ippm] Synchonization state: consistency among owdp and ippm mib Date: Wed, 31 Jul 2002 15:12:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The sender can know where the reciever gets it time source. The information is maintained in the NTP MIB. This may be accessed by the "separate communication channel" reference in the thread below. FYI, here is a link to a whitepaper on NTP deployment and configurations. http://cisco.com/warp/public/126/ntpm.html regards Bob Holley > -----Original Message----- > From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf > Of Henk Uijterwaal (RIPE-NCC) > Sent: Wednesday, July 31, 2002 2:52 PM > To: stanislav shalunov > Cc: ippm@advanced.org > Subject: Re: [ippm] Synchonization state: consistency among owdp and > ippm mib > > > On 31 Jul 2002, stanislav shalunov wrote: > > > "Henk Uijterwaal (RIPE-NCC)" writes: > > > > > I'd think that the condition for synchronized is that the clocks on > > > both sending and receiving end are synchronized to one and the same > > > source, and it is thus impossible for one to drift away from the > > > other. > > > > How can a sender possibly know where the receiver gets its time? > > Without a separate communication channel, it can't. > > However, to implement this, I'd put a flag in the packet when it is sent > indicating the status of the clock at the sender. The packet is then > received by the receiver, the receiver looks at its clock and tags the > packet accordingly: both clock synchronized so a valid (delay) > measurement, one or two clocks unsynchronized and a non-valid (delay) > measurement. > > > > > > So, a cesium clock connected to a PC but not to anything else, is > > > unsynchronized, a cesium clock connected to a PC and to (say) a > > > clock at a standards institute, is synchronized. > > > > Cesium oscillators, being the current definition of time, can only > > drift with respect to each other due to relativistic effects, right? > > I've no idea what would happen if I switched off my cesium clock and > switched it on later. (And yes, that is a silly thing to do). > > The flag just says "I'm synchronized". Now, a cesium clock needs perhaps > one calibration cycle in its life and a cheap GPS receiver a constant > signal but that is up to the implementation. > > 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 > ------------------------------------------------------------------ > ------------ > > That problem that we weren't having yesterday, is it better? (Big ISP NOC) > > NOTE: My email address (and a hole in our mailing list software) is being > abused by a spammer. We are working on fixing this hole > and tracking > the spammer down. If you receive mail from "henk@ripe.net" that is > obviously spam, please send me a copy of the mail including > ALL headers. > I'm sorry for any inconvenience caused by this. > > _______________________________________________ > 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 Jul 31 15:26:06 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14460 for ; Wed, 31 Jul 2002 15:26:05 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VJL3Nt028308; Wed, 31 Jul 2002 15:21:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g6VJKoNt028210 for ; Wed, 31 Jul 2002 15:20:50 -0400 Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g6VJKnlQ024814; Wed, 31 Jul 2002 21:20:49 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.11.6/8.10.2) with ESMTP id g6VJKnm06772; Wed, 31 Jul 2002 21:20:49 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Wed, 31 Jul 2002 21:20:49 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Robert Holley cc: stanislav shalunov , Subject: RE: [ippm] Synchonization state: consistency among owdp and ippm mib In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: NONE ; -1030 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Wed, 31 Jul 2002, Robert Holley wrote: > > > The sender can know where the reciever gets it time source. The information > is maintained in the NTP MIB. This may be accessed by the "separate > communication channel" reference in the thread below. If you are running NTP, yes, and you don't even need a MIB for it. However, not all implementations use NTP. Henk > > FYI, here is a link to a whitepaper on NTP deployment and configurations. > > http://cisco.com/warp/public/126/ntpm.html > > regards > Bob Holley > > > -----Original Message----- > > From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf > > Of Henk Uijterwaal (RIPE-NCC) > > Sent: Wednesday, July 31, 2002 2:52 PM > > To: stanislav shalunov > > Cc: ippm@advanced.org > > Subject: Re: [ippm] Synchonization state: consistency among owdp and > > ippm mib > > > > > > On 31 Jul 2002, stanislav shalunov wrote: > > > > > "Henk Uijterwaal (RIPE-NCC)" writes: > > > > > > > I'd think that the condition for synchronized is that the clocks on > > > > both sending and receiving end are synchronized to one and the same > > > > source, and it is thus impossible for one to drift away from the > > > > other. > > > > > > How can a sender possibly know where the receiver gets its time? > > > > Without a separate communication channel, it can't. > > > > However, to implement this, I'd put a flag in the packet when it is sent > > indicating the status of the clock at the sender. The packet is then > > received by the receiver, the receiver looks at its clock and tags the > > packet accordingly: both clock synchronized so a valid (delay) > > measurement, one or two clocks unsynchronized and a non-valid (delay) > > measurement. > > > > > > > > > So, a cesium clock connected to a PC but not to anything else, is > > > > unsynchronized, a cesium clock connected to a PC and to (say) a > > > > clock at a standards institute, is synchronized. > > > > > > Cesium oscillators, being the current definition of time, can only > > > drift with respect to each other due to relativistic effects, right? > > > > I've no idea what would happen if I switched off my cesium clock and > > switched it on later. (And yes, that is a silly thing to do). > > > > The flag just says "I'm synchronized". Now, a cesium clock needs perhaps > > one calibration cycle in its life and a cheap GPS receiver a constant > > signal but that is up to the implementation. > > > > 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 > > ------------------------------------------------------------------ > > ------------ > > > > That problem that we weren't having yesterday, is it better? (Big ISP NOC) > > > > NOTE: My email address (and a hole in our mailing list software) is being > > abused by a spammer. We are working on fixing this hole > > and tracking > > the spammer down. If you receive mail from "henk@ripe.net" that is > > obviously spam, please send me a copy of the mail including > > ALL headers. > > I'm sorry for any inconvenience caused by this. > > > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > > > ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk@ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm