From test-admin@advanced.org Tue May 1 06:52:56 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22887 for ; Tue, 1 May 2001 06:52:56 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f41AqpH09427 for ; Tue, 1 May 2001 06:52:51 -0400 Date: Tue, 1 May 2001 06:52:51 -0400 Message-Id: <200105011052.f41AqpH09427@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: test-admin@advanced.org Errors-To: test-admin@advanced.org X-BeenThere: test@mailhost.advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: 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 May 2 11:37:59 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15047 for ; Wed, 2 May 2001 11:37:58 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f42Fa4H25213; Wed, 2 May 2001 11:36:04 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f42ADoH28242 for ; Wed, 2 May 2001 06:13:52 -0400 X-Authentication-Warning: mailhost.advanced.org: Host louie.udel.edu [128.175.2.33] claimed to be mail.eecis.udel.edu Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa16448; 2 May 2001 06:12 EDT Date: Wed, 2 May 2001 06:12:52 -0400 (EDT) From: Constantinos Dovrolis To: Constantinos Dovrolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] CFP ICNP 2001 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 **** Reminder: The paper submission deadline is MAY 7 **** -------------------------------------------------------------------------- CALL FOR PAPERS -------------------------------------------------------------------------- 9th International Conference on Network Protocols (ICNP 2001) Mission Inn, Riverside, California November 11-14, 2001 http://www.cis.udel.edu/icnp2001/ In just eight years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, and implementation. Protocol functions of interest include network access, switching, routing, flow and congestion control, multimedia transport, wireless and mobile networks, network security, web protocols and applications, electronic commerce, network management, interoperability, internetworking, home computing and networks and digital broadcasting. ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place filled with history. Riverside is located in the Sunny Southern California, 60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from Disney Land. The city is served by three nearby airports: Los Angeles, Ontario (California) and Orange County Airport. Topics of interest include, but are not limited to: - network access - switching - routing - flow and congestion control - multimedia transport protocols - wireless and mobile networks - network security - web protocols and applications - electronic commerce - network management - interoperability, internetworking - home computing and networking - digital broadcasting - QoS and service differentiation - network measurements - protocols for distributed games - peer-to-peer communication protocols Important Dates: Paper Submission Deadline: May 7, 2001 Tutorial Submission Deadline: May 7, 2001 Notification of Acceptance: July 13, 2001 Camera Ready Due: August 8, 2001 Tutorials: November 11, 2001 Conference: November 12 - 14, 2001 Information for authors: Papers must be written in English, and they have to be in Postscript, PDF, or Word format. The complete manuscript should be no more than 12 pages of double-spaced text with 11pt fonts. If you have any questions, you can contact us at icnp@ics.uci.edu. To register and submit your paper, visit the URL: http://violin.ics.uci.edu/~icnp/ConfMan/REG-paper/ General Chair Satish K. Tripathi, University of California - Riverside Technical Program Co-Chairs Magda El Zarki, University of California, Irvine Klara Narhstedt, University of Illinois, Urbana-Champaign Tutorial Co-Chairs Pravin Bhagwat, ReefEdge, Inc Ed Knightly, Rice University Local Arrangement and Registration Co-Chairs Michalis Faloutsos, University of California - Riverside Srikant Krishnamurthy, University of California - Riverside Publicity Co-Chairs Constantinos Dovrolis, University of Delaware Samar Singh, La Trobe University, Australia Technical Program Committee Alex Petrenko (CRIM, Computer Research Institute of Montreal) Ana Rosa CAVALLI (Institut National des Telecommunications, France) Mart, Molle (University of California, Riverside) Andrew T. Campbell (Columbia University) Bobby Bhattacharjee (University of Maryland) Christophe Diot (Sprint) Cormac J. Sreenan (University College, Cork, Ireland) David Hutchison (Lancaster University) David Su (National Institute of Standards and Technology) David, Yau (Computer Science, Purdue University) Edward Knightly (Rice University ) Ellen L. Hahne (AT&T Labs - Research) Geert Heijenk (Ericsson) Gene Tsudik (UC, Irvine) Geoffrey Xie (Naval Postgraduate School) Ernst W. Biersack (Institut EURECOM) Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden) Hartmut Koenig (BTU Cottbus, Germany Hasan Ural (University of Ottawa, Canada) Ibrahim Matta (Boston University) Jennifer Hou (Ohio State University) Jorg Lieberherr (University of Virginia) Jorge Cobb (The University of Texas at Dallas) Ken Calvert (University of Kentucky) Kevin Almeroth (UC-Santa Barbara) Kirshna Sivalingam (Washington State University / Jasmine Networks) Lars Wolf (University of Karlsruhe, Germany) Lixia Zhang (UCLA) Ljiljana Trajkovic (Simon Fraser University) Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY)) Marco Schneider (SBC Technology Resources Inc.) Martha Steenstrup (Stow Research L.L.C.) Martina Zittterbart (University of Karlsruhe, Germany) Masayuki Murata (Osaka University, Japan) Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.) Mohamed G. Gouda (University of Texas at Austin) Nalini Venkatasubramanian (University of California, Irvine) Chris Edmondson-Yurkanan (University of Texas) Ness B. Shroff (Purdue University) Nina Bhatti (Nokia) Robin Kravets (University of Illinois at Urbana-Champaign) Shigang Chen (Cisco Systems) Songwu Lu (UCLA) Stanislaw Budkowski (Institut National des Telecommunications (INT), France) Terry Todd (McMaster University, Canada) Teruo Higashino (Osaka University, Japan) Timothy Roscoe (Sprint Advanced Technology Labs) William Tezlaff (IBM T. J. Watson Research Center) Yoshiaki Kakuda (Hiroshima City University, Japan) Yow-Jian Lin (Bell Labs Research, Lucent Technologies) Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel) Sonia Fahmy (Ohio State University) ICNP Steering Committee Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed May 2 11:47:26 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15264 for ; Wed, 2 May 2001 11:47:25 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f42Fk4H27108; Wed, 2 May 2001 11:46:04 -0400 Received: from plinius.intec2.rug.ac.be (plinius.intec2.rug.ac.be [157.193.122.4]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f42FjJH27072 for ; Wed, 2 May 2001 11:45:20 -0400 Received: from intec.rug.ac.be (daisne.intec2.rug.ac.be [157.193.122.92]) by plinius.intec2.rug.ac.be (Postfix) with ESMTP id 9FD21EEA8; Wed, 2 May 2001 17:45:16 +0200 (CEST) Message-ID: <3AF02B8C.ED38EDF0@intec.rug.ac.be> Date: Wed, 02 May 2001 17:45:16 +0200 From: Steven Van den Berghe X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Geib, Ruediger" Cc: ippm@advanced.org, stanislav shalunov Subject: Re: [ippm] OWDP coding proposal References: Content-Type: text/plain; charset=iso-8859-1 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f42Fk4H27108 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15264 Hi IPPMrs, Sorry for this late reply, but things have been quite busy (which is probably the case for all of you :) ). I was previously one of the people in favour of the addition of a extensible TLV-system to the OWDP-control protocol. Here is a small proposal (very drafty) for obtaining this feature. Modified request-session-message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Address (cont.) or Unused | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Address (cont.) or Unused | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Port | Receiver Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SID (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional TLV's | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Observe that, due to the fact that the draft specifies that OWDP-control goes over TCP, we know the size of the packets, hence we also know how many TLVs are following. I don' seem to find a reason for adding padding to the control-protocol (of course, i'll probably be missing out on something, as usual). An example of a possible TLV was already given in Ruediger's mail (i replyed to this, so it should be somewhere below this text). His lay-out is something like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Profile (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Profile Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Profile Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As you might have noted, i've dropped the type-P-packet classifier. I suggest to replace it with the following TLV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type-P descriptor (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The class denotes a "characteristic" of the packet like - well-known servces - DSCP - source port - .... A combination of multiple TLV's can be possible. As i said, this is just a first draft. If the IPPM list likes this, i could enhance this a bit into a real text (although i would suggest to put specific TLV definitions in a seperate document). So, please shoot your comments, Best regards, Steven Van den Berghe "Geib, Ruediger" wrote: > Dear IPPMers, > > below you'll find two proposals how to modify the coding of OWDP messages. > Please don't expect immediate replies on comments from me, I'll be out of > office until 25. April. > I hope the stuff below is readable when you get it... > > Regards, Rüdiger > > -------Content starts here---------- > > 1 Accept/Reject Indication > The coding of parameters should be non-ambiguos to leave no room for > interpretations. > > +-+-+-+-+-+-+-+-+ > | Accept | > +-+-+-+-+-+-+-+-+ > > Example of OWDP-02.txt: > > A zero value in the Accept field means that the server accepts the > [request] and is willing to conduct further [actions]. Any > non-zero value means that the server does not accept the > [request] provided by the client or, for some other reason, is > not willing to conduct further [actions] in this OWDP-Control > session. > > Proposal > > A zero value in the Accept field means that the server accepts the > [request] and is willing to conduct further [actions]. A > 00000001 value means that the server does not accept the > [request] provided by the client or, for some other reason, is > not willing to conduct further [actions] in this OWDP-Control > session. All other settings are reserved. > > 2 Request Session / test traffic profile > The Request Session message should contain a generic Test Traffic Profile > parameter leaving room for future definitions of test traffic profiles. > > Definition of OWDP-02.txt (Request Session message) > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 1 |IPVN-S | IPVN-R| Conf-Sender | Conf-Receiver | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ / > / \ > \ / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | SID (16 octets) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inv-Lambda | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ \ > / / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Proposal > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 1 |IPVN-S | IPVN-R| Conf-Sender | Conf-Receiver | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ / > / \ > \ / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | SID (16 octets) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Session Profile TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ \ > / / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note: This modification is based on the assumption that TLV coding will be > applied for the OWDP protocol. During the 50th IETF meeting Joan > Cucchiara (?) of BRIXnet volunteered to make a suggestion to this regard. > > Session Profile TLV > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Session Profile (TBD) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Profile Identifier | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Profile Parameters | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Length is a 16 bit Unsigned Integer indicating the length of the Session > Profile TLV as an integer multiple of octets (or 32 bit words, whatever is > preferred by the WG) including the TLV name and length 32 octets. > > Profile Identifier is a 16 bit field indicating the type of profile of the > test traffic for the session. > Deafault: > 0000..0000 Contiguous poisson profile. > > All other settings are reserved. > > Contiguous poisson profile parameters > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inv-Lambda | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Definition of the parameter see OWDP-02.txt. > > Rules for Session Profile TLV definitions > An OWDP Session Profile other than the defaultprofile MUST be defined by a > separate IETF document. The profile parameters MUST provide the complete > information to non-ambiguosly identify the characteristics of a test-stream > to be used for a session. > > Note that RFC1889 (RTP) choose a similar principle to provide flexibility > for future extensions. > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm -- Steven Van den Berghe steven.vandenberghe@intec.rug.ac.be Workgroup Broadband-Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ACSII stupid question, get a stupid ANSI! *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat May 5 03:35:44 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11808 for ; Sat, 5 May 2001 03:35:44 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f457Y4C13188; Sat, 5 May 2001 03:34:04 -0400 Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f457XQC13154 for ; Sat, 5 May 2001 03:33:26 -0400 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id f457XOj23963; Sat, 5 May 2001 00:33:24 -0700 (PDT) Message-Id: <200105050733.f457XOj23963@daffy.ee.lbl.gov> From: vern@aciri.org To: ippm@advanced.org Date: Sat, 05 May 2001 00:33:23 PDT Subject: [ippm] SIGCOMM Internet measurement workshop in November 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 [apologies to those who also get a copy of this via end2end-interest] SIGCOMM is sponsoring an Internet measurement workshop in November of this year. For those potentially interested, I've appended the CFP. We look forward to considering any submissions you might have. Thanks, Vern ACM SIGCOMM Internet Measurement Workshop 2001 November 1-2, 2001 San Francisco Bay Area This ACM SIGCOMM Internet Measurement Workshop is a one and a half day event focusing on Internet measurement and analysis. Submissions should contribute to the current understanding of how to collect or analyze Internet measurements, or give insight into how the Internet behaves. Examples of relevant topics are: * Workload characterization * Traffic engineering * Web measurements * Inter-domain and intra-domain routing * Active measurement techniques * Passive measurement techniques * Anonymization/privacy issues * Calibration * Measurement-based inference of network properties * Efficacy of content distribution networks * Reassessment/testing of previous measurement findings * Assessment of previous simulation/testbed findings Submissions on new ideas and work-in-progress are encouraged. Papers that do not in some fashion rely on measuring Internet properties are out of scope. The workshop is sponsored by ACM SIGCOMM. In addition to the published proceedings, the Program Committee may also select a few papers for fast-track submission for possible publication in IEEE/ACM Transactions on Networking. Attendance will be limited to 50 participants, with priority given to authors of accepted papers, program committee members, and authors of submitted papers. The workshop is open to three forms of submissions: * full papers (up to 15 pages) should exhibit succinctness appropriate to the topics and themes they discuss. * extended abstracts (up to 4 pages), conveying work expected to mature somewhat between submission and presentation at the workshop. * brief abstracts (less than a single page) to be considered for a possible work-in-progress session. Submissions must be in electronic form, as plain text, Postscript, or PDF documents, following the instructions found at: http://www.aciri.org/vern/sigcomm-imeas-2001.submit.html All manuscripts must be in English. The top of the first page of each paper should include the title of the paper, the authors and their affiliations, and the full address for the contact author (e-mail, phone, fax, mailing address). Papers and extended abstracts accepted for presentation at the workshop will be published by ACM in proceedings. Important dates --------------- June 29, 2001: HARD submission deadline August 3, 2001: Notification August 31, 2001: Camera Ready Copy due Steering committee ------------------ Christophe Diot, Sprint ATL (cdiot@sprintlabs.com) Balachander Krishnamurthy, AT&T--Labs Research (bala@research.att.com) Vern Paxson, ACIRI (vern@aciri.org) Jennifer Rexford, AT&T--Labs Research (jrex@research.att.com) Program committee ----------------- Mark Allman (NASA GRC, USA) Martin Arlitt (Hewlett-Packard Labs, USA) Paul Barford (U. of Wisconsin, USA) Anja Feldmann (Univ. Saarbruecken, Germany) Geoff Huston (Telstra, Australia) Jeffrey Mogul (Compaq WRL, USA) Henk Uijterwaal (RIPE NCC, Netherlands) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sun May 6 21:45:49 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16847 for ; Sun, 6 May 2001 21:45:49 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f471i4C28839; Sun, 6 May 2001 21:44:04 -0400 Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f471h2C28709 for ; Sun, 6 May 2001 21:43:03 -0400 Received: from d1o32.telia.com (d1o32.telia.com [194.236.208.241]) by maila.telia.com (8.11.2/8.11.0) with ESMTP id f471gxS09792 for ; Mon, 7 May 2001 03:42:59 +0200 (CEST) Received: from athena (h30n2fls22o913.telia.com [213.66.205.30]) by d1o32.telia.com (8.10.2/8.10.1) with ESMTP id f471gw829911 for ; Mon, 7 May 2001 03:42:58 +0200 (CEST) Message-ID: <1140620015171426950@athena> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: fine_fortune@hotmail.com To: ippm@advanced.org Date: Mon, 7 May 2001 03:42:06 +0200 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f471h2C28709 Subject: [ippm] The results of technology 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-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f471i4C28839 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA16847 


Proven Online Income Method

Hello Friends, I am an IT Manager making $50,000+ a year,
but I want to show you what I do for fun, which will make me
an ADDITIONAL $250,000 THIS YEAR ALONE....and it takes only
a fraction of the time that you and I spend at our regular jobs.
Basically, I send out as many of these emails as I can, then
people send me cash in the mail for information that I just
email back to them. Every day, I walk out to my mailbox
knowing that there are at least a few hundred dollars
waiting for me. And the best part, IT IS COMPLETELY LEGAL.
Just read the next few pages and see what you think.
If you like what you read, great....If you don't, read it again
because you must have missed something.

        WildCard

DEAR FRIENDS AND FUTURE MILLIONAIRES:
AS SEEN ON NATIONAL TV:

"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 US Dollars expense one time.

THANKS TO THE COMPUTER AGE AND THE INTERNET!
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!

Before you say "Bull", please read the following.
This is the letter you have been hearing about on the news
lately. Due to the popularity of this letter on the Internet, a
national weekly news program recently devoted an entire show to
the investigation of this program described below, to see if it
really can make people money. The show also investigated whether
or not the program was legal. Their findings proved once and for
all that there are "absolutely NO laws prohibiting the
participation in the program and if people can follow the simple
instructions, they are bound to make some mega bucks with only
$25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS
PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN
EVER.

This is what one had to say: "Thanks to this profitable
opportunity. I was approached many times before but each time I
passed on it. I am so glad I finally joined just to see what one
could expect in return for the minimal effort and money required.
To my astonishment, I received a total $610,470.00 in 21 weeks,
with money still coming in."

Pam Hedland, Fort Lee, New Jersey.

PRINT THIS NOW FOR YOUR FUTURE REFERENCE
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every
4 to 5 months easily and comfortably, please read
the following, THEN READ IT AGAIN AND AGAIN!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR FINANCIAL
DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

===========Order all 5 reports shown on the list below=====

For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT
YOU ARE ORDERING AND YOUR E-MAIL ADDRESS to the person whose name
appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN
ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail
problems. When you place your order, make Sure you order each of
the 5 reports. You will need all 5 reports so that you Can save
them on your computer and resell them.

YOUR TOTAL COST... $ 5 X 5 = $ 25.00. Within a few days you will
receive, via e-mail, each of the 5 reports from these 5 different
individuals. Save them on your computer so they will be
accessible for you to send to the 1,000's of people who will
order them from you. Also make a floppy of these reports and keep
it on your desk in case something happens to your computer.

IMPORTANT: DO NOT alter the names of the people who are listed
next to each report, or their sequence on the list, in any way
other than what is instructed below in each step "1 through 6" or
you will lose out on majority of your profits.
Once you understand the way this works, you will also see how
it does not work if you change it. Remember, this method has been
tested, and if you alter, it will NOT work!! People have tried to
put their friends/relatives names on all five thinking they could
get all the money. But it does not work this way. Believe us, we
all have tried to be greedy and then nothing happened. So Do Not
try to change anything other thanwhat is instructed, because if
you do, it will not work for you.

        Remember, honesty reaps the reward!!!

1. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.

2. Move the name & address in REPORT # 4 down to report # 5.

3. Move the name & address in REPORT # 3 down to report # 4.

4. Move the name & address in REPORT # 2 down to report # 3.

5. Move the name & address in REPORT # 1 down to report # 2.

6. Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY!

***Take this entire letter, with the modified list of names, and
save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save
this on a disk as well just in case if you lose any data. To
assist you with marketing your business on the internet, the 5
reports you purchase will provide you with invaluable marketing
information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD #1: BY SENDING BULK E-MAIL LEGALLY
===========================================================

Let's say that you decide to start small, just to see how it
goes, and we will assume you and those involved send out only
5,000 e-mails each.

Let's also assume that the mailing receive only a 0.2% response
(the response could be much better but lets just say it is only
0.2%. Also, many people will send out hundreds of thousands of
e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mails each for a
total of 50,000. Out of those 50,000 e-mails, only 0.2% responded
with orders. That's 100 people responding to and ordering Report
# 2. Those 100 people mail out 5,000 e-mails each for a total of
500,000 e-mails.

The 0.2% response to that is 1000 orders for Report # 3. Those
1000 people send out 5,000 e-mails each for a total of 5 million
e-mails.

The 0.2% response to that is 10,000 orders for Report # 4. Those
10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $ 500,000.00 (half
million).

Your total income in this example is: 1...$ 50 + 2...$ 500 + 3..$
5,000 + 4... $ 50,000 + 5... $ 500,000...

GRAND TOTAL = $555,550.00

                        NUMBERS DO NOT LIE.

GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE
RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL
MAKE A LOT OF MONEY!

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT
OF 5,000 YOU MAILED TO. Dare to think for a moment what would
happen if everyone or half or even one 4th of those people mailed
100,000 e-mails each or more? There are over 150 million people
on the Internet worldwide and counting. Believe me, many people
will do just that, and more!

METHOD # 2: BY PLACING FREE ADS ON THE INTERNET
Advertising on the net is very, very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free ads
on the internet will easily get a larger response.

We strongly suggest you start with Method # 1 and add METHOD # 2
as you go along.

For every $5 you receive, all you must do is e-mail them the
Report they ordered. That's it. Always provide same day service
on all orders.

This will guarantee that the e-mail they send out, with your name
and address on it, will be prompt because they can not advertise
until they receive the report.

AVAILABLE REPORTS =========================================

Notes: Always send $ 5 cash (US CURRENCY) for each report. 
                  Checks NOT accepted. 
Make sure the cash is concealed by wrapping it in atleast 2 
sheets of paper. On one of those sheets of paper, write the 
NUMBER & NAME of the Report you are ordering., YOUR E-MAIL 
ADDERSS and your name and postal address.

=========================================

PLACE YOUR ORDER FOR THESE REPORTS NOW:

REPORT # 1: "The Insider's Guide To Advertising For Free On The
Net"

Order Report # 1 from:

Karl Sewon
Åskmolnsvägen 44
74335 Storvreta
SWEDEN

Report #2: "The Insider's Guide To Sending Bulk E-Mail On The
Net"

Order Report #2 from:

Luc Riopel
P.O. Box 37028
St-Hubert   Qc
CANADA    J3Y 8N3

Report # 3: "The Secret To Multilevel Marketing On The Net"

Order Report # 3 from:

Clay Montgomery
12725 E. 76th Circle N.
Owasso, OK 74055
USA

Report # 4: "How To Become A Millionaire Utilizing MLM & The Net"

Order Report # 4 from:

Rick Dennis
P.O. Box 93649
Anchorage, AK 99509-3649
USA

Report # 5: "How To Send 1 Million E-Mails For Free"

Order Report # 5 from:

Christian Ward
PO Box 212537
Augusta, GA 30917-2537
USA

$$$$$$$$$$$$$$$$$$ YOUR SUCCESS GUIDE $$$$$$$$$$$$$$$$$$$$$$$$

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report # 1 within 2
weeks, continue sending e-mails until you do. After you have
received 10 orders, 2 to 3 weeks after that you should receive
100 orders or more for Report # 2. If you did not, continue
advertising or sending e-mails until you do. Once you have
received 100 or more orders for Report # 2, YOU CAN RELAX,
Because the system is already working for you, and the cash will
continue to roll in!

THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down
on the list, you are placed in front of a different report. You
can KEEP TRACK of your PROGRESS by watching which report people
are ordering from you.


IF YOU WANT TO GENERATE MORE INCOME, SEND ANOTHER BATCH OF E-
MAILS AND START THE WHOLE PROCESS AGAIN. There is no limit to the
income you can generate from this business!!!

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM:

You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A LITTLE
BIT OF EFFORT. You can make more money in the next few weeks and
months than you haveever imagined. Follow the program EXACTLY AS
INSTRUCTED. Do not change it in anyway. It works exceedingly well
as it is now. Remember to e-mail a copy of this exciting report
after you have put your name and address in Report # 1 and moved
others to # 2...# 5 as instructed above. One of the people you send this to
may send out 100,000 or more e-mails and your name will be on every one of
them. Remember
though, the more you send out the more potential customers you
will reach.
So my friend, I have given you the ideas, information, materials
and opportunity to become financially independent.

IT IS UP TO YOU NOW!

 =====================================================

This message is sent in compliance of the new e-mail bill:
SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618,
http://www.senate.gov/~murkowski/commercialemail/











_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue May  8 17:07:25 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07732
	for ; Tue, 8 May 2001 17:07:24 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f48L65C29178;
	Tue, 8 May 2001 17:06:05 -0400
Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f48KnJC23277
	for ; Tue, 8 May 2001 16:49:20 -0400
X-Authentication-Warning: mailhost.advanced.org: Host louie.udel.edu [128.175.2.33] claimed to be mail.eecis.udel.edu
Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa06531;
          8 May 2001 16:48 EDT
Date: Tue, 8 May 2001 16:47:08 -0400 (EDT)
From: Constantinos Dovrolis 
To: Constantinos Dovrolis 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [ippm] ICNP 2001 - Deadline extension
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 



*** Note: The paper submission deadline has been extended to
			May 14, 5pm (your local time).
	  There will be no further extensions after May 14.


--------------------------------------------------------------------------
                             CALL FOR PAPERS
--------------------------------------------------------------------------

9th International Conference on Network Protocols (ICNP 2001)

Mission Inn, Riverside, California

November 11-14, 2001

http://www.cis.udel.edu/icnp2001/


In just eight years, ICNP has established itself as one of the premier
conferences in the computer networking field.  ICNP deals with all
aspects of communication protocols, from design and specification, to
verification, testing, performance analysis, and implementation. Protocol
functions of interest include network access, switching, routing, flow and
congestion control, multimedia transport, wireless and mobile networks,
network security, web protocols and applications, electronic commerce,
network management, interoperability, internetworking, home computing and
networks and digital broadcasting.

ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place
filled with history. Riverside is located in the Sunny Southern California,
60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from
Disney Land. The city is served by three nearby airports: Los Angeles,
Ontario (California) and Orange County Airport.

Topics of interest include, but are not limited to:
- network access
- switching
- routing
- flow and congestion control
- multimedia transport protocols
- wireless and mobile networks
- network security
- web protocols and applications
- electronic commerce
- network management
- interoperability, internetworking
- home computing and networking
- digital broadcasting
- QoS and service differentiation
- network measurements
- protocols for distributed games
- peer-to-peer communication protocols


Important Dates:
	Paper Submission Deadline:  May 14, 2001   (NEW DEADLINE)
 	Tutorial Submission Deadline:  May 7, 2001
        Notification of Acceptance:  July 13, 2001
	Camera Ready Due:  August 8, 2001
	Tutorials:  November 11, 2001
	Conference:  November 12 - 14, 2001


Information for authors:
	Papers must be written in English, and they have to be in Postscript,
	PDF, or Word format. The complete manuscript should be no more than
	12 pages of double-spaced text with 11pt fonts.
	If you have any questions, you can contact us at icnp@ics.uci.edu.

	To register and submit your paper, visit the URL:
	http://violin.ics.uci.edu/~icnp/ConfMan/REG-paper/


General Chair
	Satish K. Tripathi, University of California - Riverside

Technical Program Co-Chairs
	Magda El Zarki, University of California, Irvine
	Klara Narhstedt, University of Illinois, Urbana-Champaign

Tutorial Co-Chairs
	Pravin Bhagwat, ReefEdge, Inc
        Ed Knightly, Rice University

Local Arrangement and Registration Co-Chairs
	Michalis Faloutsos, University of California - Riverside
	Srikant Krishnamurthy, University of California - Riverside

Publicity Co-Chairs
	Constantinos Dovrolis, University of Delaware
	Samar Singh, La Trobe University, Australia

Technical Program Committee
	Alex Petrenko (CRIM, Computer Research Institute of Montreal)
	Ana Rosa CAVALLI (Institut National des Telecommunications, France)
	Mart, Molle (University of California, Riverside)
	Andrew T. Campbell (Columbia University)
	Bobby Bhattacharjee (University of Maryland)
	Christophe Diot (Sprint)
	Cormac J. Sreenan (University College, Cork, Ireland)
	David Hutchison (Lancaster University)
	David Su (National Institute of Standards and Technology)
	David, Yau (Computer Science, Purdue University)
	Edward Knightly (Rice University )
	Ellen L. Hahne (AT&T Labs - Research)
	Geert Heijenk (Ericsson)
	Gene Tsudik (UC, Irvine)
	Geoffrey Xie (Naval Postgraduate School)
	Ernst W. Biersack (Institut EURECOM)
	Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden)
	Hartmut Koenig (BTU Cottbus, Germany
	Hasan Ural (University of Ottawa, Canada)
	Ibrahim Matta (Boston University)
	Jennifer Hou (Ohio State University)
	Jorg Lieberherr (University of Virginia)
	Jorge Cobb (The University of Texas at Dallas)
	Ken Calvert (University of Kentucky)
	Kevin Almeroth (UC-Santa Barbara)
	Kirshna Sivalingam (Washington State University / Jasmine Networks)
	Lars Wolf (University of Karlsruhe, Germany)
	Lixia Zhang (UCLA)
	Ljiljana Trajkovic (Simon Fraser University)
	Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY))
	Marco Schneider (SBC Technology Resources Inc.)
	Martha Steenstrup (Stow Research L.L.C.)
	Martina Zittterbart (University of Karlsruhe, Germany)
	Masayuki Murata (Osaka University, Japan)
	Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.)
	Mohamed G. Gouda (University of Texas at Austin)
	Nalini Venkatasubramanian (University of California, Irvine)
	Chris Edmondson-Yurkanan (University of Texas)
	Ness B. Shroff (Purdue University)
	Nina Bhatti (Nokia)
	Robin Kravets (University of Illinois at Urbana-Champaign)
	Shigang Chen (Cisco Systems)
	Songwu Lu (UCLA)
	Stanislaw Budkowski (Institut National des Telecommunications (INT), France)
	Terry Todd (McMaster University, Canada)
	Teruo Higashino (Osaka University, Japan)
	Timothy Roscoe (Sprint Advanced Technology Labs)
	William Tezlaff (IBM T. J. Watson  Research  Center)
	Yoshiaki Kakuda (Hiroshima City University, Japan)
	Yow-Jian Lin (Bell Labs Research, Lucent Technologies)
	Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel)
	Sonia Fahmy (Purdue University)

ICNP Steering Committee
	Mostafa Ammar, Georgia Insitute of Technology
        Mohamed Gouda, University of Texas at Austin
	Simon Lam, University of Texas at Austin
	David Lee, Bell Labs
	Ming T. (Mike) Liu, Ohio State University
	Raymond Miller, University of Maryland, College Park
	Krishan Sabnani, Bell Labs



_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed May  9 18:04:25 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26810
	for ; Wed, 9 May 2001 18:04:25 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f49M34C11015;
	Wed, 9 May 2001 18:03:04 -0400
Received: from pavilion ([24.31.80.230])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f49M2SC10828
	for ; Wed, 9 May 2001 18:02:28 -0400
X-Authentication-Warning: mailhost.advanced.org: Host [24.31.80.230] claimed to be pavilion
Message-ID: <203622001539215419180@pavilion>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
X-MSMail-Priority: Normal
From: "Mitchell" 
To: ippm@advanced.org
Date: Wed, 9 May 2001 11:54:19 -1000
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f49M2SC10828
Subject: [ippm] Business/Employment Opportunity
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

Dear Friend:

"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 U.S. Dollars expense one
time"

THANKS TO THE COMPUTER AGE AND THE INTERNET!
===============================================

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !!

Before you say "Bull" , please read the following. This is the
letter you have been hearing about on the news lately. Due to the
popularity of this letter on the internet, a national weekly news
program recently devoted an entire show to the investigation of
this program described below , to see if it really can make people
money.

The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are "absolutely
no laws prohibiting the participation in the program and if people
can follow the simple instructions, they are bound to make
some mega bucks with only $25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING
BETTER THAN EVER.

This is what one had to say:

"Thanks to this profitable opportunity. I was approached
many times before but each time I passed on it. I am so glad
I finally joined just to see what one could expect in return
for the minimal effort and money required. To my astonishment, I
received total $ 610,470.00 in 21 weeks, with money still
coming in".
Pam Hedland, Fort Lee, New Jersey.

-------------------------------------------------------------------------

Here is another testimonial:

"This program has been around for a long time but I never
believed in it. But one day when I received this again in
the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money
started to come in. First month I only made $240.00 but
the next 2 months after that I made a total of $290,000.00.
So far, in the past 8 months by re-entering the program,I
have made over $710,000.00 and I am playing it again.
The key to success in this program is to follow the simple
steps and NOT change anything ."

More testimonials later but first,

****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *******

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN READ
IT AGAIN and AGAIN !!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR
FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

**** Order all 5 reports shown on the list below.

**** For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS
to the person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
TOP LEFT CORNER in case of any mail problems.

**** When you place your order, make sure you order each of the 5
reports. You will need all 5 reports so that you can save them on your 
computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00.

**** Within a few days you will receive, via e-mail, each of the 5
reports from these 5 different individuals. Save them on your computer
so they will be accessible for you to send to the 1,000's of people
who will order them from you. Also make a floppy of these
reports and keep it on your desk in case something happen to your
computer.

****.IMPORTANT - DO NOT alter the names of the people who are
listed next to each report, or their sequence on the list, in
any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you
understand the way this works, you will also see how it does not work if you 
change it.

Remember, this method has been tested, and if you alter, it
will NOT work!!! People have tried to put their friends/relatives names
on all five thinking they could get all the money. But it does not work this 
way. Believe us, we all have tried to be greedy and then nothing happened. 
So Do Not try to change anything other than what is instructed. Because if 
you do, it will not work for you. Remember, honesty reaps the reward!!!

1.. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.

2.... Move the name & address in REPORT # 4 down TO REPORT # 5.

3.... Move the name & address in REPORT # 3 down TO REPORT # 4.

4.... Move the name & address in REPORT # 2 down TO REPORT # 3.

5.... Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY !
=========================================================

Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data.

To assist you with marketing your business on the internet, the
5 reports you purchase will provide you with invaluable
marketing information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY
============================================
let's say that you decide to start small, just to see how it
goes, and we will assume You and those involved send out only
5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just
say it is only 0.2% . Also many people will send out hundreds of
thousands e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mail
each for a total of 50,000. Out of those 50,000 e-mails only
0.2% responded with orders. That's = 100 people responded
and ordered Report # 2. Those 100 people mail out 5,000
e-mails each for a total of 500,000 e-mails. The 0.2% response
to that is 1000 orders for Report # 3. Those 1000 people send
out 5,000 e-mails each for a total of 5 million e-mails sent out.
The 0.2% response to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million).

Your total income in this example is:
1..... $50 +
2..... $500 +
3..... $5,000 +
4..... $50,000 +
5..... $500,000 ......... Grand Total = $555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE
OUT THE WORST POSSIBLE RESPONSES AND NO MATTER
HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF
MONEY !

------------------------------------------------------------------------------

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for
a moment what would happen if everyone, or half or even one 4th
of those people mailed 100,000 e-mails each or more? There are
over 250 million people on the internet worldwide and counting.
Believe me, many people will do just that, and more!

METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
===================================================
Advertising on the net is very very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly
suggest you start with Method # 1 and add METHOD # 2 as you go
along.

For every $5 you receive, all you must do is e-mail them the Report
they ordered. That's it . Always provide same day service on all
orders. This will guarantee that the e-mail they send out, with your
name and address on it, will be prompt because they can not advertise until 
they receive the report.

_____________________ AVAILABLE REPORTS_____________________

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.

Notes: Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed by wrapping
it in at least 2 sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
==============================================
REPORT #1, "The Insider's Guide to Sending
Bulk E-mail on the Internet"

ORDER REPORT #1 FROM:

G. Donaldson
P.O. Box 25884
Honolulu, Hawaii 96825-0884


don't forget to provide a permanent e-mail address in clear writing (better 
typed) to receive the reports. We had problems in delivery e-mails before!!!

==============================================
REPORT #2 "The Insider's Guide to Advertising for Free on the
Internet"
ORDER REPORT #2 FROM:

Vijay Paul
C-291, Second Floor
Defence Colony
New Delhi - 110024
INDIA

==============================================
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
ORDER REPORT #3 FROM:

JD
P.O.Box 1114
Des Plaines, IL 60017
USA

==============================================
REPORT #4 "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"
ORDER REPORT #4 FROM:

J Santi
833 Walter Ave
Des Plaines, IL 60016
USA

==============================================
REPORT #5 "How to SEND 1,000,000 e-mails for FREE"
ORDER REPORT #5 FROM:

Elaine Rix
138 Dundas Street, West, #243
Toronto, Ontario
Canada M5G 1C3

==============================================
There are currently more than 250,000,000 people online
worldwide!

$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.

After you have received 10 orders, 2 to 3 weeks after that
you should receive 100 orders or more for REPORT # 2.
If you did not, continue advertising or sending e-mails until
you do.
Once you have received 100 or more orders for Report # 2,
YOU CAN RELAX, because the system is already working for
you , and the cash will continue to roll in !

THIS IS IMPORTANT TO REMEMBER : Every time your name is
moved down on the list, you are placed in front of a different report.
You can KEEP TRACK of your PROGRESS by watching which
report people are ordering from you. IF YOU WANT TO GENERATE
MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND
START THE WHOLE PROCESS AGAIN. There is NO LIMIT to
the income you can generate from this business !!!
____________________________________________________

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM:

You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A
LITTLE BIT OF EFFORT. You can make more money in the
next few weeks and months than you have ever imagined.

Follow the program EXACTLY AS INSTRUCTED. Do Not change
it in any way. It works exceedingly well as it is now.
Remember to e-mail a copy of this exciting report after you
have put your name and address in Report #1 and moved others to
#2...........# 5 as instructed above. One of the people you send this to may 
send out 100,000 or more e-mails and your name will be on everyone of them. 
Remember though, the more you send out the more potential customers you will 
reach.

So my friend, I have given you the ideas, information,
materials and opportunity to become financially independent. IT IS UP TO YOU 
NOW !

************** MORE TESTIMONIALS ****************

"My name is Mitchell. My wife , Jody and I live in Chicago.
I am an accountant with a major U.S. Corporation and I
make pretty good money. When I received this program I grumbled
to Jody about receiving ''junk mail''. I made fun of the
whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody
totally ignored my supposed intelligence and few days later she jumped in 
with both feet. I made merciless fun of her, and was ready to
lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received
50 responses. Within the next 45 days she had received a
total of $ 147,200.00 all cash! I was shocked. I have
joined Jody in her ''hobby''."
Mitchell Wolf,
Chicago, Illinois

------------------------------------------------------------

"Not being the gambling type, it took me several weeks to
make up my mind to participate in this plan. But conservative that
I am, I decided that the initial investment was so little
that there was just no way that I wouldn't get enough orders to at
least get my money back.

I was surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first 12
weeks. The nice thing about this deal is that it does not matter
where people live. There simply isn't a better investment
with a faster return and so big."
Dan Sondstrom, Alberta,
Canada

-----------------------------------------------------------

"I had received this program before. I deleted it, but
later I wondered if I should have given it a try. Of course, I had
no idea who to contact to get another copy, so I had to wait
until I was e-mailed again by someone else.........11 months
passed then it luckily came again...... I did not delete this
one! I made more than $490,000 on my first try and all the
money came within 22 weeks".
Susan De Suza,
New York, N.Y.

----------------------------------------------------

"It really is a great opportunity to make relatively easy
money with little cost to you. I followed the simple
instructions carefully and within 10 days the money
started to come in. My first month I made $ 20,560.00
and by the end of third month my total cash count was
$ 362,840.00. Life is beautiful, Thanx to internet".
Fred Dellaca, Westport,
New Zealand
------------------------------------------------------------


ORDER YOUR REPORTS TODAY AND GET STARTED ON
YOUR ROAD TO FINANCIAL FREEDOM !

=======================================================

If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.


Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal.
This is one time e-mail transmission. No request for removal is
necessary.

------------------------------------------------------------
This message is sent in compliance of the new email
Bill HR 1910. Under Bill HR 1910 passed by the 106th
US Congress on May 24, 1999, this message cannot be
considered Spam as long as we include the way to be
removed. Per Section HR 1910, Please type "REMOVE" in
the subject line and reply to this email. All removal
requests are handled personally an immediately once
received.







_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu May 10 22:41:39 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14175
	for ; Thu, 10 May 2001 22:41:39 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4B2e5C30799;
	Thu, 10 May 2001 22:40:06 -0400
Received: from mail.cad.zju.edu.cn ([210.32.131.2])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f4B2dXC30757
	for ; Thu, 10 May 2001 22:39:34 -0400
X-Authentication-Warning: mailhost.advanced.org: Host [210.32.131.2] claimed to be mail.cad.zju.edu.cn
Received: (qmail 13153 invoked from network); 11 May 2001 02:41:07 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 11 May 2001 02:41:07 -0000
Message-ID: <3AFB5102.8B87E3ED@cad.zju.edu.cn>
Date: Fri, 11 May 2001 10:40:02 +0800
From: shen jing 
Reply-To: jshen@cad.zju.edu.cn
Organization: state key lab of CAD&CG
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ippm@advanced.org
CC: mpls@ietf.org, rsvp@isi.edu, siglite@cs.columbia.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [ippm] How to measure the actual delay when signalling QoS?
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

Dear sir/madam:

If the question following is stupid, forgive me please.


As providing a QoS enabled service over internet,  signaling the remote
end along the
path calcultated is needed. As I know in current research, RSVP is the
possible solution.

But, the question is:  the signaling procedure only consider the
bandwidth needed, real
transmission dely and jitter is considered.  In order to get a
real-guarantee for
delay and jitter,  I think the actucal delay for signaling packets
should be brought to
the end station.

What I want to ask is: is  there any method proposed to solve this
question?
 And would you please tell me any site where  documents on this
subject can be found?

Thanks in advance.

Jame Shen




_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri May 11 06:28:47 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03264
	for ; Fri, 11 May 2001 06:28:46 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4BAR9C11568;
	Fri, 11 May 2001 06:27:09 -0400
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4BAQlC11343
	for ; Fri, 11 May 2001 06:26:48 -0400
Received: from x49.ripe.net (x49.ripe.net [193.0.1.49])
	by birch.ripe.net (8.8.8/8.8.8) with ESMTP id MAA04713;
	Fri, 11 May 2001 12:26:44 +0200 (CEST)
Received: from localhost (henk@localhost)
	by x49.ripe.net (8.8.8/8.8.5) with ESMTP id MAA04811;
	Fri, 11 May 2001 12:26:44 +0200 (CEST)
X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs
Date: Fri, 11 May 2001 12:26:44 +0200 (CEST)
From: "Henk Uijterwaal (RIPE-NCC)" 
To: "Geib, Ruediger" 
cc: ippm@advanced.org
Subject: Re: [ippm] OWDP coding proposal
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mailhost.advanced.org id f4BAQlC11343
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-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4BAR9C11568
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA03264

Ruediger,

I think both suggestions make sense.

Henk



> Dear IPPMers,
> 
> below you'll find two proposals how to modify the coding of OWDP messages.
> Please don't expect immediate replies on comments from me, I'll be out of
> office until 25. April.
> I hope the stuff below is readable when you get it...
> 
> Regards, Rüdiger
> 
> -------Content starts here----------
> 
> 1 Accept/Reject Indication
> The coding of parameters should be non-ambiguos to leave no room for 
> interpretations. 
> 
> +-+-+-+-+-+-+-+-+
> |   Accept      |
> +-+-+-+-+-+-+-+-+
> 
> Example of OWDP-02.txt:
> 
>    A zero value in the Accept field means that the server accepts the
>    [request] and is willing to conduct further [actions].  Any
>    non-zero value means that the server does not accept the
>    [request] provided by the client or, for some other reason, is
>    not willing to conduct further [actions] in this OWDP-Control
>    session.
> 
> 
> Proposal
> 
>    A zero value in the Accept field means that the server accepts the
>    [request] and is willing to conduct further [actions].  A
>    00000001 value means that the server does not accept the
>    [request] provided by the client or, for some other reason, is
>    not willing to conduct further [actions] in this OWDP-Control
>    session. All other settings are reserved.
> 
> 
> 2 Request Session / test traffic profile
> The Request Session message should contain a generic Test Traffic Profile 
> parameter leaving room for future definitions of test traffic profiles.
> 
> Definition of OWDP-02.txt (Request Session message)
> 
>         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
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |      1        |IPVN-S | IPVN-R| Conf-Sender   | Conf-Receiver |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         \                                                               /
>         /                                                               \
>         \                                                               /
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                                                               |
>         |                        SID (16 octets)                        |
>         |                                                               |
>         |                                                               |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                          Inv-Lambda                           |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                            Packets                            |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         \                                                               \
>         /                                                               /
>         \                                                               \
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Proposal
> 
>         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
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |      1        |IPVN-S | IPVN-R| Conf-Sender   | Conf-Receiver |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         \                                                               /
>         /                                                               \
>         \                                                               /
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                                                               |
>         |                        SID (16 octets)                        |
>         |                                                               |
>         |                                                               |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                    Session Profile TLV                        |
>         |                                                               |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                            Packets                            |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         \                                                               \
>         /                                                               /
>         \                                                               \
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Note: This modification is based on the assumption that TLV coding will be 
> applied for the OWDP protocol. During the 50th IETF meeting Joan 
> Cucchiara (?) of BRIXnet volunteered to make a suggestion to this regard. 
> 
> Session Profile TLV
> 
>         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
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |      Session Profile  (TBD)   |            Length             |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |    Profile Identifier         |            Reserved           |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                      Profile Parameters                       |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Length is a 16 bit Unsigned Integer indicating the length of the Session 
> Profile TLV as an integer multiple of octets (or 32 bit words, whatever is 
> preferred by the WG) including the TLV name and length 32 octets.
> 
> Profile Identifier is a 16 bit field indicating the type of profile of the 
> test traffic for the session.
> Deafault:
> 0000..0000		Contiguous poisson profile.
> 
> All other settings are reserved.
> 
> Contiguous poisson profile parameters
> 
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                          Inv-Lambda                           |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Definition of the parameter see OWDP-02.txt.
> 
> Rules for Session Profile TLV definitions
> An OWDP Session Profile other than the defaultprofile MUST be defined by a
> separate IETF document. The profile parameters MUST provide the complete 
> information to non-ambiguosly identify the characteristics of a test-stream
> to be used for a session.
> 
> Note that RFC1889 (RTP) choose a similar principle to provide flexibility 
> for future extensions. 
> _______________________________________________
> 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  
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri May 11 14:46:43 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18205
	for ; Fri, 11 May 2001 14:46:42 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4BIh3C05843;
	Fri, 11 May 2001 14:43:03 -0400
Received: from Mercury.acs.unt.edu (mercury.acs.unt.edu [129.120.220.1])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4BIgLC05720
	for ; Fri, 11 May 2001 14:42:22 -0400
Received: from cs.unt.edu (cs.unt.edu [129.120.36.230])
	by Mercury.acs.unt.edu (8.8.8/8.8.8) with ESMTP id NAA00265;
	Fri, 11 May 2001 13:40:17 -0500 (CDT)
Received: from csp05.csci.unt.edu (csp05.csci.unt.edu [129.120.36.69])
	by cs.unt.edu (8.9.3/8.9.3) with ESMTP id NAA22747;
	Fri, 11 May 2001 13:40:16 -0500 (CDT)
	(envelope-from iyengar@cs.unt.edu)
Received: from iyengar (helo=localhost)
	by csp05.csci.unt.edu with local-smtp (Exim 3.12 #1 (Debian))
	id 14yHpo-0005hh-00; Fri, 11 May 2001 13:40:16 -0500
Date: Fri, 11 May 2001 13:40:16 -0500 (CDT)
From: Prasanna Iyengar 
To: shen jing 
cc: ippm@advanced.org, mpls@ietf.org, rsvp@isi.edu, siglite@cs.columbia.edu
In-Reply-To: <3AFB5102.8B87E3ED@cad.zju.edu.cn>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [ippm] Re: How to measure the actual delay when signalling QoS?
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,
 
 Guaranteed service of Integrated service model does not control jitter.
It just controls the maximum queuing delay(Ref: RFC 2212).

>  I think the actucal delay for signaling packets
> should be brought to
> the end station.

Yes, end station has to know the maximal queuing delay.

RFC 2212 says that two error terms C and D (these error terms are
used to find maximum queuing delay)should be exported to end
stations(Refer page 2 of RFC 2212). It doesn't give a clear cut guidelines
regarding how to export C and D to end stations.

rfc 2212 is available at 

www.ietf.org/rfc/rfc2212.txt


Prasanna.

On Fri, 11 May 2001, shen jing wrote:

> Dear sir/madam:
> 
> If the question following is stupid, forgive me please.
> 
> 
> As providing a QoS enabled service over internet,  signaling the remote
> end along the
> path calcultated is needed. As I know in current research, RSVP is the
> possible solution.
> 
> But, the question is:  the signaling procedure only consider the
> bandwidth needed, real
> transmission dely and jitter is considered.  In order to get a
> real-guarantee for
> delay and jitter,  I think the actucal delay for signaling packets
> should be brought to
> the end station.
> 
> What I want to ask is: is  there any method proposed to solve this
> question?
>  And would you please tell me any site where  documents on this
> subject can be found?
> 
> Thanks in advance.
> 
> Jame Shen
> 
> 
> 
> 
> 

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 05:07:55 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05715
	for ; Mon, 14 May 2001 05:07:54 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4E963C16530;
	Mon, 14 May 2001 05:06:03 -0400
Received: from mucus.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4E95WC16494;
	Mon, 14 May 2001 05:05:35 -0400
X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be mucus.advanced.org
Received: from internet2.edu (localhost [127.0.0.1])
	by mucus.advanced.org (Postfix) with ESMTP
	id BF39810CF; Mon, 14 May 2001 05:09:59 -0400 (EDT)
Message-ID: <3AFF8B9E.CA2A0EBB@internet2.edu>
Date: Mon, 14 May 2001 03:39:10 -0400
From: Ben Teitelbaum 
Organization: Internet2 (UCAID) / Advanced Network & Services
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henk Uijterwaal (RIPE-NCC)" ,
        "Geib, Ruediger" 
Cc: ippm@advanced.org
Subject: Re: [ippm] OWDP coding proposal
References: 
Content-Type: text/plain; charset=iso-8859-1
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0beta5
Precedence: bulk
List-Id: IETF IP Performance Metrics Working Group List 
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4E963C16530
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA05715

Ruediger and Henk,

While the generality of Profile Identifier/Profile Parameters is appealing,
I'd rather not achieve generality through indirection and deferral, when we
could do a pretty good job right now. What if we spec'd into the Request
Session message a test packet schedule characterized by the following three
arguments:

1) an arbitrary length packet train schedule {sleep_0, sleep_1, ...}, where
sleep_n is the amount of time session-sender waits between transmitting the 
first bit of the n_th packet and transmitting the first bit of the n+1_th 
packet in the train; each train consists of a single packet followed by as 
many packets as are specified in the schedule and sleep times less than a 
packet transmission time at the session-senders' interface speed are 
assumed to equate to back-to-back test packets;

2) a packet train probability distribution [periodic, Poisson, uniform, ...];

3) an average inter-packet train interval (given as a reciprocle, as in the
current draft);

This is general enough to describe the two in-vogue test stream distributions:

Poisson: {{}, Poisson, Inv-Rate}
Periodic: {{}, periodic, Inv-Rate}

as well as the packet pair versions of these:

Poisson-Pair: {{0}, Poisson, Inv-Rate}
Periodic-Pair: {{0}, periodic, Inv-Rate}

or weird repeating things things like:

{{10, 20, 40, 80, 160}, periodic, 5000}

or even an arbitrarily weird distribution specified by a single long packet
train schedule.

Note that the server is free to reject session requests that impose
unacceptibly large memory requirements on Session-Senders or appear to be
malformed: {{1 min}, Poisson, 0.5 sec}.

So, could something like this work?

-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum
                           -   Advanced Network & Services, Inc.
                           .   Internet2



"Henk Uijterwaal (RIPE-NCC)" wrote:
> 
> Ruediger,
> 
> I think both suggestions make sense.
> 
> Henk
> 
> > Dear IPPMers,
> >
> > below you'll find two proposals how to modify the coding of OWDP messages.
> > Please don't expect immediate replies on comments from me, I'll be out of
> > office until 25. April.
> > I hope the stuff below is readable when you get it...
> >
> > Regards, Rüdiger
> >
> > -------Content starts here----------
> >
> > 1 Accept/Reject Indication
> > The coding of parameters should be non-ambiguos to leave no room for
> > interpretations.
> >
> > +-+-+-+-+-+-+-+-+
> > |   Accept      |
> > +-+-+-+-+-+-+-+-+
> >
> > Example of OWDP-02.txt:
> >
> >    A zero value in the Accept field means that the server accepts the
> >    [request] and is willing to conduct further [actions].  Any
> >    non-zero value means that the server does not accept the
> >    [request] provided by the client or, for some other reason, is
> >    not willing to conduct further [actions] in this OWDP-Control
> >    session.
> >
> >
> > Proposal
> >
> >    A zero value in the Accept field means that the server accepts the
> >    [request] and is willing to conduct further [actions].  A
> >    00000001 value means that the server does not accept the
> >    [request] provided by the client or, for some other reason, is
> >    not willing to conduct further [actions] in this OWDP-Control
> >    session. All other settings are reserved.
> >
> >
> > 2 Request Session / test traffic profile
> > The Request Session message should contain a generic Test Traffic Profile
> > parameter leaving room for future definitions of test traffic profiles.
> >
> > Definition of OWDP-02.txt (Request Session message)
> >
> >         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
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |      1        |IPVN-S | IPVN-R| Conf-Sender   | Conf-Receiver |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         \                                                               /
> >         /                                                               \
> >         \                                                               /
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                                                               |
> >         |                        SID (16 octets)                        |
> >         |                                                               |
> >         |                                                               |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                          Inv-Lambda                           |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                            Packets                            |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         \                                                               \
> >         /                                                               /
> >         \                                                               \
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Proposal
> >
> >         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
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |      1        |IPVN-S | IPVN-R| Conf-Sender   | Conf-Receiver |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         \                                                               /
> >         /                                                               \
> >         \                                                               /
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                                                               |
> >         |                        SID (16 octets)                        |
> >         |                                                               |
> >         |                                                               |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                    Session Profile TLV                        |
> >         |                                                               |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                            Packets                            |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         \                                                               \
> >         /                                                               /
> >         \                                                               \
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Note: This modification is based on the assumption that TLV coding will be
> > applied for the OWDP protocol. During the 50th IETF meeting Joan
> > Cucchiara (?) of BRIXnet volunteered to make a suggestion to this regard.
> >
> > Session Profile TLV
> >
> >         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
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |      Session Profile  (TBD)   |            Length             |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |    Profile Identifier         |            Reserved           |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                      Profile Parameters                       |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Length is a 16 bit Unsigned Integer indicating the length of the Session
> > Profile TLV as an integer multiple of octets (or 32 bit words, whatever is
> > preferred by the WG) including the TLV name and length 32 octets.
> >
> > Profile Identifier is a 16 bit field indicating the type of profile of the
> > test traffic for the session.
> > Deafault:
> > 0000..0000            Contiguous poisson profile.
> >
> > All other settings are reserved.
> >
> > Contiguous poisson profile parameters
> >
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                          Inv-Lambda                           |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Definition of the parameter see OWDP-02.txt.
> >
> > Rules for Session Profile TLV definitions
> > An OWDP Session Profile other than the defaultprofile MUST be defined by a
> > separate IETF document. The profile parameters MUST provide the complete
> > information to non-ambiguosly identify the characteristics of a test-stream
> > to be used for a session.
> >
> > Note that RFC1889 (RTP) choose a similar principle to provide flexibility
> > for future extensions.
> > _______________________________________________
> > 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
> ------------------------------------------------------------------------------
> 
> As long as you don't tell your friends how I played the hand,
> then I won't tell my friends how you defended it.                 (Anonymous)
> 
> _______________________________________________
> ippm mailing list
> ippm@advanced.org
> http://mailhost.advanced.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 05:51:06 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06016
	for ; Mon, 14 May 2001 05:51:05 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4E9o4C20961;
	Mon, 14 May 2001 05:50:04 -0400
Received: from fw1b.telekom.de (gw1.telekom.de [194.25.15.11])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f4E9nSC20931
	for ; Mon, 14 May 2001 05:49:29 -0400
X-Authentication-Warning: mailhost.advanced.org: Host gw1.telekom.de [194.25.15.11] claimed to be fw1b.telekom.de
Received: by fw1b.telekom.de; (5.65v4.0/1.3/10May95) id AA01884; Mon, 14 May 2001 11:49:25 +0200
Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ippm@advanced.org; Mon, 14 May 2001 11:49:24 +0200
Received: from g8pbr.blf01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for ippm@advanced.org; Mon, 14 May 2001 11:49:22 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id ; Mon, 14 May 2001 11:49:16 +0200
Message-Id: 
From: "Geib, Ruediger" 
To: ippm@advanced.org
Subject: RE: [ippm] OWDP coding proposal
Date: Mon, 14 May 2001 11:49:15 +0200
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f4E9nSC20931
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-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4E9o4C20961
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA06016

Hello Ben,

Would

> 1) an arbitrary length packet train schedule  
> 2) a packet train probability distribution 
> 3) an average inter-packet train interval 

allow to code a dual Poisson distribution (e.g. train length poisson distributed, inter arrival time Poisson distributed) in a simple manner? I guess not.

I'm also not sure whether you could easily extend it to distributions which are harder to describe than trains and an inter train rate. 

I recognize that there's got to be a compromise between simplicity and usefulness. 

Regards, Rüdiger
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 06:20:10 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06175
	for ; Mon, 14 May 2001 06:20:09 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EAJ3C24907;
	Mon, 14 May 2001 06:19:03 -0400
Received: from fw1b.telekom.de (gw1.telekom.de [194.25.15.11])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f4EAICC24884
	for ; Mon, 14 May 2001 06:18:13 -0400
X-Authentication-Warning: mailhost.advanced.org: Host gw1.telekom.de [194.25.15.11] claimed to be fw1b.telekom.de
Received: by fw1b.telekom.de; (5.65v4.0/1.3/10May95) id AA10237; Mon, 14 May 2001 12:18:09 +0200
Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ippm@advanced.org; Mon, 14 May 2001 12:18:04 +0200
Received: from g8pbq.blf01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for ippm@advanced.org; Mon, 14 May 2001 12:17:59 +0200
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id ; Mon, 14 May 2001 12:17:58 +0200
Message-Id: 
From: "Geib, Ruediger" 
To: ippm@advanced.org
Date: Mon, 14 May 2001 12:17:54 +0200
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f4EAICC24884
Subject: [ippm] OWDP: Is measurement box access speed information required?
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-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4EAJ3C24907
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06175

Hi IPPMers,

should I come back on something already discussed, please drop this message.

My question is whether sender/receiver need to provide information on their access speeds. The access speed of the measurement equipment will determine the "resolution of time" the system can provide depending on the packet length. In some cases, it may be useful to know the minimum distance in time two packets can have due to access speed limitations.

I didn't thoroughly read the draft. But I didn't have the impression that this information is communicateable by OWDP. 

Regards, 

Rüdiger
 
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 06:39:43 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06389
	for ; Mon, 14 May 2001 06:39:42 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EAc3C29088;
	Mon, 14 May 2001 06:38:03 -0400
Received: from plinius.intec2.rug.ac.be (plinius.intec2.rug.ac.be [157.193.122.4])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EAb9C28859
	for ; Mon, 14 May 2001 06:37:10 -0400
Received: from intec.rug.ac.be (daisne.intec2.rug.ac.be [157.193.122.92])
	by plinius.intec2.rug.ac.be (Postfix) with ESMTP
	id 0BD99EEAA; Mon, 14 May 2001 12:37:06 +0200 (CEST)
Message-ID: <3AFFB551.A47E54A2@intec.rug.ac.be>
Date: Mon, 14 May 2001 12:37:05 +0200
From: Steven Van den Berghe 
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Geib, Ruediger" ,
        Ben Teitelbaum 
Cc: ippm@advanced.org, "Henk Uijterwaal (RIPE-NCC)" 
Subject: Re: [ippm] OWDP coding proposal
References: 
Content-Type: text/plain; charset=iso-8859-1
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0beta5
Precedence: bulk
List-Id: IETF IP Performance Metrics Working Group List 
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4EAc3C29088
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06389

Hi all,

These are just some personal thoughts on the OWDP-control protocol. If you feel they go to far and complicate things too much, just ignore them.

We need indeed find the right balance between simplicity (from an implementation point of view), current usefulness and future usefulness. My feeling is that
these objectives are achieved by allowing a flexible extensibility of the control-side of the protocol:
  - allow to generalize by adding for instance TLV's
  - don't impose the implementation of any of the TLV's so one can have the choice between a "light-weight" and a "full-option" implementation.

Next to the profile definition, other areas i see, where extensibility might be a nice thing to have are:
  - result description (say for instance that we just want to keep min/max/avg results instead of packet-sequences to avoid wasting storage space)
  - type-P-packet definitions (cf my  previous mail)

I know it might endanger the idea of having a universal measurement infrastructure as offered by the "ping"-way, but implementing some basic TLVs and
ignoring all the rest shouldn't complicate things too much.

Regards,
Steven

"Geib, Ruediger" wrote:

> Hello Ben,
>
> Would
>
> > 1) an arbitrary length packet train schedule
> > 2) a packet train probability distribution
> > 3) an average inter-packet train interval
>
> allow to code a dual Poisson distribution (e.g. train length poisson distributed, inter arrival time Poisson distributed) in a simple manner? I guess not.
>
> I'm also not sure whether you could easily extend it to distributions which are harder to describe than trains and an inter train rate.
>
> I recognize that there's got to be a compromise between simplicity and usefulness.
>
> Regards, Rüdiger
> _______________________________________________
> ippm mailing list
> ippm@advanced.org
> http://mailhost.advanced.org/mailman/listinfo/ippm

--
Steven Van den Berghe
steven.vandenberghe@intec.rug.ac.be
Workgroup Broadband-Networks
Department Information Technology
Ghent University - Belgium
Phone:  +32 (0)9 267 35 86 | Fax  :  +32 (0)9 267 35 99
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
The faulty interface lies between the chair and the
keyboard.


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 07:25:17 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06832
	for ; Mon, 14 May 2001 07:25:17 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EBM6C02061;
	Mon, 14 May 2001 07:22:06 -0400
Received: from mucus.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EBL0C01799;
	Mon, 14 May 2001 07:21:02 -0400
X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be mucus.advanced.org
Received: from internet2.edu (localhost [127.0.0.1])
	by mucus.advanced.org (Postfix) with ESMTP
	id D3A9A10CB; Mon, 14 May 2001 07:25:30 -0400 (EDT)
Message-ID: <3AFFC0A9.1D4D6339@internet2.edu>
Date: Mon, 14 May 2001 07:25:29 -0400
From: Ben Teitelbaum 
Organization: Internet2 (UCAID) / Advanced Network & Services
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Geib, Ruediger" 
Cc: ippm@advanced.org
Subject: Re: [ippm] OWDP coding proposal
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0beta5
Precedence: bulk
List-Id: IETF IP Performance Metrics Working Group List 
Content-Transfer-Encoding: 7bit

"Geib, Ruediger" wrote:
> 
> Hello Ben,
> 
> Would
> 
> > 1) an arbitrary length packet train schedule
> > 2) a packet train probability distribution
> > 3) an average inter-packet train interval
> 
> allow to code a dual Poisson distribution (e.g. train length poisson distributed, inter arrival time Poisson distributed) in a simple manner? I guess not.
> 

Right. But, you could fake it with a pseudo-Poisson packet train schedule. 

> I'm also not sure whether you could easily extend it to distributions which are harder to describe than trains and an inter train rate.

The only way to achieve full generality, is to install an explicit test packet
schedule in the session-sender, which my proposed approach can support. I
don't claim to support full generality in an efficient way, but the hook is
there. The idea was to offer a solution that is general enough to describe
efficiently the distributions that the WG currently finds important, while
offering generality and extensibility.

Cheers,

-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum
                           -   Advanced Network & Services, Inc.
                           .   Internet2
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 07:36:13 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07156
	for ; Mon, 14 May 2001 07:36:13 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EBZ7C03475;
	Mon, 14 May 2001 07:35:07 -0400
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EBYPC03435
	for ; Mon, 14 May 2001 07:34:25 -0400
Received: from x49.ripe.net (x49.ripe.net [193.0.1.49])
	by birch.ripe.net (8.8.8/8.8.8) with ESMTP id NAA28170;
	Mon, 14 May 2001 13:34:22 +0200 (CEST)
Received: from localhost (henk@localhost)
	by x49.ripe.net (8.8.8/8.8.5) with ESMTP id NAA05856;
	Mon, 14 May 2001 13:34:21 +0200 (CEST)
X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs
Date: Mon, 14 May 2001 13:34:21 +0200 (CEST)
From: "Henk Uijterwaal (RIPE-NCC)" 
To: "Geib, Ruediger" 
cc: ippm@advanced.org
Subject: Re: [ippm] OWDP: Is measurement box access speed information required?
In-Reply-To: 
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 

On Mon, 14 May 2001, Geib, Ruediger wrote:

> Hi IPPMers,
> 
> should I come back on something already discussed, please drop this message.
> 
> My question is whether sender/receiver need to provide information on
> their access speeds. The access speed of the measurement equipment
> will determine the "resolution of time" the system can provide
> depending on the packet length. In some cases, it may be useful to
> know the minimum distance in time two packets can have due to access
> speed limitations.

But this only sets an upper limit on the number of packets a sender can
send to a receiver.  It will work if only one sender sends packets to a
receiver, but, in practice, usually more than 1 sender will be sending
packets to a receiver.

Wouldn't it be much more practical to have a receiver send a
OWDP-session-reject if a sender asks to send data to a receiver at a rate
that the receiver cannot cope with, taking into account all active
sessions?

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: henk.uijterwaal@ripe.net
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445 
The Netherlands                   Mobile: +31.6.55861746  
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)


_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 07:43:13 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07320
	for ; Mon, 14 May 2001 07:43:13 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EBg3C05208;
	Mon, 14 May 2001 07:42:03 -0400
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EBfmC05099
	for ; Mon, 14 May 2001 07:41:49 -0400
Received: from x49.ripe.net (x49.ripe.net [193.0.1.49])
	by birch.ripe.net (8.8.8/8.8.8) with ESMTP id NAA00209;
	Mon, 14 May 2001 13:41:46 +0200 (CEST)
Received: from localhost (henk@localhost)
	by x49.ripe.net (8.8.8/8.8.5) with ESMTP id NAA05918;
	Mon, 14 May 2001 13:41:45 +0200 (CEST)
X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs
Date: Mon, 14 May 2001 13:41:45 +0200 (CEST)
From: "Henk Uijterwaal (RIPE-NCC)" 
To: Ben Teitelbaum 
cc: "Geib, Ruediger" , ippm@advanced.org
Subject: Re: [ippm] OWDP coding proposal
In-Reply-To: <3AFF8B9E.CA2A0EBB@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 

On Mon, 14 May 2001, Ben Teitelbaum wrote:

> Ruediger and Henk,
> 
> While the generality of Profile Identifier/Profile Parameters is appealing,
> I'd rather not achieve generality through indirection and deferral, when we
> could do a pretty good job right now.

Can't we do both: use Ruediger's proposal for a profile identifier and put
a number of currently popular cases in the draft, reserving the others? 

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: henk.uijterwaal@ripe.net
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445 
The Netherlands                   Mobile: +31.6.55861746  
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)


_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 08:41:22 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAB08964
	for ; Mon, 14 May 2001 08:41:22 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4ECd3C11569;
	Mon, 14 May 2001 08:39:03 -0400
Received: from david.ttt.bme.hu (david.ttt.bme.hu [152.66.246.102])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4ECc4C11542
	for ; Mon, 14 May 2001 08:38:04 -0400
Received: from ttt-atm.ttt.bme.hu (ttt-atm.ttt.bme.hu [152.66.246.81])
	by david.ttt.bme.hu (8.9.1/8.9.1) with ESMTP id OAA20994;
	Mon, 14 May 2001 14:37:43 +0200 (MET DST)
Received: from TTT-ATM/SpoolDir by ttt-atm.ttt.bme.hu (Mercury 1.48);
    14 May 01 14:44:43 +0100
Received: from SpoolDir by TTT-ATM (Mercury 1.48); 14 May 01 14:44:14 +0100
Received: from ttt-atm.ttt.bme.hu (152.66.246.28) by ttt-atm.ttt.bme.hu (Mercury 1.48) with ESMTP;
    14 May 01 14:43:46 +0100
Message-ID: <3AFFD29F.3C59A90E@ttt-atm.ttt.bme.hu>
Date: Mon, 14 May 2001 14:42:07 +0200
From: Sandor Molnar 
Organization: Technical University of Budapest
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: manet@itd.nrl.navy.mil, mobile-ip@sunroof.eng.sun.com, te-wg@ops.ietf.org,
        diffserv@ietf.org, ippm@advanced.org
Content-Type: multipart/mixed;
 boundary="------------24A067880866993C333B344C"
Subject: [ippm] MONET cfp on Performance Evaluation of Qos Architectures in Mobile
 Networks
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.
--------------24A067880866993C333B344C
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4ECd3C11569
Content-Transfer-Encoding: quoted-printable

Our apologies, if you receive multiple copies of this CfP.
---------------------------------------------------------------------

CALL FOR PAPERS

Special Issue of the Journal on Special Topics in Mobile
Networking and Applications (MONET) on

Performance Evaluation of Qos Architectures in Mobile Networks

GUEST EDITORS

Dr. S=E1ndor Moln=E1r
High Speed Networks Laboratory
Dept. of Telecommunication and Telematics
Budapest University of Technology and Economics
P=E1zm=E1ny P=E9ter s. 1/D, H-1117 Budapest, Hungary
Phone: +36 1 463 3889
Fax: +36 1 463 3107
Email: molnar@ttt-atm.ttt.bme.hu

Dr. Kin K. Leung
AT&T Labs, Room 5A-1D35
200 South Laurel Avenue
Middletown, NJ 07748, U.S.A.
phone: 732-420-9041
fax: 732-368-9426
email: kkleung@research.att.com


OVERVIEW:

Future mobile networks are being designed for carrying multimedia
calls, including voice and bursty data transmission. Many studies
have predicted a large increase of customer demands for the mobile
services and applications in the near future. To meet these
demands with adequate Quality of Services (QoS), we must devise
efficient network and service architectures. In contrast to the
wired networks, there is not enough understanding or availability
of traffic characteristics, measurements, performance analysis and
models for mobile networks. However, such understanding of
teletraffic issues is vital for designing and dimensioning
efficient mobile networks.

These networks will incorporate different networking technologies,
control algorithms and versatile services. How to guarantee the
required QoS of mobile services as expected by customers, using
present and future technologies, presents a real challenge for
mobile-network researchers.

SCOPE:

This special issue will concentrate on the performance evaluation
of different architectures supporting QoS in mobile networks, and
the traffic issues and performance models in such environments.

Areas of interest include but are not limited to

* Performance evaluation of
   wireless ATM,
   wireless LANs,
   wireless Internet and Intranet
   mobile IP and nomadic communications
   next generation mobile systems, UMTS and IMT-2000
   mobile multimedia and mobile personal communication
* Resource management, dynamic channel and bandwidth assignment
* Quality of Service and Service Level Guarantees in mobile systems
* Admission Control in mobile networks
* Models of mobile user traffic generation
* Traffic measurements and analysis of mobile networks
* Traffic models in mobile networks
* Mobility management protocols and performance
* Internetworking of wireless and wired networks for QoS

PUBLICATION SCHEDULE:

MANUSCRIPT DUE: October 31, 2001=20
ACCEPTANCE NOTIFICATION: March 29, 2002=20
FINAL MANUSCRIPT DUE: May 31, 2002=20

SUBMISSION GUIDELINES:

Authors should submit an electronic postscript or pdf copy of their
papers to both guest editors (molnar@ttt-atm.ttt.bme.hu,
kkleung@research.att.com) by the due date. Submissions should be limited
to 20 double space pages excluding figures, graphs and illustrations.=20
If email submission is impossible, then three (3) copies of the paper
should be sent by the due date to each of the co-guest editors.

For more information visit: http://www.wkap.nl/kaphtml.htm/MONECFP4
--------------24A067880866993C333B344C
Content-Type: text/x-vcard; charset=us-ascii;
 name="molnar.vcf"
Content-Description: Card for Sandor Molnar
Content-Disposition: attachment;
 filename="molnar.vcf"
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4ECd3C11569
Content-Transfer-Encoding: quoted-printable

begin:vcard=20
n:Moln=E1r;S=E1ndor
tel;fax:+ 36 1 463 3107
tel;work:+ 36 1 463 3889
x-mozilla-html:FALSE
url:http://hsnlab.ttt.bme.hu/~molnar
org:Budapest University of Technology and Economics;Department of Telecom=
munications and Telematics
adr:;;P=E1zm=E1ny P=E9ter s=E9t=E1ny 1/D;Budapest;;H-1117;Hungary
version:2.1
email;internet:molnar@ttt-atm.ttt.bme.hu
title:Assistant Professor
x-mozilla-cpt:;-1
fn:Dr. S=E1ndor Moln=E1r
end:vcard

--------------24A067880866993C333B344C--

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 09:44:22 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11310
	for ; Mon, 14 May 2001 09:44:21 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EDh3C27213;
	Mon, 14 May 2001 09:43:03 -0400
Received: from mucus.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EDgPC27162;
	Mon, 14 May 2001 09:42:27 -0400
X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be mucus.advanced.org
Received: from internet2.edu (localhost [127.0.0.1])
	by mucus.advanced.org (Postfix) with ESMTP
	id 634E510CB; Mon, 14 May 2001 09:46:59 -0400 (EDT)
Message-ID: <3AFFE1D1.7B2203BC@internet2.edu>
Date: Mon, 14 May 2001 09:46:57 -0400
From: Ben Teitelbaum 
Organization: Internet2 (UCAID) / Advanced Network & Services
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henk Uijterwaal (RIPE-NCC)" 
Cc: "Geib, Ruediger" , ippm@advanced.org
Subject: Re: [ippm] OWDP coding proposal
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0beta5
Precedence: bulk
List-Id: IETF IP Performance Metrics Working Group List 
Content-Transfer-Encoding: 7bit

"Henk Uijterwaal (RIPE-NCC)" wrote:
> 
> On Mon, 14 May 2001, Ben Teitelbaum wrote:
> 
> > Ruediger and Henk,
> >
> > While the generality of Profile Identifier/Profile Parameters is appealing,
> > I'd rather not achieve generality through indirection and deferral, when we
> > could do a pretty good job right now.
> 
> Can't we do both: use Ruediger's proposal for a profile identifier and put
> a number of currently popular cases in the draft, reserving the others?
> 

Yes, I suppose we could. If we did so, I'd advocate defining a profile
identifier for an explicit test packet schedule specified in the Profile
Parameters area. 


-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum
                           -   Advanced Network & Services, Inc.
                           .   Internet2
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 16:08:17 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23507
	for ; Mon, 14 May 2001 16:08:17 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EK58C24611;
	Mon, 14 May 2001 16:05:08 -0400
Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EK4sC24405
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL)
	for ; Mon, 14 May 2001 16:04:58 -0400
Received: from cain.internet2.edu (localhost [127.0.0.1])
	by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EK4pS05782
	for ; Mon, 14 May 2001 16:04:51 -0400
X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu
Received: by cain.internet2.edu (Postfix, from userid 1000)
	id 694515A6; Mon, 14 May 2001 08:29:22 -0400 (EDT)
To: ippm@advanced.org
Subject: Re: [ippm] OWDP coding proposal
References:  <3AF02B8C.ED38EDF0@intec.rug.ac.be>
From: stanislav shalunov 
Date: 14 May 2001 08:29:22 -0400
In-Reply-To: <3AF02B8C.ED38EDF0@intec.rug.ac.be>
Message-ID: <87eltsyuzh.fsf@cain.internet2.edu>
Lines: 28
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 

Steven Van den Berghe  writes:

> Modified  request-session-message

[Append field called "Optional TLV's" and remove Type-P descriptor to
existing Request-Session command format.]

> Observe that, due to the fact that the draft specifies that
> OWDP-control goes over TCP, we know the size of the packets, hence
> we also know how many TLVs are following. I don' seem to find a
> reason for adding padding to the control-protocol (of course, i'll
> probably be missing out on something, as usual).

Steven,

Just a quick note for now:

1. We don't know when to stop reading the current command from the TCP
   connection.

2. Zero padding isn't used to indicate the end of something (end is
   determined from known fixed size); it's to ensure message integrity
   in authenticated and encrypted modes.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

"Hey!  Who took the cork off my lunch?!"               -- W. C. Fields
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 16:10:01 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23544
	for ; Mon, 14 May 2001 16:10:01 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EK5CC24632;
	Mon, 14 May 2001 16:05:12 -0400
Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EK4uC24406
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL)
	for ; Mon, 14 May 2001 16:05:00 -0400
Received: from cain.internet2.edu (localhost [127.0.0.1])
	by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EK4rS05874
	for ; Mon, 14 May 2001 16:04:53 -0400
X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu
Received: by cain.internet2.edu (Postfix, from userid 1000)
	id 512F1579; Mon, 14 May 2001 08:19:59 -0400 (EDT)
To: ippm@advanced.org
Subject: Re: [ippm] OWDP: Is measurement box access speed information required?
References: 
From: stanislav shalunov 
Date: 14 May 2001 08:19:59 -0400
In-Reply-To: 
Message-ID: <87heyoyvf4.fsf@cain.internet2.edu>
Lines: 42
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 

"Geib, Ruediger"  writes:

> My question is whether sender/receiver need to provide information
> on their access speeds.

Current spec doesn't have any place to provide such information.
When deciding whether to provide it we need to recognize that for an
application program it may be quite hard to obtain this information in
a reliable manner; further, a typical bottleneck-close-to-an-edge
might not be the access link (which is now typically 100Mbps and
GigE will likely become more typical later)--thus, the interesting
speed more often than not will not be available to the measurement
host at all (and when it is available, there will be no way to tell
whether it's the right number or not).

Surely, link speeds (all along the path and not just the remote end;
and utilizations with various averaging periods) are interesting
parameters.  It's possible that they are, in fact, the parameters that
the end user wants to know.  But should a delay measurement protocol
become a place to leran these things (or things that are just as
important, such as network topology)?  I think not...

It seems pretty meaningless to me to go to a great pain of figuring
out that the Ethernet card is in fact in 10Gbps mode only to omit the
fact that the Ethernet is behind a much slower link.

Making the end link capacity (probably the least interesting of all
intermediate capacities) a somehow preferred parameter seems not very
useful.

Short trains of back-to-back packets would provide more interesting
information (about the bottleneck, not about access link).  Whether
and how to allow to specify them (and other useful things) is the
question that I think needs to be discussed.

Concrete suggestions on how to specify a broader class of inter-packet
interval distributions would be most welcome.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed at 600 dpi.
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 16:51:37 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24435
	for ; Mon, 14 May 2001 16:51:36 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EKj3C01211;
	Mon, 14 May 2001 16:45:03 -0400
Received: from tadarida.theasis.com (tadarida.theasis.com [206.9.240.247])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EKi8C01178
	for ; Mon, 14 May 2001 16:44:13 -0400
Received: from localhost (andy@localhost)
	by tadarida.theasis.com (8.9.2/8.9.2) with SMTP id PAA28928
	for ; Mon, 14 May 2001 15:43:01 -0500 (CDT)
X-Authentication-Warning: tadarida.theasis.com: andy owned process doing -bs
Date: Mon, 14 May 2001 15:43:01 -0500 (CDT)
From: Andy Scherrer 
X-Sender: andy@tadarida.theasis.com
Reply-To: Andy Scherrer 
To: ippm@advanced.org
Subject: Re: [ippm] OWDP: inter-packet interval distributions
In-Reply-To: <87heyoyvf4.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 

> Concrete suggestions on how to specify a broader class of inter-packet
> interval distributions would be most welcome.

Why do interval distributions have to be _specified_ at all? The IPPM role
should be to point out that it may be of interest to chose this
distribution based on desired effects, and then maybe give some examples.
i.e., Uniform for ease of scheduling, pseudorandom from some distribution
for various other advantages (and disadvantages!). Maybe some guidelines
indicating that Poisson streams are achieved by using exponential
inter-packet delays. But forcing/assuming that all applications will be
served by a Poisson(lambda) test stream seems inappropriate.  

Specifying too much control over "recommended" data distributions has too
much bearing on the distribution of the _collected_ data, rather than on
the methods of collecting, which, IMO, is a more apt focus.

Assuming for the moment that someone agrees with that, then the problem
remains how to specify the distribution that you're using inside the
packet? i.e., the
 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Inv-Lambda                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

section? 

Well I guess one advantage of forcing everyone to use Poisson data streams
is that you can memorize from draft-ietf-ippm-owdp-02.txt the definition
of which parametrization (there are at least 2, and the units of
microseconds becomes very important) of Poisson distribution you're using,
and everyone would presumably know what it means. 

Alternatively, though, that field could house a code that refers to some
long-winded specification which is usable in a flexible way by a
particular experimenter. For example, I could say that for my experiments,
"Type 6 data stream is a Poisson stream whose lambda is Gaussian with
mean 90 and variance 200 milliseconds".

Given that as a general perspective, do you want more concrete? 

Andy Scherrer
Matrix.Net, Inc.
http://www.matrix.net/


> -- 
> Stanislav Shalunov		http://www.internet2.edu/~shalunov/


_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 18:01:20 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25580
	for ; Mon, 14 May 2001 18:01:19 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EM04C17915;
	Mon, 14 May 2001 18:00:04 -0400
Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4ELxqC17796
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL)
	for ; Mon, 14 May 2001 17:59:57 -0400
Received: from cain.internet2.edu (localhost [127.0.0.1])
	by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4ELxnS07694
	for ; Mon, 14 May 2001 17:59:49 -0400
X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu
Received: by cain.internet2.edu (Postfix, from userid 1000)
	id BB1DC5A1; Mon, 14 May 2001 17:59:47 -0400 (EDT)
To: ippm@advanced.org
Subject: Re: [ippm] OWDP: inter-packet interval distributions
References: 
From: stanislav shalunov 
Date: 14 May 2001 17:59:47 -0400
In-Reply-To: 
Message-ID: <878zjzy4ks.fsf@cain.internet2.edu>
Lines: 23
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 

Andy Scherrer  writes:

> Why do interval distributions have to be _specified_ at all?

For the protocol implementation, the receiver has to know when to
expect packets to be able to decide when packets are lost.  Somehow,
the information about packet schedule has to be communicated.  Sending
the whole schedule beforehand is wasteful and inconvenient (you might
want to generate it as you go).  A way out is to specify given
distribution and describe how to generate pseudo-random numbers
matching that.

The question of which _metrics_ are defined is, strictly speaking,
orthogonal to the question of what the protocol can do.  Currently
defined metrics are all singleton (and Poisson inter-packet time
serves well here).  This doesn't mean the protocol _has_ to be
restricted to only measuring that.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Democracy is a form of government that substitutes election by the incompetent
many for appointment by the corrupt few.                         -- G. B. Shaw
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 14 18:59:58 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26779
	for ; Mon, 14 May 2001 18:59:57 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EMtBC29481;
	Mon, 14 May 2001 18:55:11 -0400
Received: from tadarida.theasis.com (tadarida.theasis.com [206.9.240.247])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4EMsVC29455
	for ; Mon, 14 May 2001 18:54:32 -0400
Received: from localhost (andy@localhost)
	by tadarida.theasis.com (8.9.2/8.9.2) with SMTP id RAA29007
	for ; Mon, 14 May 2001 17:53:25 -0500 (CDT)
X-Authentication-Warning: tadarida.theasis.com: andy owned process doing -bs
Date: Mon, 14 May 2001 17:53:25 -0500 (CDT)
From: Andy Scherrer 
X-Sender: andy@tadarida.theasis.com
To: ippm@advanced.org
Subject: Re: [ippm] OWDP: inter-packet interval distributions
In-Reply-To: <878zjzy4ks.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 

> > Why do interval distributions have to be _specified_ at all?
> 
> For the protocol implementation, the receiver has to know when to
> expect packets to be able to decide when packets are lost.  Somehow,
> the information about packet schedule has to be communicated.  Sending
> the whole schedule beforehand is wasteful and inconvenient (you might
> want to generate it as you go).  A way out is to specify given
> distribution and describe how to generate pseudo-random numbers
> matching that.

Well, if it needs to know a schedule at a per-packet level, you'd have to
specify not the distribution, but the complete algorithm and random seed. 
I.e., I'm gonna generate my poisson stream by using such and such an
algorithm, using drand48(), and the seed is blah. 

Otherwise, there's no hope of predicting the next packet, precisely
because of the properties of the Poisson stream that are considered
desirable. 

So you're still stuck with sending the schedule before you execute it,
whether in bursts or totally in advance. 

> The question of which _metrics_ are defined is, strictly speaking,
> orthogonal to the question of what the protocol can do.  Currently
> defined metrics are all singleton (and Poisson inter-packet time
> serves well here).  This doesn't mean the protocol _has_ to be
> restricted to only measuring that.

True enough... But I'm thinking more of the perturbation of the
distribution of the process that you're trying to measure (the network) by
the distribution that you're inserting in your data stream. At the
measurement end, the distribution you're recording is some weird mixture
of the two, and it makes statistical treatment, e.g., variance
calculations, much more awkward. 

Hopefully those who want to use a uniform inter-packet time will still
find it easy to do so. At the other extreme, it may be desirable to
construct & study much more complex packet-sending distributions than is
made available through a 1-dimensional Poisson model; my earlier example
is only slightly more complicated. 

Andy Scherrer
Matrix.Net, Inc.
http://www.matrix.net/


> -- 
> Stanislav Shalunov		http://www.internet2.edu/~shalunov/
> 
> Democracy is a form of government that substitutes election by the incompetent
> many for appointment by the corrupt few.                         -- G. B. Shaw
> _______________________________________________
> 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  Tue May 15 05:28:40 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19405
	for ; Tue, 15 May 2001 05:28:40 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4F9R7C02077;
	Tue, 15 May 2001 05:27:07 -0400
Received: from mucus.advanced.org (localhost [127.0.0.1])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4F9QlC01868
	for ; Tue, 15 May 2001 05:26:48 -0400
X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be mucus.advanced.org
Received: from internet2.edu (localhost [127.0.0.1])
	by mucus.advanced.org (Postfix) with ESMTP id A4CB510CF
	for ; Tue, 15 May 2001 05:31:26 -0400 (EDT)
Message-ID: <3B00F639.A2C339BD@internet2.edu>
Date: Tue, 15 May 2001 05:26:17 -0400
From: Ben Teitelbaum 
Organization: Internet2 (UCAID) / Advanced Network & Services
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ippm@advanced.org
Subject: Re: [ippm] OWDP: inter-packet interval distributions
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0beta5
Precedence: bulk
List-Id: IETF IP Performance Metrics Working Group List 
Content-Transfer-Encoding: 7bit

Andy Scherrer wrote:
> 
> > > Why do interval distributions have to be _specified_ at all?
> >
> > For the protocol implementation, the receiver has to know when to
> > expect packets to be able to decide when packets are lost.  Somehow,
> > the information about packet schedule has to be communicated.  Sending
> > the whole schedule beforehand is wasteful and inconvenient (you might
> > want to generate it as you go).  A way out is to specify given
> > distribution and describe how to generate pseudo-random numbers
> > matching that.
> 
> Well, if it needs to know a schedule at a per-packet level, you'd have to
> specify not the distribution, but the complete algorithm and random seed.
> I.e., I'm gonna generate my poisson stream by using such and such an
> algorithm, using drand48(), and the seed is blah.
> 

Right. That's exactly what we have attempted to do in section 5.1 of
draft-ietf-ippm-owdp-01.txt.

-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum
                           -   Advanced Network & Services, Inc.
                           .   Internet2


_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue May 15 14:29:48 2001
Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04709
	for ; Tue, 15 May 2001 14:29:47 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4FISAC20575;
	Tue, 15 May 2001 14:28:10 -0400
Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4FIRUC20462
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL)
	for ; Tue, 15 May 2001 14:27:35 -0400
Received: from cain.internet2.edu (localhost [127.0.0.1])
	by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4FIROS23703
	for ; Tue, 15 May 2001 14:27:27 -0400
X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu
Received: by cain.internet2.edu (Postfix, from userid 1000)
	id 297245A1; Tue, 15 May 2001 14:27:23 -0400 (EDT)
To: ippm@advanced.org
Subject: Re: [ippm] OWDP: inter-packet interval distributions
References: 
From: stanislav shalunov 
Date: 15 May 2001 14:27:23 -0400
In-Reply-To: 
Message-ID: <873da6xyb8.fsf@cain.internet2.edu>
Lines: 70
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 

Andy Scherrer  writes:

> Well, if it needs to know a schedule at a per-packet level, you'd have to
> specify not the distribution, but the complete algorithm and random seed. 
> I.e., I'm gonna generate my poisson stream by using such and such an
> algorithm, using drand48(), and the seed is blah. 

In draft-ietf-ippm-owdp-02.txt, section 5.1 pp. 18-19 it is said:

>   The time elapsed between packets is pseudo-random, with exponential
>   distribution (resulting in a Poisson stream of packets).  As
>   suggested in RFC 2330, the ith sampling interval Ei may be computed
>   using inverse transform:

>        Ei = -ln(Ui) * Inv-Lambda

>   where Ui is uniformly distributed between 0 and 1 and lambda is the
>   desired mean time between packets.

>   Pseudo-random stream of bits is obtained using AES with SID as the
>   key, running in counter mode (first encrypted block is 0, second
>   encrypted block is 1 in network octet order, etc.)  Each block of 64
>   bits is used to obtain one pseudo-random number uniformly distributed
>   between 0 and 1.  If the bits are Bj (j=1..64, numbered left to
>   right), the resulting value is
>        U = B1*2^{-1} + B2*2^{-2} + ... B64*2^{-64}

>   The parameter lambda is has the value requested in the Request-
>   Session message of the OWDP-Control negotiation that spawned the
>   session.

>   The logarithm and division in the formula above MUST be computed
>   using IEEE 754 standard floating point arithmetic. [HELP WANTED!:
>   Someone with a stronger background in numerical analysis to specify
>   how to compute the sampling intervals precisely and portably!]

If you have suggestions on how to make this clearer don't hesitate to
tell us.

> True enough... But I'm thinking more of the perturbation of the
> distribution of the process that you're trying to measure (the network) by
> the distribution that you're inserting in your data stream. At the
> measurement end, the distribution you're recording is some weird mixture
> of the two, and it makes statistical treatment, e.g., variance
> calculations, much more awkward. 

Poisson stream with low rate is fine (and a safe choice) for
measurement of singleton metrics in such a way that measurement
doesn't affect the state of the network.

We hear repeated requests for adding features for measurement of
characteristics not currently standartized (and measurement of which
relies on changing the network state).  Doing it in a flexible,
general, elegant, and economical way would be great.  Concrete
suggestions are welcome.

> Hopefully those who want to use a uniform inter-packet time will still
> find it easy to do so. At the other extreme, it may be desirable to
> construct & study much more complex packet-sending distributions than is
> made available through a 1-dimensional Poisson model; my earlier example
> is only slightly more complicated. 

In its current form, OWDP supports only a single distribution of
inter-packet intervals (exponential).

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

A fanatic is one who can't change his mind and won't change the
subject.                                   -- Winston Churchill
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu May 17 09:15:26 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16721
	for ; Thu, 17 May 2001 09:15:25 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4HDC3C00493;
	Thu, 17 May 2001 09:12:03 -0400
Received: from tadarida.theasis.com (tadarida.theasis.com [206.9.240.247])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4HDBhC00468
	for ; Thu, 17 May 2001 09:11:44 -0400
Received: from localhost (andy@localhost)
	by tadarida.theasis.com (8.9.2/8.9.2) with SMTP id IAA01453
	for ; Thu, 17 May 2001 08:10:11 -0500 (CDT)
X-Authentication-Warning: tadarida.theasis.com: andy owned process doing -bs
Date: Thu, 17 May 2001 08:10:11 -0500 (CDT)
From: Andy Scherrer 
X-Sender: andy@tadarida.theasis.com
Reply-To: Andy Scherrer 
To: ippm@advanced.org
Subject: Re: [ippm] OWDP: inter-packet interval distributions
In-Reply-To: <873da6xyb8.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 


(sorry for the delay in following up...)

> In draft-ietf-ippm-owdp-02.txt, section 5.1 pp. 18-19 it is said:

[ . . . ] 

> >   The logarithm and division in the formula above MUST be computed
> >   using IEEE 754 standard floating point arithmetic. [HELP WANTED!:
> >   Someone with a stronger background in numerical analysis to specify
> >   how to compute the sampling intervals precisely and portably!]

> If you have suggestions on how to make this clearer don't hesitate to
> tell us.

I did go back and read that section more carefully after Ben's note that
same morning. Of course I'll suggest any specific improvements I can think
of. 

> In its current form, OWDP supports only a single distribution of
> inter-packet intervals (exponential).

This is back to my original point. I was hoping that I'd missed something
in the document and that there _was_ a way to perform experiments within
the guidelines of draft-ietf-ippm-owdp-02.txt but not be restricted to
Poisson streams. I can certainly see that it's difficult to define a
single formula that's explicit and transportable, yet more general.

But, to reiterate, IMHO, restricting it that far degrades the utility of
the OWDP protocol. Emphasizing Poisson/Exponential to the exclusion of
Uniform or Gaussian or even 'equal spacing' -- is this really better than
just sending the whole schedule ahead of time? Maybe. Is it really
necessary?

I'm still hoping there is some way within the current structure (which I
probably don't understand fully) to circumvent that requirement so that
non-Poisson intervals can be negotiated, perhaps out of band, but at least
referred to in the OWDP framework.

Ideally it would be possible to implement something like, "Use Inverse
transform formula #3.2 from the table of formulae we previously
negotiated. Parameters are alpha,beta,lambda and seed X". This is
preferable (simpler and more flexible, but not so restrictive) to trying
to _specify_ a more general inverse transform (e.g., one covering all
exponential family) than the one mentioned: 

>        Ei = -ln(Ui) * Inv-Lambda

A *default* inverse transform yielding Poisson/Exponential is not at all
objectionable to me. 

So can you see a practical way to employ the capability I describe?
Does anyone agree that it would be preferable not to be limited to
Poisson-only streams?

Thanks,

Andy Scherrer

> -- 
> Stanislav Shalunov		http://www.internet2.edu/~shalunov/




_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu May 17 16:35:17 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26545
	for ; Thu, 17 May 2001 16:35:16 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4HKY3C10793;
	Thu, 17 May 2001 16:34:03 -0400
Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4HKXuC10773
	for ; Thu, 17 May 2001 16:33:57 -0400
Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA09554
	for ; Thu, 17 May 2001 16:31:11 -0400 (EDT)
To: ippm@advanced.org
From: "Patricia K. Maier" 
Date: Thu, 17 May 2001 16:31:11 -0400
Message-ID: 
X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at
 05/17/2001 04:31:12 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [ippm] packet delay variation
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 am a newcomer to this arena.

In draft-ietf-ippm-ipdv-07, the outcome of delay variation evidently
depends on the choice of the selection function, which appears to be
totally arbitrary.  Are there any particular criteria that can be applied
or some guidance on how to choose F.

Thanks

PK Maier

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri May 18 02:36:23 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18012
	for ; Fri, 18 May 2001 02:36:22 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4I6Z4C21857;
	Fri, 18 May 2001 02:35:04 -0400
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f4I6YfC21833
	for ; Fri, 18 May 2001 02:34:42 -0400
X-Authentication-Warning: mailhost.advanced.org: Host p-mail1.rd.francetelecom.fr [193.49.124.31] claimed to be p-mail1.cnet.fr
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Fri, 18 May 2001 08:34:32 +0200
Message-ID: 
From: ADAM Yann FTRD/DAC/LAN 
To: "'ippm@advanced.org'" 
Date: Fri, 18 May 2001 08:34:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [ippm] 1-point, 2-points IPDV
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 all,

the current draft-ietf-ippm-ipdv-07.txt draft defines a 2-points IPDV. This
metric is essential for Network Service Providers because they must be able
to qualify and garantee the jitter in their network, whatever the jitter can
be at the entry of their network.

But, IMHO, this metric is meaningless for applications: applications suffer
the cumulative jitter at the network point where they are implemented. Thus,
I think a 1-point IPDV could be defined for this type of meausrement.
Moreover, (new) applications like VoIP, video streaming, are very sensitive
to the jitter, packet loss and OWD. These metrics can be found in RTCP
packets but they are related to RTP streams, and they concern the
application level, which in not in the scope of the IPPM WG. In conclusion,
I would say that there is a place here to define a new metric which could be
very usefull for new services.

Maybe I'm wrong whith this issue, what do you think of this idea ?

Yann
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Fri May 18 09:40:46 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26744
	for ; Fri, 18 May 2001 09:40:45 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4IDd3C08362;
	Fri, 18 May 2001 09:39:03 -0400
Received: from plinius.intec2.rug.ac.be (plinius.intec2.rug.ac.be [157.193.122.4])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4IDckC08335
	for ; Fri, 18 May 2001 09:38:46 -0400
Received: from intec.rug.ac.be (daisne.intec2.rug.ac.be [157.193.122.92])
	by plinius.intec2.rug.ac.be (Postfix) with ESMTP
	id ED21CEEA9; Fri, 18 May 2001 15:38:41 +0200 (CEST)
Message-ID: <3B0525E2.1B00232F@intec.rug.ac.be>
Date: Fri, 18 May 2001 15:38:42 +0200
From: Steven Van den Berghe 
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IPPM Working Group 
Content-Type: multipart/mixed;
 boundary="------------7B32AFA812D3213C2D63E86C"
Subject: [ippm] FYI: [Fwd: I-D ACTION:draft-wlai-tewg-measure-01.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 

This is a multi-part message in MIME format.
--------------7B32AFA812D3213C2D63E86C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

There is a new draft available on the measurement framework for Traffic
Engineering, which is a merged version of all the draft-work previously
done in this area.

Best regards,
Steven

-------- Original Message --------
Subject: I-D ACTION:draft-wlai-tewg-measure-01.txt
Date: Fri, 18 May 2001 06:55:36 -0400
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: A Framework for Internet Traffic Engineering 
                          Measurement
	Author(s)	: W. Lai
	Filename	: draft-wlai-tewg-measure-01.txt
	Pages		: 15
	Date		: 17-May-01
	
In this document, a measurement framework for supporting the traffic
engineering of IP-based networks is presented.  It is intended for
the TEM (Traffic Engineering Measurement) category as described in
the TEWG charter.  Consideration for including this document as a
TEWG working-group item for further development is requested.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wlai-tewg-measure-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-wlai-tewg-measure-01.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-wlai-tewg-measure-01.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.

---

Steven Van den Berghe
steven.vandenberghe@intec.rug.ac.be
Workgroup Broadband-Networks
Department Information Technology
Ghent University - Belgium
Phone:  +32 (0)9 267 35 86 | Fax  :  +32 (0)9 267 35 99
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
I cna ytpe 300 wrods pre mniuet!!!
 
 
 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
--------------7B32AFA812D3213C2D63E86C
Content-Type: Message/External-body;
 name="draft-wlai-tewg-measure-01.txt"
Content-Disposition: inline;
 filename="draft-wlai-tewg-measure-01.txt"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<20010517131913.I-D@ietf.org>


--------------7B32AFA812D3213C2D63E86C--

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Tue May 22 10:23:54 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19685
	for ; Tue, 22 May 2001 10:23:53 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4MEL2C00847;
	Tue, 22 May 2001 10:21:02 -0400
Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4MEKIC00718
	for ; Tue, 22 May 2001 10:20:18 -0400
Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA21596
	for ; Tue, 22 May 2001 10:13:30 -0400 (EDT)
To: ippm@advanced.org
From: "Patricia K. Maier" 
Date: Tue, 22 May 2001 10:13:32 -0400
Message-ID: 
X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at
 05/22/2001 10:13:32 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [ippm] IP delay variation selection function
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 

Have there been any contributions on what constitues a good selection
function, F, to measure IP packet delay variation?

It seems that an arbitrary F would allow almost an arbitrary metric for
delay variation.  Since the metric could then be defined uniquely for
different implementations, how can the outcomes be compared it measurements
are made with different functions, F?

PKM

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed May 23 05:18:47 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29358
	for ; Wed, 23 May 2001 05:18:47 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4N9D2C08179;
	Wed, 23 May 2001 05:13:02 -0400
Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4N9CPC08156
	for ; Wed, 23 May 2001 05:12:25 -0400
Received: from oleane (dyn-1-1-191.Vin.dialup.oleane.fr [195.25.4.191]) by smtp4.cluster.oleane.net with SMTP id f4N9CLf41651 for ; Wed, 23 May 2001 11:12:21 +0200 (CEST)
Message-ID: <002101c0e368$7b714a60$8001a8c0@oleane.com>
From: "Peter Lewis" 
To: 
Date: Wed, 23 May 2001 11:12:24 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01C0E379.3EB6F6E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [ippm] IP Performance Conference
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_000_001E_01C0E379.3EB6F6E0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Improving TCP performance. Measuring transit delay in the network as =
well as in the equipments. Monitoring, reporting, billing tools.IP SLAs. =
Passive or active measurement:

The IP Performance Conference will stand in Paris, from 20 to 23rd =
November, 2001.

A call for proposals is online at:

http://www.upperside.fr/ipperf/ipperfcfp.htm


------=_NextPart_000_001E_01C0E379.3EB6F6E0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Improving TCP performance. Measuring transit delay in the network as =
well as=20
in the equipments. Monitoring, reporting, billing tools.IP SLAs. Passive =
or=20
active measurement:


The IP Performance Conference will =
stand in=20
Paris, from 20 to 23rd November, 2001.


A call for proposals is online at:


http://www.uppersid=
e.fr/ipperf/ipperfcfp.htm


------=_NextPart_000_001E_01C0E379.3EB6F6E0--

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed May 23 12:14:40 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08647
	for ; Wed, 23 May 2001 12:14:39 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4NGD2C23458;
	Wed, 23 May 2001 12:13:02 -0400
Received: from roam.psg.com (120-59.nanog22.centergate.com [204.74.120.59])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4NGCZC23435
	for ; Wed, 23 May 2001 12:12:36 -0400
X-Authentication-Warning: mailhost.advanced.org: Host 120-59.nanog22.centergate.com [204.74.120.59] claimed to be roam.psg.com
Received: from randy by roam.psg.com with local (Exim 3.22 #1)
	id 152bFI-00053w-00; Wed, 23 May 2001 09:12:24 -0700
From: Randy Bush 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Peter Lewis" 
Cc: 
Subject: Re: [ippm] IP Performance Conference
References: <002101c0e368$7b714a60$8001a8c0@oleane.com>
Message-Id: 
Date: Wed, 23 May 2001 09:12:24 -0700
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

> Improving TCP performance. Measuring transit delay in the network as well as in the equipments. Monitoring, reporting, billing tools.IP SLAs. Passive or active measurement:
> 
> The IP Performance Conference will

hopefully getting rid of slimeball spammers like you.

randy
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Wed May 23 13:37:04 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10665
	for ; Wed, 23 May 2001 13:37:01 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4NHY3C10935;
	Wed, 23 May 2001 13:34:03 -0400
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4NHXOC10741
	for ; Wed, 23 May 2001 13:33:24 -0400
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA03113 for ; Wed, 23 May 2001 10:33:21 -0700 (MST)]
Received: [from il06exi01.CORP.MOT.COM (il06exi01.corp.mot.com [199.5.78.78]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA03108 for ; Wed, 23 May 2001 10:33:20 -0700 (MST)]
Received: by il06exi01.corp.mot.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 23 May 2001 12:33:20 -0500
Message-ID: 
From: Grotefeld Glenn-cecl03 
To: "'Randy Bush'" , Peter Lewis 
Cc: ippm@advanced.org
Subject: RE: [ippm] IP Performance Conference
Date: Wed, 23 May 2001 12:33:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0beta5
Precedence: bulk
List-Id: IETF IP Performance Metrics Working Group List 

Sorry, Randy, I believe that sending notice of an IP Performance Conference to to IP Performance Metrics WG is NOT spam.

Glenn Grotefeld

Motorola, Inc.
g.grotefeld@motorola.com
US  847 435-0730
      847 632-6800 FAX


~-----Original Message-----
~From: Randy Bush [mailto:randy@psg.com]
~Sent: Wednesday, May 23, 2001 11:12 AM
~To: Peter Lewis
~Cc: ippm@advanced.org
~Subject: Re: [ippm] IP Performance Conference
~
~
~> Improving TCP performance. Measuring transit delay in the 
~network as well as in the equipments. Monitoring, reporting, 
~billing tools.IP SLAs. Passive or active measurement:
~> 
~> The IP Performance Conference will
~
~hopefully getting rid of slimeball spammers like you.
~
~randy
~_______________________________________________
~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 May 23 22:24:18 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20809
	for ; Wed, 23 May 2001 22:24:18 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4O2N3C02415;
	Wed, 23 May 2001 22:23:03 -0400
Received: from orc.cs.waikato.ac.nz (orc.cs.waikato.ac.nz [130.217.241.22])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4O2MEC02128;
	Wed, 23 May 2001 22:22:15 -0400
Received: from orca.cs.waikato.ac.nz
	([130.217.244.4] helo=cs.waikato.ac.nz ident=sfd)
	by orc.cs.waikato.ac.nz with esmtp (Exim 3.16 #6)
	id 152klN-0007LF-00; Thu, 24 May 2001 14:22:09 +1200
Message-ID: <3B0C7051.6F361315@cs.waikato.ac.nz>
Date: Thu, 24 May 2001 14:22:09 +1200
From: Stephen Donnelly 
Organization: The University of Waikato
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ippm@advanced.org
CC: Vern Paxson , Matthew J Zekauskas ,
        Nevil Brownlee 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [ippm] rfc2330 'wire-time' discussion
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,

I am doing some detailed investigation of active and passive measurement
as part of my thesis work, including OWD. I have been working with both
RIPE and Advanced in performing passive measurements of their rfc2679
Type-P-One-way-Delay measurement systems.

In the discussion of these terms, it became clear that the IPPM
definition of the probe packet transmission and reception times needs
clarification. It was suggested that a discussion thread on the IPPM
mailing list may be useful.

rfc2330 states in section 10.2:

   In order to provide a general way of talking about these effects, we
   introduce two notions of "wire time".  These notions are only defined
   in terms of an Internet host H observing an Internet link L at a
   particular location:

 +    For a given packet P, the 'wire arrival time' of P at H on L is
      the first time T at which any bit of P has appeared at H's
      observational position on L.

 +    For a given packet P, the 'wire exit time' of P at H on L is the
      first time T at which all the bits of P have appeared at H's
      observational position on L.

And rfc2679 states in section 3.4:

   For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at
   T is dT<< means that Src sent the first bit of a Type-P packet to Dst
   at wire-time* T and that Dst received the last bit of that packet at
   wire-time T+dT.

It is not clear however if the packet P is taken to be the IP packet
itself, a layer 2 packet such as an Ethernet MAC frame, or a layer 1
packet including synchronisation signals such as Ethernet preamble.

Being an IP metric, I assume that P refers to the IP packet, do you
agree? Is this the correct definition for the wire-exit-time and
wire-arrival-time?

This means that when timestamping packets for measurement purposes, care
must be taken to correct for the offset within the physical packet
between the start of the IP packet and the point at which the timestamp
is generated. In order to do this, the data link rate of the interface
must also be known.

Although these corrections may potentially be small compared to other
delay components, there are now a number of passive measurement systems
capable of resolving packet timestamps to byte or bit time resolution,
and these distinctions can be made.

Stephen.
-- 
-----------------------------------------------------------------------
    Stephen Donnelly (BCMS)             email: sfd@cs.waikato.ac.nz
    WAND Group                      Room GG.15 phone +64 7 838 4086
    Computer Science Department, University of Waikato, New Zealand
-----------------------------------------------------------------------
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu May 24 09:11:16 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12483
	for ; Thu, 24 May 2001 09:11:15 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4ODA3C03790;
	Thu, 24 May 2001 09:10:03 -0400
Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4OD97C03753
	for ; Thu, 24 May 2001 09:09:08 -0400
Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id JAA02344
	for ; Thu, 24 May 2001 09:07:30 -0400 (EDT)
To: ippm@advanced.org
From: "Patricia K. Maier" 
Date: Thu, 24 May 2001 09:07:33 -0400
Message-ID: 
X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at
 05/24/2001 09:07:34 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [ippm] IP Delay variation selection function
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 been looking for some documented criteria on what constitutes a
"good" selection function to measure the delay variation.  I have not seen
anything in the mail archives that offers any guidance.  An intuitively
appealing metric is some measure of the "width" of the distribution of the
packet delay.  Then the resulting selection function would be equivalent to
choosing an upper and lower percentile from the population of packets under
consideration between two selected measurement points.  Specifying F
effectively to choose a range would provide a consistent way to obtain the
delay variation and permit some meaningful comparison across measurements
made by different implementations.

Are there any other known contributions to this metric within this group or
elsewhere?

Thanks
PK Maier

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Mon May 28 04:31:34 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02255
	for ; Mon, 28 May 2001 04:31:34 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4S8R2C11605;
	Mon, 28 May 2001 04:27:02 -0400
Received: from fw11.telekom.de ([62.225.183.250])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4S8Q6C11575
	for ; Mon, 28 May 2001 04:26:08 -0400
X-Authentication-Warning: mailhost.advanced.org: Host [62.225.183.250] claimed to be fw11.telekom.de
Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id KAA00441; Mon, 28 May 2001 10:26:03 +0200 (MET DST)
Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ippm@advanced.org; Mon, 28 May 2001 10:25:00 +0200
Received: from g8pbq.blf01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for ippm@advanced.org; Mon, 28 May 2001 10:24:42 +0200
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id ; Mon, 28 May 2001 10:24:41 +0200
Message-Id: 
From: "Geib, Ruediger" 
To: ippm@advanced.org
Subject: RE: [ippm] IP Delay variation selection function
Date: Mon, 28 May 2001 10:24:39 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f4S8Q6C11575
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-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4S8R2C11605
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA02255

Pasztor and Veitch presented at PAM 2001 a document called "A precision infrastructure for active probing". There they present bottleneck bandwidth measurement results based on delay differences of packets sent back to back. The method is based on Lai and Bakers "Measuring link bandwidths using a deterministic model of packet delay". 

The basic idea is to send two back to back packets and measure the delay difference caused by the bottleneck. That's an IPDV measurement.

There may be other purposes for measurements at link speed or buffer time scale measurement. Pairs of packets with a sending distance of back to back up to less than say 200 ms seem to be a reasonable measurement to me. That may not quite be what was meant by a "selection function". I think it's a good idea to cover useful evaluations of IPDV measurements by the standard to be written, so this method of IPDV measurements should be in there.

Looking at a selction function reasonable for applications may be to check the sending properties of the application first. If the application is creating a streamed packet flow, the function to select ipdv measurements should correspond to the minmum interval of the packets sent by the application.  

Regards, Rüdiger


> -----Original Message-----
> From: Patricia K. Maier [mailto:pmaier@telcordia.com]
> Sent: Thursday, May 24, 2001 3:08 PM
> To: ippm@advanced.org
> Subject: [ippm] IP Delay variation selection function
> 
> 
> I have been looking for some documented criteria on what 
> constitutes a "good" selection function to measure the delay
> variation. I have not seen anything in the mail archives 
> that offers any guidance. An intuitively appealing metric
> is some measure of the "width" of the distribution of the
> packet delay. Then the resulting selection function would be 
> equivalent to choosing an upper and lower percentile from
> the population of packets under consideration between two
> selected measurement points.  Specifying F effectively to
> choose a range would provide a consistent way to obtain the
> delay variation and permit some meaningful comparison across 
> measurements made by different implementations.
> 
> Are there any other known contributions to this metric within 
> this group or elsewhere?
> 
> Thanks
> PK Maier
> 
> _______________________________________________
> 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  Mon May 28 10:13:46 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04832
	for ; Mon, 28 May 2001 10:13:46 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4SEB3C11673;
	Mon, 28 May 2001 10:11:03 -0400
Received: from emulab.ee.mu.oz.au (potoroo.ee.mu.OZ.AU [128.250.76.186])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4SEAOC11456
	for ; Mon, 28 May 2001 10:10:29 -0400
X-Authentication-Warning: mailhost.advanced.org: Host potoroo.ee.mu.OZ.AU [128.250.76.186] claimed to be emulab.ee.mu.oz.au
Received: from ee.mu.oz.au (IDENT:darryl@sugar-glider.emulab.ee.mu.oz.au [10.0.0.5])
	by emulab.ee.mu.oz.au (8.9.3/8.9.3) with ESMTP id AAA93813
	for ; Tue, 29 May 2001 00:10:20 +1000 (EST)
	(envelope-from d.veitch@ee.mu.oz.au)
Message-ID: <3B125C4C.AF0DA58E@ee.mu.oz.au>
Date: Tue, 29 May 2001 00:10:20 +1000
From: Darryl Neil Veitch 
Organization: EMUlab
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: ippm@advanced.org
Subject: Re: [ippm] IP Delay variation selection function
References: 
Content-Type: text/plain; charset=iso-8859-1
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0beta5
Precedence: bulk
List-Id: IETF IP Performance Metrics Working Group List 
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f4SEB3C11673
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA04832

Dear OWDPers and others,

since Geib Rüdiger mentioned our work, it seems a good time to make a few comments- I have been following the OWDP discussions with interest, and I
have been wanting to make a few points for some time now on delay and loss issues.  My comments may well be too impractical in several respects with
respect to what is feasible within the protocol as it
stands, my opologies in advance.

My essential point of view is that generality is highly desirable, and I agree strongly with  Benjamin Teitelbaum's mail of the 14th May where he
argues for general inter-departure times (IDT's) and packet sizes, as well as Andy Scherrer's comments on being able to say `type 6 stream please'
(14th May) and by the comments of many that Poisson is too restrictive.
I believe that much more information about route state than is commonly suggested can be extracted by cleverly designed probe streams, and so by
limiting oneself to `Poisson' or minor variants a great deal is missed, which is not what is needed for a protocol designed for measurement.  Simple,
light weight measurement modes should be included, but surely more advanced methods must be at least allowed, even if we may not know how to define
them yet.  Furthermore `more advanced' means more sophisticated,
which does not necessarily imply heavy computational burdens nor even too
many extra parameters.  You can define a multifractal with just one 
parameter..  

In the discussions I find a number of what could be called `statistical' points are somewhat unclear.  Some important points I think are:
-  the `Poisson streams' referred to are of course not Poisson, as they 
   are truncated, and disturbed by the packet sizes. This being the 
   case, there is no reason to hold to them religiously, especially
   since the `PASTA' principle of simple queueing systems (Poisson
   Arrivals see Time Averages), does not hold in any way for end-to-end 
   delay measurements.  Without this, Poison is simply one way to get a 
   spread of values to avoid unpleasant synchronisation.
-  While Poisson gives you a spread of sizes, 
   it should be remembered that a Poisson (or pseudo Poisson) process 
   is essentially one with only a single time-scale, 
   the average IDT, and is thus morally close to a constant 
   rate. It is therefore not capable of `exciting' the route at multiple 
   time-scales and is doomed to match high resolution with high
   average probing rate, which is too invasive, leaving us with low
   rate low resolution probing, which only tells us the grosser 
   features of what is going on.  
-  when generalisations are discussed, people talk about changing `the 
   distribution', but the inter-departure distribution does not 
   determine a sending process, it is only ONe aspect of it. What is 
   often meant implicitly in effect is IID (independent indentically
   distributed) IDT's, but again this restricts us to a very
   small corner of the probing universe, what about correlations between
   IDT's?    Thus what Benjamin was proposing (or if not, 
   what I wished he proposed) was not that general IDT's be allowed in 
   the sense of a general (IID) DIstribution (this is still very restrictive) 
   but general as in arbitary NUmbers, which could be generated by
   unrestricted mechanisms (ie more complex RAndom processes) as
   developed over time. This IS full generality.  
-  Again, `more complex' does not necessarily imply at all that they
   would be onerous to generate, and by having them random, there is
   no issue of having to transmit the full stream in advance as some 
   have been discussing, you Want it to vary, only the parameters and 
   the model need be known. Furthermore losses should be allowed, the 
   receiver can be very confident in reasonable time that a packet 
   has been lost if sequence numbers can be included in the payload, 
   as packet reordering is not So common.  I say this as it was suggested
   that sending a specification of the stream in advance was needed
   as the receiver needed to know when loss had occurred.  This does not
   make a lot of sense as the route will seriously perturb the sending
   stream anyway, indeed this is the whole point.
-  again on this point of random sending, 
   there seems to be a issue regarding being able to send Exactly the 
   same stream, by specifying seeds and so on.  Although this may have 
   its uses as a special option, it does fly in the face of the whole
   philosophy of traffic measurement and engineering as I see it: 
   traffic is modelled as random, so even if the input is fixed, the
   measured output will be random (due to cross traffic) and therefore 
   it is more coherent to use random input (indeed this is what the 
   `Poisson' models always intended to provide).  Now random input does
   not exclude deterministic features (eg packet pairs). For example you
   could have random inter-pair times, and/or random group sizes 
   (triads not pairs), and there are advantages to these approaches.
    These `deterministic' features are strictly speaking just highly
   correlated features of the random sample paths in the random view of 
   traffic, although of course it is intuitively and practically useful 
   to consider their deterministic character as well.

We think that a much more general viewpoint is need. A probing process could modulate its packet size in a completely general way (with some limits of
course), and its IDT's according to Any process one desires, of arbitrary complexity. These do not even have to be stationary. Indeed, any packet pair
based method involves a highly correllated IDT sequences which fall well outside the simple Poisson model, even though this model IS still
 stationary provided one randomises the initial condition in the right way. 

 In this connection, note that sending rate is a TIME SCALe phenomenon, in a packet pair technique, the average rate is one parameter, but locally, on
small timescales, the sending rate is at line rate over the packet pairs. In more general streams many different time scales could be inserted.
This brings us to the question of whether sending rate matters, explored (again on the 14th May) by Henk and others. I'm afraid I disagree with Henk,
the sending rate does matter because it is not only the average rate that counts (in fact one of the holy grails of active measurement is to be able
to measure whatever you want even at Very low (average) rate!!)  but the entire sending pattern, and the higher the sending rate, the more structure
can be inserted into the pattern. Having a bottleneck which is not at the access is excellent news for the sender, it means that the higher resolution
details of what is put in will survive for longer, and can therefore probe for longer. Yes the bottleneck will erase this detail, in the inter-arrival
times, but not in the delay series...

Another general point is what to do with the measurements, what metric to choose.  I agree with Steven Van den Berghe (14th again) that the full data
must be condensed, but there is no need to reduce the full richness of
the probe stream, plus the transformation of it that is received at the receiver, by a couple of numbers such as mean and variance. It is clear that
such simple metrics cannot hope to capture too much, and I have been distressed to read over the last 24 months or more the amount of energy going
into discussing exactly how to estimate a variance, with very little discussion of metrics that could be much more important.
Part of the work Attila Pasztor and I are involved in now aims at
developing new metrics based on a measurement of the full distribution of the delay series- not to match it to some classic standard, but
to extract specific, network motivated features from it (in fact our approach is not based on Lai and Baker's work, it is quite different,
although we have similar aims and of course we both wish to exploit
back to back packets).  Speaking quite generally, condensation of information is necessary, and always implies MODelling.  Parameters do not exist in
their own right, but only mean something in the context of a model, even if that model is implicit.  What we need is a route model which is rich
enough to capture important behaviour, and with parameters that correspond to a large data reduction, but without throwing out the baby with the
bathwater.
Many parameters of interest are not related to simple means in any obvious
way, the mean and variance of delay have been chosen more for their familiarity as statistics rather than as parameters of a model. 
Seeing them as model free is a symptom of this problem.  

Finally (nearly finished now), some points have been made regarding clock rate synchronisation and how this could be corrected for. We think it is
possible to do so simply and effectively without resorting to GPS, just
by improving clock software, but nothing is written up at this point. This is a key point for the practical usefulness of (some of) the more
interesting techniques. 

Darryl 

+----------------------------+--------------------------------------------+
|  Darryl Veitch             | Email:   d.veitch@ee.mu.oz.au              |
|  EMUlab                    | Telephone:                                 |
|  Department of Electrical  |        Direct-   +61 3 8344 9196           |
|  & Electronic Engineering, |     Inquiries-   +61 3 8344 9204           | 
|  University of Melbourne   |                                            | 
|                            | Fax:             +61 3 8344 9188           |
|  Victoria 3010             |                                            |
|  Australia                 | Web: http://www.emulab.ee.mu.oz.au/~darryl |
+----------------------------+--------------------------------------------+
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu May 31 10:01:47 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25440
	for ; Thu, 31 May 2001 10:01:46 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4VE05T26201;
	Thu, 31 May 2001 10:00:05 -0400
Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4VDxlx23567
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL)
	for ; Thu, 31 May 2001 09:59:53 -0400
Received: from cain.internet2.edu (localhost [127.0.0.1])
	by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f4VBnYk06699;
	Thu, 31 May 2001 07:49:34 -0400
X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu
Received: by cain.internet2.edu (Postfix, from userid 1000)
	id A77C5619; Wed, 30 May 2001 12:53:40 -0400 (EDT)
To: Darryl Neil Veitch 
Cc: ippm@advanced.org
Subject: [ippm] OWDP inter-packet times (Was: IP Delay variation...)
References:  <3B125C4C.AF0DA58E@ee.mu.oz.au>
From: stanislav shalunov 
Date: 30 May 2001 12:53:40 -0400
In-Reply-To: <3B125C4C.AF0DA58E@ee.mu.oz.au>
Message-ID: <87itiilqwb.fsf_-_@cain.internet2.edu>
Lines: 53
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 

Darryl,

I agree with your comments that Poisson stream of packets isn't
something special (even if it's truely and really Poisson).  It's
simply a way of measuring singleton characteristics (when used with a
sufficiently low rate).  It's also what's defined in current
standards, so there's no real reason not to stick with it for the
purposes of singleton measurements.

I believe that the current form of the draft is adequate for singleton
characteristics measurements; at the same time I agree that if we can
specify more than singleton measurements it's definitely benefitial to
do so.  Measurements of distribution of the arrival times vector for
n-tuples, for example, could prove useful.

We need to communicate the packet send schedule beforehand to be able
to detect losses.  This can be done in a variety of ways; e.g., one
could simply send all the timestamps.  This would increase control
overhead by roughly 50% and comprise roughly up to 20% of total OWDP
traffic (assuming long sessions and results that are retrieved exactly
once; if results are stored at the receiver, it's roughly 50% of total
OWDP traffic).

Can we afford to just choose full generality at the expense of network
resource consumption?  Maybe.  Should we give the opportunity to have
full generality?  Probably (but it goes beyond measuring currently
defined metrics).  Should we try to compress the schedule for "typical
measurement cases"?  Absolutely.

The question essentially is, how to compress the send schedule for
those typical measurement cases.  I don't like the answer "identify
them later and add them slowly one-by-one, thusly creating 50 protocol
variations just so we have something to do in the future".  This
protocol could be put in hard-to-upgrade devices (little measurement
nodes that you could put into the back of your network closet).
Regularly changing it is a Bad Idea.

What Ben Teitelbaum proposes is a repeated fixed-intervals schedule
with intervals between repetitions distributed independently and
exponentially or in some other simple way.  (When the number of
repetitions is 1 you achieve full generality by fully specifying the
schedule in advance.)  So far, in my opinion, it's the best proposal
that goes beyond singleton metrics.  It includes little-overhead
measurements of currently defined metrics as well as many metrics that
are clearly useful.  It also includes full generality as a special
case (without a switch statement).

Are there any better answers?

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed at 600 mph.
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm


From ippm-admin@advanced.org  Thu May 31 21:32:03 2001
Received: from mailhost.advanced.org (root@[209.211.239.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11417
	for ; Thu, 31 May 2001 21:32:03 -0400 (EDT)
Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f511T3J27707;
	Thu, 31 May 2001 21:29:03 -0400
Received: from emulab.ee.mu.oz.au (potoroo.ee.mu.OZ.AU [128.250.76.186])
	by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f511SFJ26341
	for ; Thu, 31 May 2001 21:28:16 -0400
X-Authentication-Warning: mailhost.advanced.org: Host potoroo.ee.mu.OZ.AU [128.250.76.186] claimed to be emulab.ee.mu.oz.au
Received: from ee.mu.oz.au (IDENT:attila@wallaby.emulab.ee.mu.oz.au [10.0.0.8])
	by emulab.ee.mu.oz.au (8.9.3/8.9.3) with ESMTP id LAA11553;
	Fri, 1 Jun 2001 11:28:06 +1000 (EST)
	(envelope-from a.pasztor@ee.mu.oz.au)
Message-ID: <3B16EF7E.572EA375@ee.mu.oz.au>
Date: Fri, 01 Jun 2001 11:27:26 +1000
From: Attila Pasztor 
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: stanislav shalunov 
CC: Darryl Neil Veitch , ippm@advanced.org
Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...)
References:  <3B125C4C.AF0DA58E@ee.mu.oz.au> <87itiilqwb.fsf_-_@cain.internet2.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: ippm-admin@advanced.org
Errors-To: ippm-admin@advanced.org
X-BeenThere: ippm@advanced.org
X-Mailman-Version: 2.0beta5
Precedence: bulk
List-Id: IETF IP Performance Metrics Working Group List 
Content-Transfer-Encoding: 7bit

Hi Stanislav,

Please excuse me if my question is not appropriate. In your mail to
Darryl you make the following statement:

> We need to communicate the packet send schedule beforehand to be able
> to detect losses.

Why? I am sorry, but I don't get it.

I believe that the loss detection should be based on packet serial
numbers. If it is a problem to detect when a measurement starts or when
it has ended, it can be communicated with simple control messages between
the sender and the receiver.

1. Sender sends a "Measurement starts" message
2. Receiver sends back an acknowledgement

3. If the ack is received Sender starts to send the measurement packets;
if the ack is not received within a finite time, then it resends message
#1
4. Sender continues to send packets according to his preferred timing
schedule

5. Sender sends an "End of measurement" message, including the serial
number of the last packet sent
6. Receiver sends back an acknowledgement
7. If the sender does not receive an ack within a finite time the sender
resends message #5

(Note: limit the number of resending the messages, if no ack is received
after n trials, then the measurement has failed)

8. If there are any packets missing, after a certain time receiver
assumes they are lost

I think that the process described above detects the losses reliably
(except packet delays exceeding the time outs).
Including serial numbers in the packets is needed anyway, I don't think
that losses could be detected reliably only based on the sending
schedule.

Please, explain to me, why do we need to communicate the packet send
schedule beforehand to be able to detect losses?

By the way, in RFC 2680 'A One-way Packet Loss Metric for IPPM' there is
no mentioning of communicating the send schedule.

Thanks,
Attila





_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm