From tqtf-admin@advanced.org Sat Dec 1 06:52:22 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12443 for ; Sat, 1 Dec 2001 06:52:21 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB1BqMB18493 for ; Sat, 1 Dec 2001 06:52:22 -0500 Date: Sat, 1 Dec 2001 06:52:22 -0500 Message-Id: <200112011152.fB1BqMB18493@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: tqtf-admin@advanced.org Errors-To: tqtf-admin@advanced.org X-BeenThere: tqtf@thinkquest.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 Mon Dec 3 10:51:18 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07531 for ; Mon, 3 Dec 2001 10:51:18 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3Fo4B24925; Mon, 3 Dec 2001 10:50:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3DbVB31101 for ; Mon, 3 Dec 2001 08:37:32 -0500 X-Authentication-Warning: mailhost.advanced.org: Host odin.ietf.org [132.151.1.176] claimed to be ietf.org Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28985; Mon, 3 Dec 2001 08:37:24 -0500 (EST) Message-Id: <200112031337.IAA28985@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 03 Dec 2001 08:37:23 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-owdp-reqs-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-way Active Measurement Protocol Requirements Author(s) : S. Shalunov, B. Teitelbaum Filename : draft-ietf-ippm-owdp-reqs-01.txt Pages : 9 Date : 30-Nov-01 With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-reqs-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-owdp-reqs-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-ietf-ippm-owdp-reqs-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011130160652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-owdp-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-owdp-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011130160652.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Dec 3 16:18:01 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01562 for ; Mon, 3 Dec 2001 16:18:01 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3LG2B07908; Mon, 3 Dec 2001 16:16:02 -0500 Received: from mave.nlanr.net (mave.nlanr.net [198.202.74.38]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3LFeB07878 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 3 Dec 2001 16:15:41 -0500 Received: from localhost (mjl@localhost) by mave.nlanr.net (8.11.1/8.11.1) with ESMTP id fB3LFdd21919 for ; Mon, 3 Dec 2001 13:15:39 -0800 (PST) (envelope-from mjl@nlanr.net) X-Authentication-Warning: mave.nlanr.net: mjl owned process doing -bs Date: Mon, 3 Dec 2001 13:15:39 -0800 (PST) From: Matthew Luckie To: ippm@advanced.org Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-owdp-reqs-01.txt In-Reply-To: <200112031337.IAA28985@ietf.org> 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 > + Allow UDP as the transport protocol, since the protocol needs to > be able to measure individual packet delivery times and has to run > on various machines. is this requirement really necessary? Matthew Luckie mjl@nlanr.net _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Dec 3 16:41:46 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03761 for ; Mon, 3 Dec 2001 16:41:46 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3Lf2B14840; Mon, 3 Dec 2001 16:41:02 -0500 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 fB3LeSB14806 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Mon, 3 Dec 2001 16:40:32 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3LeR512182 for ; Mon, 3 Dec 2001 16:40:28 -0500 To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp-reqs-01.txt References: From: stanislav shalunov Date: 03 Dec 2001 16:40:26 -0500 In-Reply-To: Message-ID: <87pu5wq8xh.fsf@cain.internet2.edu> Lines: 26 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 Matthew Luckie writes: > > + Allow UDP as the transport protocol, since the protocol needs to > > be able to measure individual packet delivery times and has to run > > on various machines. > > is this requirement really necessary? Please elaborate. I don't understand this one-liner. Do you mean we should use general packet templates, TCP packets, separate IP protocol packets as IPMP does, or something else? Separate protocol number, in my opinion, won't do it. It contradicts requirement of section 6.2 (and you can't do it efficiently in userspace). Being able to do TCP would be nice; this is not excluded by the requirement. Not that we know how to do TCP without ripping out TCP stack from the kernel and replacing it with something instrumented even more heavily than, say, Web100, really. (For the inbound traffic, there's the timestamps option, too.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at sea level. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Dec 3 17:25:40 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06986 for ; Mon, 3 Dec 2001 17:25:40 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3MP3B23645; Mon, 3 Dec 2001 17:25:03 -0500 Received: from mave.nlanr.net (mave.nlanr.net [198.202.74.38]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3MOKB23606 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 3 Dec 2001 17:24:22 -0500 Received: from localhost (mjl@localhost) by mave.nlanr.net (8.11.1/8.11.1) with ESMTP id fB3MOIh22190; Mon, 3 Dec 2001 14:24:18 -0800 (PST) (envelope-from mjl@nlanr.net) X-Authentication-Warning: mave.nlanr.net: mjl owned process doing -bs Date: Mon, 3 Dec 2001 14:24:18 -0800 (PST) From: Matthew Luckie To: stanislav shalunov cc: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp-reqs-01.txt In-Reply-To: <87pu5wq8xh.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 > > > + Allow UDP as the transport protocol, since the protocol needs to > > > be able to measure individual packet delivery times and has to run > > > on various machines. > > > > is this requirement really necessary? > > Please elaborate. I don't understand this one-liner. Do you mean we > should use general packet templates, TCP packets, separate IP protocol > packets as IPMP does, or something else? I'm just wondering if allowing UDP as the transport protocol is a necessary requirement. As you point out, there are multiple protocol types that can be used in conducting one-way active measurements (the OWAMP-Test). > Separate protocol number, in my opinion, won't do it. It contradicts > requirement of section 6.2 (and you can't do it efficiently in > userspace). but i'm not suggesting that (1). > Being able to do TCP would be nice; this is not excluded by the > requirement. It's not excluded by the requirements specification, but my reading of the specification is that you should have a UDP implementation of the OWAMP-Test protocol too. Section 4.6 spends some time discussing the use of other protocol types. More-over, I'm wondering if the requirements specification is designed specifically for the OWAMP protocol draft or whether I should be able to apply the requirements draft to other one-way active measurement protocols as well. ---- (1) you can do `it' efficiently in kernel space though, and section 6.3 of rfc2330 touches briefly on this. if you really wanted to do it efficiently in user-space (modifications to raw sockets or something like that) you could. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Dec 3 17:43:43 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08488 for ; Mon, 3 Dec 2001 17:43:43 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3Mh3B28281; Mon, 3 Dec 2001 17:43:03 -0500 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 fB3MgSB28167 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Mon, 3 Dec 2001 17:42:32 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB3MgS529164 for ; Mon, 3 Dec 2001 17:42:28 -0500 To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp-reqs-01.txt References: From: stanislav shalunov Date: 03 Dec 2001 17:42:26 -0500 In-Reply-To: Message-ID: <87r8qcorhp.fsf@cain.internet2.edu> Lines: 34 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 Matthew Luckie writes: > As you point out, there are multiple protocol types that can be used in > conducting one-way active measurements (the OWAMP-Test). But we need to have a lowest common denominator that works on maximum number of machines, across domain boundaries, etc. UDP's not ideal. But it'll give us ability to conduct some measurements. We should make their domain of applicability as large as possible. > It's not excluded by the requirements specification, but my reading of the > specification is that you should have a UDP implementation of the > OWAMP-Test protocol too. Yes. > Section 4.6 spends some time discussing the use of other protocol > types. Yes, or rather difficulties we'd need to overcome to do more than UDP, essentially. > More-over, I'm wondering if the requirements specification is > designed specifically for the OWAMP protocol draft or whether I > should be able to apply the requirements draft to other one-way > active measurement protocols as well. draft-ietf-ippm-owdp-reqs-01.txt covers OWAMP requirements only. It should not be read as constraining your work on IPMP in any way. -- 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 Tue Dec 4 03:28:01 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21520 for ; Tue, 4 Dec 2001 03:28:01 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB48R2B05044; Tue, 4 Dec 2001 03:27:02 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB48Q7B04938 for ; Tue, 4 Dec 2001 03:26:07 -0500 Received: from penguin.ripe.net (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fB48Q6G24886 for ; Tue, 4 Dec 2001 09:26:06 +0100 Received: from localhost (henk@localhost) by penguin.ripe.net (8.11.6/8.11.6) with ESMTP id fB48Q6R06500 for ; Tue, 4 Dec 2001 09:26:06 +0100 X-Authentication-Warning: penguin.ripe.net: henk owned process doing -bs Date: Tue, 4 Dec 2001 09:26:06 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Subject: Re: [ippm] IPMP : IP Measurement Protocol In-Reply-To: <87adxmvw6j.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 (Catching up on email after being offline for 2 weeks). On 16 Nov 2001, stanislav shalunov wrote: > Matthew Luckie writes: > > > [Henk writes:] > >> The most important feature of this protocol is the possibility to > >> (optionally) include information from intermediate routers, in the > >> measurement packet. I think the OWDP we're working on would > >> benefit from this feature. > > > > To give those that haven't read the IPMP specification an idea on > > how this feature is achieved, we make IPMP echo packets as obvious > > as we can. > > It's important to keep in mind that there's a trade-off between being > able to get information from intermediate routers and being able to > test these routers. In essense, IPMP implies fully co-operating > routers while OWAMP expects that some routers will be configured to > cheat and try to make measurement results appear better than they > would be for ``real'' traffic. To achieve that goal, OWAMP packets > are made hard to identify (while IPMP packets are easy to identify by > design with even a separate IP protocol number). I agree with this. What I would like to see is some sort of "switch" that allows you to use IPMP or OWAMP, use the former if everybody agrees with the measurement and the latter if there is benefit in hiding the packets. This is probably best done in the control plane. 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 Tue Dec 4 03:29:42 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21553 for ; Tue, 4 Dec 2001 03:29:42 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB48T2B05334; Tue, 4 Dec 2001 03:29:02 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB48SNB05304 for ; Tue, 4 Dec 2001 03:28:23 -0500 Received: from penguin.ripe.net (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fB48RpG25056; Tue, 4 Dec 2001 09:27:51 +0100 Received: from localhost (henk@localhost) by penguin.ripe.net (8.11.6/8.11.6) with ESMTP id fB48RoN06520; Tue, 4 Dec 2001 09:27:51 +0100 X-Authentication-Warning: penguin.ripe.net: henk owned process doing -bs Date: Tue, 4 Dec 2001 09:27:50 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN cc: , Subject: RE: [ippm] I-D on requirement for a management plane of the IPPM metrics 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, 19 Nov 2001, STEPHAN Emile FTRD/DAC/LAN wrote: > Hi Henk, > > Henk writes: > > This section (4.2, 4.3) seem to be copied directly from RFC2330 and > > consist mainly of pointers to 2330. > > The requirements focus ONLY and ONLY ON the IPPM WG documents. So whenever > it is possible the section names, the keywords are those of the IPPM WG > documents. Yes, but why don't you put in a 1 line reference to 2330 then, instead of repeating various sections? 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 Tue Dec 4 04:03:15 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22056 for ; Tue, 4 Dec 2001 04:03:15 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB4913B07752; Tue, 4 Dec 2001 04:01:03 -0500 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 fB4908B07733 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Tue, 4 Dec 2001 04:00:13 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB4908526374 for ; Tue, 4 Dec 2001 04:00:08 -0500 To: ippm@advanced.org Subject: Re: [ippm] IPMP : IP Measurement Protocol References: From: stanislav shalunov Date: 04 Dec 2001 04:00:07 -0500 In-Reply-To: Message-ID: <87y9kjicmg.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 "Henk Uijterwaal (RIPE-NCC)" writes: > What I would like to see is some sort of "switch" that allows you to > use IPMP or OWAMP, use the former if everybody agrees with the > measurement and the latter if there is benefit in hiding the > packets. This is probably best done in the control plane. I guess that's not unreasonable (but we do need to avoid featuritis in general). This brings up the next question: Is IPMP really the right way to do that or would, perhaps, well-known port numbers have some advantages? You're not going to run OWAMP-Control in kernel space. The co-ordination between kernel and user land on the measurement stations could quickly become a hassle with OWAMP-Control/IPMP: the amount of state to hold is potentially large. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "The power of accurate observation is commonly called cynicism by those who have not got it." -- G. B. Shaw _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Dec 4 04:08:56 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22109 for ; Tue, 4 Dec 2001 04:08:56 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB4973B08492; Tue, 4 Dec 2001 04:07:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB496CB08469 for ; Tue, 4 Dec 2001 04:06:12 -0500 Received: from penguin.ripe.net (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fB495eG00847; Tue, 4 Dec 2001 10:05:40 +0100 Received: from localhost (henk@localhost) by penguin.ripe.net (8.11.6/8.11.6) with ESMTP id fB495eQ11090; Tue, 4 Dec 2001 10:05:40 +0100 X-Authentication-Warning: penguin.ripe.net: henk owned process doing -bs Date: Tue, 4 Dec 2001 10:05:40 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN cc: stanislav shalunov , , In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] RE:IPPM management plane requirements I-D 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, 19 Nov 2001, STEPHAN Emile FTRD/DAC/LAN wrote: > Hi stanislav, henk > > The purpose of the draft-stephan-ippm-mgmt-reqs-00.txt need to be clarify. > It is intended to fix the needs for a management interface: > + independant; > + The in/out of a measurement; > + Cover all the IPPM metrics; > + Scalability; > ... Please explain to me what a "management interface" is then. I thought we had 2 layers: OWAM-control and OWAMP-test, where the former controls the measurements and the latter does the measurement and this seems to cover everything (at least to me). Related: reading all the mails in the various threads on this, i think we are going nowhere and could really benefit from a discussion by voice next week. Henk > > > -1- management plane/control protocol: > > stanislav [shalunov@internet2.edu] writes : > > If there are problems with the requirements document in the > > area of conducting measurements between different domains, we need to > > hear about those. They would need to be fixed > > The draft-stephan-ippm-mgmt-reqs-00.txt does not add requirements for > control protocols. It list the requirements for the management plane. Its > purpose is not to define how will be controled the measurement, but to > standardize the parameters (in/out) of the IPPM metrics measurements which > are accessible from the management plane. On another hand there are issues > in the draft-stephan-ippm-mgmt-reqs-00.txt that may be considerered in the > "One-way Delay Protocol Requirements". As an example, the specification of > the Type P is an main point because the control protocol must carry any > protocols suites description. > > -2- Control protocols purposes: > > stanislav [shalunov@internet2.edu] writes > > Conceptually, I like IPMP a lot. With regard to its relationship to > > OWAMP, I can see the following possible strategies for us: > > > > * provide all functionality that IPMP provides in OWAMP without > > necessarily using IPMP directly; > > > > * provide all functionality that OWAMP is going to provide in IPMP and > > forget about OWAMP; > > > >* ``merge'' IPMP and OWAMP in some fashion; > > > >* leave them separate recognizing that they solve different problems. > > > >Presently, I tend to favor the last. Opinions of IPMP designers and > >WG participants in general are solicited. > > It appears that the scope of the existing control protocols are differents. > So the second goal of the draft-stephan-ippm-mgmt-reqs-00.txt is to specify > the needs for an common management interface to access to the control > protocols. > > > -3- Only the IPPM metrics, all the IPPM metrics: > > The section "Functional Requirements" of "One-way Delay Protocol > Requirements" says that "Non-singleton characteristics (such as those > related to trains of packets, back-to-back tuples, and so forth) and > application traffic simulation aren't areas that the protocol(s) need to > address". So another requirements of the management plane is to provide an > interface for all the IPPM metrics either they need or NOT a control > protocol to be performed. > > -4- Scalability: > > NMS can not afford to keep hundred of control protocol TCP connexions open > during the measurement tests. It is not acceptable that the management plane > has to maintain sessions (restart broken TCP session...). Relations between > NMS and the control protocols needs to be soft state. > > > Regards > Emile > > > > ------------------------------------------------------------------------------ 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 Tue Dec 4 05:05:16 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22713 for ; Tue, 4 Dec 2001 05:05:16 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB4A43B14459; Tue, 4 Dec 2001 05:04:03 -0500 Received: from mave.nlanr.net (mave.nlanr.net [198.202.74.38]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB4A3gB14446 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 4 Dec 2001 05:03:43 -0500 Received: from localhost (mjl@localhost) by mave.nlanr.net (8.11.1/8.11.1) with ESMTP id fB4A3eI24203; Tue, 4 Dec 2001 02:03:40 -0800 (PST) (envelope-from mjl@nlanr.net) X-Authentication-Warning: mave.nlanr.net: mjl owned process doing -bs Date: Tue, 4 Dec 2001 02:03:40 -0800 (PST) From: Matthew Luckie To: stanislav shalunov cc: ippm@advanced.org Subject: Re: [ippm] IPMP : IP Measurement Protocol In-Reply-To: <87y9kjicmg.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 > You're not going to run OWAMP-Control in kernel space. The > co-ordination between kernel and user land on the measurement stations > could quickly become a hassle with OWAMP-Control/IPMP: the amount of > state to hold is potentially large. There is no issue of co-ordination to consider that I can think of. The kernel stamps the packets and passes them to userland applications. I have plans to do an implementation of OWAMP-Control/IPMP as part of my research in the near future. Matthew Luckie mjl@nlanr.net _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Dec 4 12:34:30 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03047 for ; Tue, 4 Dec 2001 12:34:30 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB4HW2B01916; Tue, 4 Dec 2001 12:32:02 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id fB4HVwB01719; Tue, 4 Dec 2001 12:31:58 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Cc: , "Matt Zekauskas" , "Merike Kaeo" , "Allison Mankin" Date: Tue, 4 Dec 2001 12:34:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Current agenda for IPPM at IETF 52 - Salt Lake City 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 [note: this assumes we have the 1st half of the 2hr slot holding both IPPM and MEGACO. If my assumption is wrong, we'll let you know ASAP.] -=-=-=- IP Performance Metrics WG (ippm) Wednesday, December 12 at 13:00 - 14:00 ==================================== CHAIRS: Merike Kaeo Matt Zekauskas AGENDA: 1. Agenda bashing (<= 5 min) 2. Summarizing latest radical revision of npmps draft as per the I-D (10 min) -- Al Morton acmorton@att.com http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-05.txt The formatting of the submitted version is "not nice"; a version with "more standard" formatting, and believed to be otherwise identical, is available from http://www.advanced.org/IPPM/docs/draft-ietf-ippm-npmps-05p.txt 3. Practical experience with the IPDV draft (15 min) -- Henk Uijterwaal This item will discuss issues relating to the draft arising from an implementation. It particularly relates to the previous (technically now-expired) version of the draft, which is available from http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-07.txt and http://www.advanced.org/IPPM/docs/draft-ietf-ippm-ipdv-07.txt In addtion, note that a newer version was submitted, but unfortunately not in time before the cutoff. That version will appear soon after this meeting. It was sent to the mailing list, and also appears at http://www.advanced.org/IPPM/docs/draft-ietf-ippm-ipdv-08.txt 4. One-way Active Measurements Protocol Requirements (15 min) -- Stanislav Shalunov http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-reqs-01.txt see also http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-03.txt 5. IPPM metric management needs (10 min) -- Emile STEPHAN In particular, we'd like to address issues raised by this draft and it's relationship to the protocol requirements draft above. http://www.ietf.org/internet-drafts/draft-stephan-ippm-mgmt-reqs-00.txt see also http://www.ietf.org/internet-drafts/draft-stephan-ippm-mib-00.txt NOTE: there is also going to be a discussion of IPPM MIB-related issues in the RMONMIB WG on Monday evening, see http://www.ietf.org/ietf/01dec/rmonmib.txt We encourage interested parties to attend that session. 6. Discussion on charter/milestones/potential new work (5 min). -- Matt & Merike _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Dec 4 16:28:44 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13131 for ; Tue, 4 Dec 2001 16:28:44 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB4LQ5B07257; Tue, 4 Dec 2001 16:26:05 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB4LPYB05246; Tue, 4 Dec 2001 16:25:35 -0500 Received: from penguin.ripe.net (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fB4LPOG20889; Tue, 4 Dec 2001 22:25:24 +0100 Received: from localhost (henk@localhost) by penguin.ripe.net (8.11.6/8.11.6) with ESMTP id fB4LPOm20770; Tue, 4 Dec 2001 22:25:24 +0100 X-Authentication-Warning: penguin.ripe.net: henk owned process doing -bs Date: Tue, 4 Dec 2001 22:25:24 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Matthew J Zekauskas cc: , , , Merike Kaeo , Allison Mankin Subject: Re: [ippm] Current agenda for IPPM at IETF 52 - Salt Lake City 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 Matt, others, > IP Performance Metrics WG (ippm) > Wednesday, December 12 at 13:00 - 14:00 1 hour for this meeting looks extremely short to me. In particular #5 needs a lot of discussion (like what are these drafts trying to accomplish, why are they needed, relation between the various blocks, etc), followed by a discussion which WG is going to do what. I much rather see an hour or two scheduled for this, and cut the meeting short if we run out of material, than the current 30 minutes on Monday, 10 on Wednesday which (probably) ends up in another endless discussion going nowhere on the list. Henk > ==================================== > CHAIRS: Merike Kaeo > Matt Zekauskas > > AGENDA: > > 1. Agenda bashing (<= 5 min) > > 2. Summarizing latest radical revision of npmps draft as per the I-D (10 min) > -- Al Morton acmorton@att.com > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-05.txt > > The formatting of the submitted version is "not nice"; a version > with "more standard" formatting, and believed to be otherwise identical, > is available from > http://www.advanced.org/IPPM/docs/draft-ietf-ippm-npmps-05p.txt > > > 3. Practical experience with the IPDV draft (15 min) > -- Henk Uijterwaal > > This item will discuss issues relating to the draft arising from > an implementation. It particularly relates to the previous (technically > now-expired) version of the draft, which is available from > http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-07.txt > and > http://www.advanced.org/IPPM/docs/draft-ietf-ippm-ipdv-07.txt > > In addtion, note that a newer version was submitted, but unfortunately > not in time before the cutoff. That version will appear soon after > this meeting. It was sent to the mailing list, and also appears at > http://www.advanced.org/IPPM/docs/draft-ietf-ippm-ipdv-08.txt > > 4. One-way Active Measurements Protocol Requirements (15 min) > -- Stanislav Shalunov > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-reqs-01.txt > see also > http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-03.txt > > 5. IPPM metric management needs (10 min) > -- Emile STEPHAN > > In particular, we'd like to address issues raised by this draft and > it's relationship to the protocol requirements draft above. > http://www.ietf.org/internet-drafts/draft-stephan-ippm-mgmt-reqs-00.txt > see also > http://www.ietf.org/internet-drafts/draft-stephan-ippm-mib-00.txt > > NOTE: there is also going to be a discussion of IPPM MIB-related issues > in the RMONMIB WG on Monday evening, see > http://www.ietf.org/ietf/01dec/rmonmib.txt > We encourage interested parties to attend that session. > > 6. Discussion on charter/milestones/potential new work (5 min). > -- Matt & Merike > > _______________________________________________ > 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 Wed Dec 5 04:12:32 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17116 for ; Wed, 5 Dec 2001 04:12:31 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5993T01637; Wed, 5 Dec 2001 04:09:03 -0500 Received: from bigglesworth.mail.be.easynet.net (bigglesworth.mail.be.easynet.net [212.100.160.67]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB598qT01539; Wed, 5 Dec 2001 04:08:53 -0500 Received: from 212-100-179-122.adsl.easynet.be ([212.100.179.122]) by bigglesworth.mail.be.easynet.net with esmtp (Exim 3.16 #1) id 16BY2s-0007gg-00; Wed, 05 Dec 2001 10:08:50 +0100 Subject: Re: [ippm] Current agenda for IPPM at IETF 52 - Salt Lake City From: Steven Van den Berghe To: Henk "Uijterwaal (RIPE-NCC)" Cc: ippm@advanced.org, Merike Kaeo , Matthew J Zekauskas In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 05 Dec 2001 10:09:26 +0100 Message-Id: <1007543366.3151.0.camel@localhost.localdomain> Mime-Version: 1.0 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi all, Just my 2 (euro)cents.... one of the jobs of ippm is (as the charter expresses it) promoting the application of the metrics. Now, these metrics have been popping up in a variety of places (e.g. rmon, tewg) and i can assure you that there are other applications on their way. These applications have different requirements than the "new inter administrative domain ping" the current triplet owdp-test, owdp-control, owdp-mgmt is mainly aiming at. The only thing which is, still to my humble opinion, a necessity is the owdp-test (especially if equipment vendors would put this in their boxes). owdp-control, owdp-mgmt are just one way of using it, and might be replaced by other ways of control (which is forseen in the reqm draft). Conclusion: neither owdp-control/owdp-mgmt are strictly required for being able to get interoperability between boxes. As with other management functionalities like CLI, SNMP, COPS or psychic control, might be be put in place. Given this, there are multiple approaches possible for ippm: 1. we don't care, let the different approaches be spread over their appropriate working groups (with sending a single fyi message to the ippm mailinglist) 2. we care but nothing more: we let ippm be a forum where these approaches can be 'published' as a bcp and make sure they don't conflict with the metrics requirements 3. we foster them i don't have a strong opinion on which option to choose, but it should be decided asap, before the current mix between 1 and 3 gets out of hand (and to reduce the number of endless discussions on it). Cheers (and have a succesful 1h10m in SLC), Steven On Tue, 2001-12-04 at 22:25, Henk Uijterwaal (RIPE-NCC) wrote: > Matt, others, > > > IP Performance Metrics WG (ippm) > > Wednesday, December 12 at 13:00 - 14:00 > > 1 hour for this meeting looks extremely short to me. In particular #5 > needs a lot of discussion (like what are these drafts trying to > accomplish, why are they needed, relation between the various blocks, > etc), followed by a discussion which WG is going to do what. > > I much rather see an hour or two scheduled for this, and cut the meeting > short if we run out of material, than the current 30 minutes on Monday, 10 > on Wednesday which (probably) ends up in another endless discussion going > nowhere on the list. > > Henk > > > > > > > > > ==================================== > > CHAIRS: Merike Kaeo > > Matt Zekauskas > > > > AGENDA: > > > > 1. Agenda bashing (<= 5 min) > > > > 2. Summarizing latest radical revision of npmps draft as per the I-D (10 min) > > -- Al Morton acmorton@att.com > > > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-05.txt > > > > The formatting of the submitted version is "not nice"; a version > > with "more standard" formatting, and believed to be otherwise identical, > > is available from > > http://www.advanced.org/IPPM/docs/draft-ietf-ippm-npmps-05p.txt > > > > > > 3. Practical experience with the IPDV draft (15 min) > > -- Henk Uijterwaal > > > > This item will discuss issues relating to the draft arising from > > an implementation. It particularly relates to the previous (technically > > now-expired) version of the draft, which is available from > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-07.txt > > and > > http://www.advanced.org/IPPM/docs/draft-ietf-ippm-ipdv-07.txt > > > > In addtion, note that a newer version was submitted, but unfortunately > > not in time before the cutoff. That version will appear soon after > > this meeting. It was sent to the mailing list, and also appears at > > http://www.advanced.org/IPPM/docs/draft-ietf-ippm-ipdv-08.txt > > > > 4. One-way Active Measurements Protocol Requirements (15 min) > > -- Stanislav Shalunov > > > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-reqs-01.txt > > see also > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-03.txt > > > > 5. IPPM metric management needs (10 min) > > -- Emile STEPHAN > > > > In particular, we'd like to address issues raised by this draft and > > it's relationship to the protocol requirements draft above. > > http://www.ietf.org/internet-drafts/draft-stephan-ippm-mgmt-reqs-00.txt > > see also > > http://www.ietf.org/internet-drafts/draft-stephan-ippm-mib-00.txt > > > > NOTE: there is also going to be a discussion of IPPM MIB-related issues > > in the RMONMIB WG on Monday evening, see > > http://www.ietf.org/ietf/01dec/rmonmib.txt > > We encourage interested parties to attend that session. > > > > 6. Discussion on charter/milestones/potential new work (5 min). > > -- Matt & Merike > > > > _______________________________________________ > > 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 > > -- -- Steven Van den Berghe steven.vandenberghe@intec.rug.ac.be Workgroup Broadband Communication Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* A computer is like an Old Testament god, with a lot of rules and no mercy. - Joseph Campbell *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Dec 5 04:39:46 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17300 for ; Wed, 5 Dec 2001 04:39:46 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB59d2T03765; Wed, 5 Dec 2001 04:39:02 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB59cZT03655; Wed, 5 Dec 2001 04:38:36 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fB59cZG29287; Wed, 5 Dec 2001 10:38:35 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.11.6/8.11.6) with ESMTP id fB59cZu19028; Wed, 5 Dec 2001 10:38:35 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 5 Dec 2001 10:38:35 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Steven Van den Berghe cc: , Merike Kaeo , Matthew J Zekauskas Subject: Re: [ippm] Current agenda for IPPM at IETF 52 - Salt Lake City In-Reply-To: <1007543366.3151.0.camel@localhost.localdomain> 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 Steven, > one of the jobs of ippm is (as the charter expresses it) promoting the > application of the metrics. Now, these metrics have been popping up in a > variety of places (e.g. rmon, tewg) and i can assure you that there are > other applications on their way. Great (hey, I'm implementing these metrics). > > These applications have different requirements than the "new inter > administrative domain ping" the current triplet owdp-test, owdp-control, > owdp-mgmt is mainly aiming at. This is what I think we should try to accomplish. At an abstract level, we need: 1. Metrics and measurement devices that implement them, 2. Protocol(s) that allows measurements between different implementations, 3. A control mechanism that allows a user from any other area to do a measurement 4. A reporting protocol that returns the result to the user. So-far, IPPM has been doing (1) and we started on (2) and (3) a year or so ago. (4) is still open. At the moment, other groups (RMON, TE, ...) started to work on (3) and (4), which clearly overlaps with the work in IPPM. I think we should try to coordinate these efforts and keep the number of control and report mechanisms to preferably 1 or at least a small number. This basically why I think we need to have a longer discussion with RMON (etc) to see what they need, which building blocks are needed and which group is going to define what, before things start to diverge. If we don't do this now, then we might as well forget about (2) and have various implementations tuned towards specific users of the metrics (with all disadvantages of that approach). Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Dec 5 04:56:23 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17604 for ; Wed, 5 Dec 2001 04:56:23 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB59s3T05656; Wed, 5 Dec 2001 04:54:03 -0500 Received: from mainserver.surfnetusa.com (mail.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB59rpT05558; Wed, 5 Dec 2001 04:53:51 -0500 X-Authentication-Warning: mailhost.advanced.org: Host mail.surfnetusa.com [208.201.152.2] claimed to be mainserver.surfnetusa.com Received: from [63.67.14.34] by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id fhctsbaa for ippm@advanced.org; Wed, 5 Dec 2001 01:59:35 -0800 Message-Id: <5.1.0.14.2.20011205014505.03b6c170@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Dec 2001 01:50:00 -0800 To: "Henk Uijterwaal (RIPE-NCC)" , Steven Van den Berghe From: Merike Kaeo Subject: Re: [ippm] Current agenda for IPPM at IETF 52 - Salt Lake City Cc: , Matthew J Zekauskas In-Reply-To: References: <1007543366.3151.0.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List > >This is what I think we should try to accomplish. At an abstract level, >we need: > > 1. Metrics and measurement devices that implement them, > 2. Protocol(s) that allows measurements between different > implementations, > 3. A control mechanism that allows a user from any other area to do a > measurement > 4. A reporting protocol that returns the result to the user. > >So-far, IPPM has been doing (1) and we started on (2) and (3) a year or so >ago. (4) is still open. At the moment, other groups (RMON, TE, ...) >started to work on (3) and (4), which clearly overlaps with the work in >IPPM. I've been following TEWG and Matt has been following RMON.....who else that you know of is working on (3) and (4)? Agreed that coordination is required on all fronts - hope to come to some consensus in SLC albeit the time limitation. - merike _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Dec 5 08:51:09 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20722 for ; Wed, 5 Dec 2001 08:51:09 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5Do4w31925; Wed, 5 Dec 2001 08:50:04 -0500 Received: from mail-server.comgates.co.il ([212.150.198.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5Dnrw31894 for ; Wed, 5 Dec 2001 08:49:54 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [212.150.198.2] claimed to be mail-server.comgates.co.il Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 15:50:46 +0200 Message-ID: <6FEF757325DBD411B7DA000629A8A61E76E913@mail-server.comgates.co.il> From: Haim Zlotokrilov To: "'ippm@advanced.org'" Date: Wed, 5 Dec 2001 15:50:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17D93.D5880410" Subject: [ippm] 'bursty loss' metrics 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17D93.D5880410 Content-Type: text/plain; charset="iso-8859-1" Hi I'm doing a research about IP QoS for VoIP application, especially regarding the influence of bursty vs. random packet loss and its effect on perceived quality. Therefore I'm interested in definitions of 'loss burstiness'. Are there any ideas other than those mentioned in "One-way Loss Pattern Sample Metrics"? The 'm out of n' metrics was mentioned, but not in details. Can anyone explain more about this metrics? Best Regards Zlatokrilov Haim ------_=_NextPart_001_01C17D93.D5880410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 'bursty loss' metrics

Hi
I'm doing a research about IP QoS for VoIP = application, especially regarding the influence of bursty vs. random = packet  loss and its effect on perceived quality.

Therefore I'm interested in definitions of 'loss = burstiness'. Are there any ideas other than those mentioned in = "One-way Loss Pattern Sample Metrics"?

The 'm out of n' metrics was mentioned, but not in = details. Can anyone explain more about this metrics?

Best Regards
Zlatokrilov Haim

------_=_NextPart_001_01C17D93.D5880410-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Dec 5 09:25:58 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21523 for ; Wed, 5 Dec 2001 09:25:57 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5EP4w05249; Wed, 5 Dec 2001 09:25:04 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5EOQw05202 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 5 Dec 2001 09:24:28 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB5EPAA20321 for ; Wed, 5 Dec 2001 16:25:10 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Dec 2001 16:24:25 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 5 Dec 2001 16:24:25 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F911757520C5D@esebe004.NOE.Nokia.com> From: vilho.raisanen@nokia.com To: hzlatokrilov@COMGATES.co.il, ippm@advanced.org Cc: vilho.raisanen@nokia.com Subject: RE: [ippm] 'bursty loss' metrics Date: Wed, 5 Dec 2001 16:24:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17D98.86E92794" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17D98.86E92794 Content-Type: text/plain; charset="iso-8859-1" Hello, you could also take a look at ETSI EP TIPHON document TS 101 329-5 at http://www.etsi.org/tiphon . Effect of burstiness and means of measuring that have been addressed there. Vilho -----Original Message----- From: ext Haim Zlotokrilov [mailto:hzlatokrilov@COMGATES.co.il] Sent: 05 December 2001 15:51 To: 'ippm@advanced.org' Subject: [ippm] 'bursty loss' metrics Hi I'm doing a research about IP QoS for VoIP application, especially regarding the influence of bursty vs. random packet loss and its effect on perceived quality. Therefore I'm interested in definitions of 'loss burstiness'. Are there any ideas other than those mentioned in "One-way Loss Pattern Sample Metrics"? The 'm out of n' metrics was mentioned, but not in details. Can anyone explain more about this metrics? Best Regards Zlatokrilov Haim ------_=_NextPart_001_01C17D98.86E92794 Content-Type: text/html; charset="iso-8859-1" 'bursty loss' metrics
Hello,
 
you could also take a look at ETSI EP TIPHON document TS 101 329-5 at http://www.etsi.org/tiphon. Effect of burstiness and means of measuring that have been addressed there.
 
    Vilho
-----Original Message-----
From: ext Haim Zlotokrilov [mailto:hzlatokrilov@COMGATES.co.il]
Sent: 05 December 2001 15:51
To: 'ippm@advanced.org'
Subject: [ippm] 'bursty loss' metrics

Hi
I'm doing a research about IP QoS for VoIP application, especially regarding the influence of bursty vs. random packet  loss and its effect on perceived quality.

Therefore I'm interested in definitions of 'loss burstiness'. Are there any ideas other than those mentioned in "One-way Loss Pattern Sample Metrics"?

The 'm out of n' metrics was mentioned, but not in details. Can anyone explain more about this metrics?

Best Regards
Zlatokrilov Haim

------_=_NextPart_001_01C17D98.86E92794-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Dec 5 10:06:31 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22764 for ; Wed, 5 Dec 2001 10:06:31 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5F22w11968; Wed, 5 Dec 2001 10:02:02 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5Esjw10648; Wed, 5 Dec 2001 09:54:45 -0500 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id DDB3A4CF3F; Wed, 5 Dec 2001 09:54:44 -0500 (EST) Received: from research.att.com (roughan@wombat.research.att.com [135.207.26.100]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id JAA25024; Wed, 5 Dec 2001 09:54:42 -0500 (EST) Message-ID: <3C0E35A6.B21151BD@research.att.com> Date: Wed, 05 Dec 2001 09:56:38 -0500 From: Matthew Roughan Organization: AT&T Research Labs X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: "Henk Uijterwaal (RIPE-NCC)" Cc: Steven Van den Berghe , ippm@advanced.org, Merike Kaeo , Matthew J Zekauskas Subject: Re: [ippm] Current agenda for IPPM at IETF 52 - Salt Lake City 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: > > Steven, > > > one of the jobs of ippm is (as the charter expresses it) promoting the > > application of the metrics. Now, these metrics have been popping up in a > > variety of places (e.g. rmon, tewg) and i can assure you that there are > > other applications on their way. > > Great (hey, I'm implementing these metrics). > > > > > These applications have different requirements than the "new inter > > administrative domain ping" the current triplet owdp-test, owdp-control, > > owdp-mgmt is mainly aiming at. > > This is what I think we should try to accomplish. At an abstract level, > we need: > > 1. Metrics and measurement devices that implement them, > 2. Protocol(s) that allows measurements between different > implementations, > 3. A control mechanism that allows a user from any other area to do a > measurement > 4. A reporting protocol that returns the result to the user. > > So-far, IPPM has been doing (1) and we started on (2) and (3) a year or so > ago. (4) is still open. At the moment, other groups (RMON, TE, ...) > started to work on (3) and (4), which clearly overlaps with the work in > IPPM. > > I think we should try to coordinate these efforts and keep the number of > control and report mechanisms to preferably 1 or at least a small number. > I agree strongly here. Having a uniform control and reporting mechanism makes life a great deal easier. I think there is a lot to be gained from talking to the RMON group -- we don't want to reimplement a lot of stuff they have already thought about in slightly different contexts. Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Dec 5 13:41:43 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01734 for ; Wed, 5 Dec 2001 13:41:43 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5Id3w00785; Wed, 5 Dec 2001 13:39:03 -0500 Received: from bigglesworth.mail.be.easynet.net (bigglesworth.mail.be.easynet.net [212.100.160.67]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fB5Id0w00688; Wed, 5 Dec 2001 13:39:00 -0500 Received: from 212-100-179-113.adsl.easynet.be ([212.100.179.113]) by bigglesworth.mail.be.easynet.net with esmtp (Exim 3.16 #1) id 16Bgwd-0008Pw-00; Wed, 05 Dec 2001 19:38:59 +0100 Subject: Re: [ippm] Current agenda for IPPM at IETF 52 - Salt Lake City From: Steven Van den Berghe To: Merike Kaeo Cc: ippm@advanced.org, Matthew J Zekauskas In-Reply-To: <5.1.0.14.2.20011205014505.03b6c170@mail.merike.com> References: <1007543366.3151.0.camel@localhost.localdomain> <5.1.0.14.2.20011205014505.03b6c170@mail.merike.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 05 Dec 2001 19:39:35 +0100 Message-Id: <1007577575.3093.5.camel@localhost.localdomain> Mime-Version: 1.0 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit On Wed, 2001-12-05 at 10:50, Merike Kaeo wrote: > > > > >This is what I think we should try to accomplish. At an abstract level, > >we need: > > > > 1. Metrics and measurement devices that implement them, > > 2. Protocol(s) that allows measurements between different > > implementations, > > 3. A control mechanism that allows a user from any other area to do a > > measurement > > 4. A reporting protocol that returns the result to the user. > > > >So-far, IPPM has been doing (1) and we started on (2) and (3) a year or so > >ago. (4) is still open. At the moment, other groups (RMON, TE, ...) > >started to work on (3) and (4), which clearly overlaps with the work in > >IPPM. > > I've been following TEWG and Matt has been following RMON.....who else that > you know of is working on (3) and (4)? Agreed that coordination is > required on all fronts - hope to come to some consensus in SLC albeit the > time limitation. > so, you got the easy job:). You might want to check out http://search.ietf.org/internet-drafts/draft-choi-tunman-stats-00.txt for another measurement-related application. Cheers, Steven -- -- Steven Van den Berghe steven.vandenberghe@intec.rug.ac.be Workgroup Broadband Communication Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* A computer is like an Old Testament god, with a lot of rules and no mercy. - Joseph Campbell *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Dec 6 04:29:33 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22094 for ; Thu, 6 Dec 2001 04:29:33 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fB69T2x2007188; Thu, 6 Dec 2001 04:29:02 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fB69SJx3007169 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 6 Dec 2001 04:28:20 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB69QDc25585 for ; Thu, 6 Dec 2001 11:26:13 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Dec 2001 11:28:18 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 6 Dec 2001 11:28:18 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F91175715052E@esebe004.NOE.Nokia.com> From: vilho.raisanen@nokia.com To: hzlatokrilov@COMGATES.co.il Cc: ari.lakaniemi@nokia.com, vilho.raisanen@nokia.com, ippm@advanced.org Subject: RE: [ippm] 'bursty loss' metrics Date: Thu, 6 Dec 2001 11:28:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17E38.4F1931AA" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17E38.4F1931AA Content-Type: text/plain; charset="iso-8859-1" Hi, some further comments about loss correlations. Computing loss correlations is a matter of metrics, but making a direct link between end user experienced and packet loss correlation is a tougher problem in general. For example, it depends on the codec used. Also, the effect of packet losses depend on where it occurs with respect to sentence and so on. Perhaps Ari or some other audio coding guy can elaborate on this, but I'll just mention that I gave a presentation about one way of linking MOS and network-level QoS at IPPM slot at San Diego meeting one year ago. I guess the contribution should be linked to IETF proceedings. Vilho ------_=_NextPart_001_01C17E38.4F1931AA Content-Type: text/html; charset="iso-8859-1" 'bursty loss' metrics
Hi,
 
some further comments about loss correlations. Computing loss correlations is a matter of metrics, but making a direct link between end user experienced and packet loss correlation is a tougher problem in general. For example, it depends on the codec used. Also, the effect of packet losses depend on where it occurs with respect to sentence and so on. Perhaps Ari or some other audio coding guy can elaborate on this, but I'll just mention that I gave a presentation about one way of linking MOS and network-level QoS at IPPM slot at San Diego meeting one year ago. I guess the contribution should be linked to IETF proceedings.
 
    Vilho
 
------_=_NextPart_001_01C17E38.4F1931AA-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Dec 6 12:45:39 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05534 for ; Thu, 6 Dec 2001 12:45:39 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fB6Hj4x2001205; Thu, 6 Dec 2001 12:45:04 -0500 Received: from telchemy.com ([4.21.228.251]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fB6HiBx2000501 for ; Thu, 6 Dec 2001 12:44:12 -0500 Received: from TELWS104 [209.186.15.20] by telchemy.com with ESMTP (SMTPD32-6.06) id ADCC1C0218; Thu, 06 Dec 2001 12:41:32 -0500 Reply-To: From: "Alan Clark" To: , , Subject: RE: [ippm] 'bursty loss' metrics Date: Thu, 6 Dec 2001 12:40:09 -0500 Message-ID: <00d201c17e7d$0d5d13a0$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01C17E53.24870BA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <009CA59D1752DD448E07F8EB2F911757520C5D@esebe004.NOE.Nokia.com> 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_00D3_01C17E53.24870BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 'bursty loss' metricsThe algorithm described in TS 101 329-5 (VQmon) is described in an IPtel 2001 paper and in a number of standards contributions - these are collected together on (http://www.telchemy.com/techref.html). The key issues to consider when looking at burst packet loss effects are:- (i) Isolated lost packets are generally masked by packet loss concealment algorithms (ii) Periods of high packet loss are generally more noticeable to the listener (iii) At low average loss rates burst packet loss can sound better as there are long gaps between bursts (iv) At high average loss rates burst packet loss generally results in a lower subjective score (v) There are "time constants" associated with periods of poor quality, e.g. the longer a period of poor quality persists then the more annoyed a listener becomes, after the period of poor quality ends then it takes some time for the listener to forgive (or forget) (vi) There appears to be a recency effect which results in lower subjective scores for calls with bursts of packet loss near the end .. a test by AT&T showed a reduction in MOS of 0.6 due to this effect. Alan -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of vilho.raisanen@nokia.com Sent: Wednesday, December 05, 2001 9:24 AM To: hzlatokrilov@COMGATES.co.il; ippm@advanced.org Cc: vilho.raisanen@nokia.com Subject: RE: [ippm] 'bursty loss' metrics Hello, you could also take a look at ETSI EP TIPHON document TS 101 329-5 at http://www.etsi.org/tiphon. Effect of burstiness and means of measuring that have been addressed there. Vilho -----Original Message----- From: ext Haim Zlotokrilov [mailto:hzlatokrilov@COMGATES.co.il] Sent: 05 December 2001 15:51 To: 'ippm@advanced.org' Subject: [ippm] 'bursty loss' metrics Hi I'm doing a research about IP QoS for VoIP application, especially regarding the influence of bursty vs. random packet loss and its effect on perceived quality. Therefore I'm interested in definitions of 'loss burstiness'. Are there any ideas other than those mentioned in "One-way Loss Pattern Sample Metrics"? The 'm out of n' metrics was mentioned, but not in details. Can anyone explain more about this metrics? Best Regards Zlatokrilov Haim ------=_NextPart_000_00D3_01C17E53.24870BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 'bursty loss' metrics
The=20 algorithm described in TS  101 329-5 (VQmon) is described in an = IPtel 2001=20 paper and in a number of standards contributions - these are collected = together=20 on (http://www.telchemy.com/techref.html).&= nbsp;=20
 
The=20 key issues to consider when looking at burst packet loss effects=20 are:-
 
(i)=20 Isolated lost packets are generally masked by packet loss concealment=20 algorithms
 
(ii)=20 Periods of high packet loss are generally more noticeable to the=20 listener
 
(iii)=20 At low average loss rates burst packet loss can sound better as there = are long=20 gaps between bursts
 
(iv)=20 At high average loss rates burst packet loss generally results in a = lower=20 subjective score
 
(v)=20 There are "time constants" associated with periods of poor quality, e.g. = the=20 longer a period of poor quality persists then the more annoyed a = listener=20 becomes, after the period of poor quality ends then it takes some time = for the=20 listener to forgive (or forget)
 
(vi)=20 There appears to be a recency effect which results in lower = subjective=20 scores for calls with bursts of packet loss near the end .. a test = by=20 AT&T showed a reduction in MOS of 0.6 due to this=20 effect.
 
Alan
 
-----Original Message-----
From: = ippm-admin@advanced.org=20 [mailto:ippm-admin@advanced.org]On Behalf Of=20 vilho.raisanen@nokia.com
Sent: Wednesday, December 05, = 2001 9:24=20 AM
To: hzlatokrilov@COMGATES.co.il; = ippm@advanced.org
Cc:=20 vilho.raisanen@nokia.com
Subject: RE: [ippm] 'bursty loss'=20 metrics

Hello,
 
you=20 could also take a look at ETSI EP TIPHON document TS 101 329-5 at http://www.etsi.org/tiphon. = Effect of=20 burstiness and means of measuring that have been addressed=20 there.
 
    = Vilho
-----Original Message-----
From: ext Haim = Zlotokrilov=20 [mailto:hzlatokrilov@COMGATES.co.il]
Sent: 05 December = 2001=20 15:51
To: 'ippm@advanced.org'
Subject: [ippm] = 'bursty=20 loss' metrics

Hi
I'm doing a research = about IP QoS=20 for VoIP application, especially regarding the influence of bursty = vs.=20 random packet  loss and its effect on perceived = quality.

Therefore I'm interested in definitions of 'loss=20 burstiness'. Are there any ideas other than those mentioned in = "One-way Loss=20 Pattern Sample Metrics"?

The 'm out of n' metrics was mentioned, but not in = details.=20 Can anyone explain more about this metrics?

Best Regards
Zlatokrilov = Haim=20

------=_NextPart_000_00D3_01C17E53.24870BA0-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Dec 20 11:55:34 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12261 for ; Thu, 20 Dec 2001 11:55:34 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBKGt3Hh005801; Thu, 20 Dec 2001 11:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBKG9wHh023279 for ; Thu, 20 Dec 2001 11:09:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10501; Thu, 20 Dec 2001 11:09:54 -0500 (EST) Message-Id: <200112201609.LAA10501@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 20 Dec 2001 11:09:54 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-ipdv-08.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : IP Packet Delay Variation Metric for IPPM Author(s) : C. Demichelis, P. Chimento Filename : draft-ietf-ippm-ipdv-08.txt Pages : 20 Date : 17-Dec-01 This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in the One-Way- Delay of selected packets. This difference in delay is called 'IP Packet Delay variation.' The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-ipdv-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-ipdv-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011217141330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-ipdv-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-ipdv-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011217141330.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Dec 20 11:55:44 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12280 for ; Thu, 20 Dec 2001 11:55:43 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBKGt7Hh005813; Thu, 20 Dec 2001 11:55:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBKGABHh023409 for ; Thu, 20 Dec 2001 11:10:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10526; Thu, 20 Dec 2001 11:10:07 -0500 (EST) Message-Id: <200112201610.LAA10526@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 20 Dec 2001 11:10:07 -0500 Subject: [ippm] I-D ACTION:draft-shalunov-reordering-definition-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definition of IP Packet Reordering Metric Author(s) : S. Shalunov Filename : draft-shalunov-reordering-definition-00.txt Pages : 4 Date : 17-Dec-01 Various pieces of network testing equipment currently often report a characteristic that is referred to as a 'degree (or percentage) of packet reordering'. The way this metric is computed is often undocumented and it differs between vendors. Having a useful numeric measure of the degree of packet reordering is important for applications such as TCP and VoIP on different ends of the spectrum. However, the metric that makes sense for one application may have no or little applicability to another. This document introduces a definition of reordering metric that is hoped to be applicable to a number of different applications by parametrizing the metric. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shalunov-reordering-definition-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shalunov-reordering-definition-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shalunov-reordering-definition-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011217141405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shalunov-reordering-definition-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shalunov-reordering-definition-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011217141405.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Dec 20 12:44:12 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12260 for ; Thu, 20 Dec 2001 11:55:34 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBKGtAHh005831; Thu, 20 Dec 2001 11:55:10 -0500 Received: from smtp5.cluster.oleane.net (smtp5.cluster.oleane.net [195.25.12.27]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBJ9kCHh025214 for ; Wed, 19 Dec 2001 04:46:12 -0500 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp5.cluster.oleane.net with SMTP id fBJ9k9E34431 for ; Wed, 19 Dec 2001 10:46:10 +0100 (CET) Message-ID: <018101c18871$ca2fd960$0601a8c0@oleane.com> From: "Peter Lewis" To: Date: Wed, 19 Dec 2001 10:44:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017E_01C1887A.28949BA0" 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] Wireless IP Video : Call for Paper 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_017E_01C1887A.28949BA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What work is being conducted within the standardization bodies regarding = IP Wireless Video? What compression mechanisms will be used? What about = QoS, multicasting, and security aspects? How can copyright problems be = handled? How far along are wireless handset and PAD vendors? What will the first = services look like? What can we learn from the current trials underway = and the Japanese example? Responses during the Wireless IP Video event next 21-24 May 2002. A call for papers is online at: http://www.upperside.fr/wipv/wipvintro.htm ------=_NextPart_000_017E_01C1887A.28949BA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What work is being conducted within the = standardization bodies=20 regarding IP Wireless Video? What compression mechanisms will be used? = What=20 about QoS, multicasting, and security aspects? How can copyright = problems be=20 handled?
How far along are wireless handset and PAD vendors? What = will the=20 first services look like? What can we learn from the current trials = underway and=20 the Japanese example?
Responses during the Wireless IP Video event next = 21-24 May=20 2002.
 
A call for papers is online at:

http://www.upperside.= fr/wipv/wipvintro.htm
 
------=_NextPart_000_017E_01C1887A.28949BA0-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Dec 21 07:55:53 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23249 for ; Fri, 21 Dec 2001 07:55:53 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBLCt3Hh031561; Fri, 21 Dec 2001 07:55:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBLCs3Hh031525 for ; Fri, 21 Dec 2001 07:54:04 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fBLCs3T27154 for ; Fri, 21 Dec 2001 13:54:03 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.11.6/8.11.6) with ESMTP id fBLCs3t11017 for ; Fri, 21 Dec 2001 13:54:03 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 21 Dec 2001 13:54:02 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Subject: Re: [ippm] I-D ACTION:draft-shalunov-reordering-definition-00.txt In-Reply-To: <200112201610.LAA10526@ietf.org> 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 Stas, others, > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Definition of IP Packet Reordering Metric > Author(s) : S. Shalunov > Various pieces of network testing equipment currently often report a > characteristic that is referred to as a 'degree (or percentage) of > packet reordering'. The way this metric is computed is often > undocumented and it differs between vendors. Having a useful numeric > measure of the degree of packet reordering is important for > applications such as TCP and VoIP on different ends of the spectrum. > However, the metric that makes sense for one application may have no > or little applicability to another. This document introduces a > definition of reordering metric that is hoped to be applicable to a > number of different applications by parametrizing the metric. A couple of questions * How does this metric differ from the one presented by Dale in London? And if they are different, what are the pros and cons of this metric over Dale's. And, yes, I realize that this might be a non-trivial question but if we define two metrics for the same phenomena, then we should have an idea which one should be use when. * How does this metric deal with losses? If 4 out of 5 packets are received, with a packet in the middle lost, is this considered no reordering or equivalent to <1,2,4,5,3>? The same goes for time-outs (a packet arrive _after_ the destination asking for a retransmit). 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 Fri Dec 21 08:40:41 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23729 for ; Fri, 21 Dec 2001 08:40:41 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBLDe4Hh004469; Fri, 21 Dec 2001 08:40:04 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBLDd9Hi004247 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 21 Dec 2001 08:39:13 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fBLDd9F08415 for ; Fri, 21 Dec 2001 08:39:09 -0500 To: Subject: Re: [ippm] draft-shalunov-reordering-definition-00.txt References: From: stanislav shalunov Date: 21 Dec 2001 08:39:08 -0500 In-Reply-To: Message-ID: <87vgf0r8ub.fsf@cain.internet2.edu> Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > * How does this metric differ from the one presented by Dale in London? This metric is parametrized. Dale's not. See section 6 of my draft, which argues why parametrization is a good thing. (Different applications are different and this metric covers a large subset of the application space.) This metric is thought to be directly applicable to applications (e.g., TCP with a fixed dupack threshold, or an interactive video application with a buffer of some fixed number of packets). > * How does this metric deal with losses? Losses aren't counted as any sort of reordering. So, an application with a buffer for reordering repair of N buffers will have lost loss+N-reordering packets. > If 4 out of 5 packets are received, with a packet in the middle lost, > is this considered no reordering or equivalent to <1,2,4,5,3>? The > same goes for time-outs (a packet arrive _after_ the destination > asking for a retransmit). I don't understand the retransmit question. This metric maps from the cartesian product of finite sequences of sequence numbers and non-negative integers into real numbers. -- 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 Fri Dec 21 09:05:33 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23924 for ; Fri, 21 Dec 2001 09:05:32 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBLE53Hh009714; Fri, 21 Dec 2001 09:05:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBLE4pHh009701 for ; Fri, 21 Dec 2001 09:04:52 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fBLE4pT11052; Fri, 21 Dec 2001 15:04:51 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.11.6/8.11.6) with ESMTP id fBLE4pj11826; Fri, 21 Dec 2001 15:04:51 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 21 Dec 2001 15:04:51 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: stanislav shalunov cc: Subject: Re: [ippm] draft-shalunov-reordering-definition-00.txt In-Reply-To: <87vgf0r8ub.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 On 21 Dec 2001, stanislav shalunov wrote: > "Henk Uijterwaal (RIPE-NCC)" writes: > > > * How does this metric differ from the one presented by Dale in London? > > This metric is parametrized. Dale's not. See section 6 of my draft, > which argues why parametrization is a good thing. (Different > applications are different and this metric covers a large subset of > the application space.) > > This metric is thought to be directly applicable to applications > (e.g., TCP with a fixed dupack threshold, or an interactive video > application with a buffer of some fixed number of packets). If we continue with 2 metrics (or drafts), I think it should be stated somewhere which one covers what (cross-reference plus a bit of text). > > * How does this metric deal with losses? > > Losses aren't counted as any sort of reordering. So, an application > with a buffer for reordering repair of N buffers will have lost > loss+N-reordering packets. In other words, <1,2,4,5> has no reordering? > > If 4 out of 5 packets are received, with a packet in the middle lost, > > is this considered no reordering or equivalent to <1,2,4,5,3>? The > > same goes for time-outs (a packet arrive _after_ the destination > > asking for a retransmit). > > I don't understand the retransmit question. This metric maps from the > cartesian product of finite sequences of sequence numbers and > non-negative integers into real numbers. Yes, that is exactly my problem. Suppose I have an application that needs ALL the packets. Case #1: It receives packet 4, 5 and 3, in that order, with minimal delay between 5 and 3. My application can now put them in order and wait for packet 6. Case #2: It receives packets 4 and 5, followed by nothing. After a while, my application will (presumably) time-out and ask for packet to be resend. Now 3 arrives. In both cases, the reordering metric sees this as <1,2,4,5,3> and gives the same result. However, the performance of the setup in case 1 will be different from case 2. We can accept this, but then we have to give a second number to express the difference between the 2 cases, or we can modify the metric. 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 Fri Dec 21 09:16:19 2001 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24030 for ; Fri, 21 Dec 2001 09:16:19 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBLEG2Hh011293; Fri, 21 Dec 2001 09:16:02 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id fBLEF4Hi011267 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 21 Dec 2001 09:15:08 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fBLEF4F23992 for ; Fri, 21 Dec 2001 09:15:04 -0500 To: Subject: Re: [ippm] draft-shalunov-reordering-definition-00.txt References: From: stanislav shalunov Date: 21 Dec 2001 09:15:03 -0500 In-Reply-To: Message-ID: <87y9jwpsm0.fsf@cain.internet2.edu> Lines: 39 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > In other words, <1,2,4,5> has no reordering? That's correct, it has no N-reordering for any value of N. > Suppose I have an application that needs ALL the packets. > > Case #1: It receives packet 4, 5 and 3, in that order, with minimal > delay between 5 and 3. My application can now put them in order and > wait for packet 6. If it has a reordering repair buffer of at least 1 packet... > Case #2: It receives packets 4 and 5, followed by nothing. After a while, > my application will (presumably) time-out and ask for packet to be resend. > Now 3 arrives. If you were to measure the network with synthetic traffic (and not ask for retransmits), this would show up as loss, not as reordering. In fact, the network reordered nothing in this case, but simply lost a single packet. However, you raise a valid point: Not only the number of packets by which a packet is delayed matters, but, for some applications, other things matter as well. I'm thinking about other metrics that would cover that. > In both cases, the reordering metric sees this as <1,2,4,5,3> and > gives the same result. No, packets are numbered *as they are sent*. For the purposes of N-reordering, in the second case, what I see is <1, 2, 4, 5, 6> (3 is lost, no N-reordering for any value of N). -- 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