From mailman-bounces@ietf.org Fri Oct 1 11:00:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06938 for ; Fri, 1 Oct 2004 11:00:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKJo-0003kT-TX for ippm-archive@lists.ietf.org; Fri, 01 Oct 2004 06:07:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ippm-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:25:58 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.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, mailman-request@ietf.org ) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org . Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@ietf.org wurudu https://www1.ietf.org/mailman/options/ippm/ippm-archive%40lists.ietf.org From ippm-bounces@ietf.org Fri Oct 1 12:53:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24045 for ; Fri, 1 Oct 2004 12:53:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPnJ-0004HM-Rg; Fri, 01 Oct 2004 11:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDMuz-0004XS-Uc for ippm@megatron.ietf.org; Fri, 01 Oct 2004 08:53:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25672 for ; Fri, 1 Oct 2004 08:53:46 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDN3P-0006YG-1Q for ippm@ietf.org; Fri, 01 Oct 2004 09:02:34 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 1D90155CE9; Fri, 1 Oct 2004 14:53:15 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id B310655CE6 for ; Fri, 1 Oct 2004 14:53:14 +0200 (CEST) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i91CrErL024839 for ; Fri, 1 Oct 2004 14:53:14 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i91CrEOQ030461 for ; Fri, 1 Oct 2004 14:53:14 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 1 Oct 2004 14:53:14 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: ippm@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 5999c1eae0b69811f1dbf8ea39f5cf28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [ippm] Re: IPPM MIB X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org IPPM group, On August 16, I posted the note below regarding the IPPM MIB. If you planned to respond to this mail, please do so before Wednesday October 6. On Wednesday, the chairs will make a decision on the future of this work. Henk On Mon, 16 Aug 2004, Henk Uijterwaal (RIPE NCC) wrote: > IPPM group, > > Since the IPPM WG meeting in Seoul, there have been several discussions > (both public and private) between Emile Stephan, Andy Bierman (the IPPM > MIB technical advisor), the chairs of the WG and several others, on how to > proceed with the IPPM MIB document (draft-ietf-ippm-reporting-mib-06.txt). > This mail summarizes the discussions and proposes a way forward. > > We all agree that even though the current draft is in its 6th iteration, > there has been very little feedback from the WG on its contents. The > chairs did receive some informal comments on the document, these can be > summarized as "the document and MIB are too complex". > > A proposal has been made to for a simpler approach, based on a ring buffer > to store individual measurements. While this looked nice in theory, in > practice it is probably not possible to store and retrieve individual > measurements in a MIB at a rate of the order of 1Hz or more. In other > words, a MIB can only be used to report aggregate information, where the > aggregation is done either on demand or by default at regular intervals. > > As the next steps, we propose: > > 1. The mailing list will be asked to provide feedback on the question > what information they would like to see in the management interface > of a network measurement system. (See below). > > 2. When there is consensus on this question, we will look at existing > MIB's (in particular the RMONMIB TPM-MIB) to see what is > already there to satisfy the requirements generated in the previous > step and what has to be defined in our group. > > 3. The existing document will be rewritten to define whatever has to be > defined and nothing more. > > If there is little or no feedback on step 1, we will conclude that there > is no interest in an IPPM at the moment. In that case, the existing > document will be finished and a published as an informational RFC. > > To start, the first questions we would like to see answered, are: > > * What information would you like to see in a management interface of a > measurement system? > * What action would you like to take with a management interface of a > measurement system? > * Do you have requests from the users of your implementation of the > IPPM metrics for an interface between the measurement system and > a network management system (NMS)? > > Please note the constraint mentioned above. It also should be noted that > some of the IPPM metrics implementations do not use a MIB but do report > aggregated information in other formats (CSV, XML, graphical, ...) This > is information that could (potentially) be reported in a MIB as well. > > We invite everybody to comment on both the procedure and the questions > above before September 30, > > Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Oct 7 14:37:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09895 for ; Thu, 7 Oct 2004 14:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFcyx-00022g-39; Thu, 07 Oct 2004 14:27:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFcsZ-0000zt-L8 for ippm@megatron.ietf.org; Thu, 07 Oct 2004 14:20:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08256 for ; Thu, 7 Oct 2004 14:20:36 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFcn7-0005lk-5I for ippm@ietf.org; Thu, 07 Oct 2004 14:15:02 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 0FCF94E724; Thu, 7 Oct 2004 20:02:39 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id B4B6D4E714; Thu, 7 Oct 2004 20:02:38 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i97I2crL010910; Thu, 7 Oct 2004 20:02:38 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i97I2c84006599; Thu, 7 Oct 2004 20:02:38 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Thu, 7 Oct 2004 20:02:38 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: Matthew J Zekauskas , acmorton@att.com, ippm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 2057ec50cce2e6661f779fdcc04f8c82 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [ippm] WGLC on draft-ietf-ippm-reordering-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org IPPM group, The latest draft of "Packet Reordering Metric for IPPM" has all the fixes and changes suggested on this list and at previous IETF meetings. The chairs propose a Working Group last-call for this document, draft-ietf-ippm-reordering-07.txt Please comment on whether or not you feel that this Internet-Draft should be given to the Area Directors and the IESG for consideration as a Proposed Standard RFC. Submit your comments to the IPPM mailing list or to the chairs or I-D authors as you feel appropriate (although public comments are preferred). This Working Group last call will end on Friday, October 29, 2004 at 9:00 GMT. One pointer for the document is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-07.txt The chairs, Matt & Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Oct 7 14:38:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10016 for ; Thu, 7 Oct 2004 14:38:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFcz0-000244-0v; Thu, 07 Oct 2004 14:27:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFcsg-00010o-2f for ippm@megatron.ietf.org; Thu, 07 Oct 2004 14:20:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08338 for ; Thu, 7 Oct 2004 14:20:42 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFciH-0005SB-Kn for ippm@ietf.org; Thu, 07 Oct 2004 14:10:02 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 2D6C14E538; Thu, 7 Oct 2004 19:59:10 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CE64B4E5BF; Thu, 7 Oct 2004 19:59:09 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i97Hx9rL010054; Thu, 7 Oct 2004 19:59:09 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i97Hx9Uh006436; Thu, 7 Oct 2004 19:59:09 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Thu, 7 Oct 2004 19:59:09 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: ippm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 2052cfcc208ebc6f1c484197a2df6147 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Matthew J Zekauskas , Allison Mankin Subject: [ippm] IPPM MIB (fwd) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org IPPM group, On August 16, we asked the working group for feedback on the question "what information would you like to see in the management interface of a network measurement system". There have been almost no responses to the list on this question. We conclude that the members of this WG are, at the moment, not interested in the development of an IPPM MIB. As a result, we propose to remove this work item from the agenda. We realize that a considerable amount of work has been put into draft-ietf-ippm-reporting-mib-06.txt. In order to save this work for the future, we encourage the authors to finish this document, then submit it as an individual, informational RFC. The chairs, Matt & Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Oct 8 11:26:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04091 for ; Fri, 8 Oct 2004 11:26:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwTG-0005iL-K5; Fri, 08 Oct 2004 11:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwMf-0004ST-LS for ippm@megatron.ietf.org; Fri, 08 Oct 2004 11:09:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02689 for ; Fri, 8 Oct 2004 11:09:00 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwWc-0000b7-Nq for ippm@ietf.org; Fri, 08 Oct 2004 11:19:18 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AC7F51CD865; Fri, 8 Oct 2004 11:09:01 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22967-05; Fri, 8 Oct 2004 11:09:01 -0400 (EDT) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id B1DDF1CD869; Fri, 8 Oct 2004 11:09:00 -0400 (EDT) Date: Fri, 08 Oct 2004 11:08:59 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Message-ID: <92E1A2E468C02BDA8FAD7982@DCFF15AFC1F6764BA3927E50> X-Mailer: Mulberry/3.1.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Henk Uijterwaal , Matt Zekauskas Subject: [ippm] Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA (fwd) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit FYI - if there are any people that are posting a -00 draft for ippm, let one of us know before the beginning of the day (US eastern time) on Monday. I don't anticipate any, but... --Matt ---------- Forwarded Message ---------- Date: Friday, October 08, 2004 9:56 AM -0400 From: Internet-Drafts Administrator To: Working Group Chairs Cc: INVALID_ADDRESS Subject: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Dear IETF Working Group Chairs: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@ietf.org by no later than five (5) business days prior to the cutoff date for -00 submissions, or by Monday, October 11th at 9:00 AM ET for the 61st IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. Thank you for your cooperation in this matter. The Internet-Drafts Administrator FYI: The Internet-Draft cutoff dates as well as other significant dates for the 61st IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_61.html. ---------- End Forwarded Message ---------- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Oct 8 14:24:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18392 for ; Fri, 8 Oct 2004 14:24:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzGl-0001EQ-Gw; Fri, 08 Oct 2004 14:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFz59-0004wg-Ox for ippm@megatron.ietf.org; Fri, 08 Oct 2004 14:03:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16516 for ; Fri, 8 Oct 2004 14:03:08 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzF8-0004aX-LB for ippm@ietf.org; Fri, 08 Oct 2004 14:13:27 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 20:03:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ippm] IPPM MIB (fwd) Date: Fri, 8 Oct 2004 20:03:05 +0200 Message-ID: Thread-Topic: RE: [ippm] IPPM MIB (fwd) Thread-Index: AcStYQ8iK8aMjRgCRxe/5zGdfht61A== From: "STEPHAN Emile RD-CORE-LAN" To: "Henk Uijterwaal \(RIPE NCC\)" , X-OriginalArrivalTime: 08 Oct 2004 18:03:06.0484 (UTC) FILETIME=[0FFC4340:01C4AD61] X-Spam-Score: 0.5 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: Matthew J Zekauskas , Allison Mankin X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1796170326==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============1796170326== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AD61.0FC69A1C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AD61.0FC69A1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Henk and Matt, In the mail sent in the list you never proposed that the IPPM MIB will = be removed from the charter. You said "...In that case, the existing = document will be finished and a published as an informational RFC." I consider that what is happening is against the spirit of a = standardization process for the following reasons: -1- Attendees don't care if a WG MIB is informational or BCP or standard = track. Consequently I think that most of them understood that if they = were not enough reaction the IPPM MIB will become an informational WG = draft. So you should have clearly said to the list that "...In that = case, the existing document will be finished and a published as an = individual informational RFC.". -2- Making an implementation is part of the standardization process of = the IETF. France Telecom decided to make an implementation to validate = the specification after the document became a WG item and after the mail = from Andy (19/11/2001) telling both to ippm and rmon lists that he = wanted a MIB that exposed aggregated statistics based directly on the = IPPM metrics.=20 -3- I have taken in account all the requests from other WG. I extracted = the IPPM REGISTRY from the IPPM MIB to satisfy the needs of other MIBs. = I removed any informational reference to the IPPM MIB in the IPPM = REGISTRY to facilitate the evolution of the TPM MIB (which has a = normative reference to IPPM REGISTRY).=20 -4- Before the last meeting, an expert from another WG proposed to co = author the IPPM MIB because the design of IPPM MIB fits specific needs = related to scalability and user separation... That should be a good = opportunity to complete this IPPM MIB while taking in account the = constraints of the integration in routers. He retracted because he heard = that the IPPM MIB was kill. So if your decision was taken before the = last meeting you should have clearly announced in the list that the IPPM = MIB will be removed from the charter if there were not more interest: = You should never have said that this WG item will became informational. So I consider that the IPPM MIB should become an informational WG = document as proposed in the ippm list in August and because this WG item = was accepted and motivated by both the chairs and the TA.=20 Regards Emile -----Message d'origine----- De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de = Henk Uijterwaal (RIPE NCC) Envoy=E9 : jeudi 7 octobre 2004 19:59 =C0 : ippm@ietf.org Cc : Matthew J Zekauskas; Allison Mankin Objet : [ippm] IPPM MIB (fwd) IPPM group, On August 16, we asked the working group for feedback on the question "what information would you like to see in the management interface of a network measurement system". There have been almost no responses to the list on this question. We conclude that the members of this WG are, at the moment, not = interested in the development of an IPPM MIB. As a result, we propose to remove = this work item from the agenda. We realize that a considerable amount of work has been put into draft-ietf-ippm-reporting-mib-06.txt. In order to save this work for the future, we encourage the authors to finish this document, then submit it as an individual, informational RFC. The chairs, Matt & Henk -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre = http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- In a room with a window in the corner, I found truth. (Ian = Curtis) _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm ------_=_NextPart_001_01C4AD61.0FC69A1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ippm] IPPM MIB (fwd)

Dear = Henk and Matt,

In = the mail sent in the list you never = proposed that the IPPM MIB will be removed from the charter. = You said "...In that case, the = existing document will be finished and a published as an informational = RFC."

I = consider that what is happening is against the spirit of a = standardization process for the = following reasons:

-1- = Attendees don't care if a WG MIB is informational or BCP or standard = track. Consequently I think that = most of them understood that if they were not enough reaction the IPPM = MIB will become an informational WG draft. So you should have clearly said to the list that "...In that case, the existing document = will be finished and a published as an individual informational = RFC.".

-2- = Making an implementation is part of the standardization process of the = IETF. France Telecom decided to = make an implementation to validate = the specification after the document became a WG item and after the mail = from Andy (19/11/2001) telling both to ippm and rmon lists that he = wanted a MIB that exposed aggregated statistics based directly on the = IPPM metrics.

-3- I = have taken in account all the = requests from other WG. I extracted = the IPPM REGISTRY from the IPPM MIB to satisfy the needs of other = MIBs. I removed any informational = reference to the IPPM MIB in the IPPM REGISTRY to facilitate the = evolution of the TPM MIB (which has a normative reference to IPPM REGISTRY).

-4- = Before the last meeting, = an expert from another WG proposed to co author the IPPM = MIB because the design of IPPM MIB fits specific needs related to = scalability and user separation... That should be a good opportunity to complete this = IPPM MIB while taking in account = the constraints of the integration in routers. He retracted because he heard that the IPPM MIB was = kill. So if your decision was taken = before the last meeting you should have clearly announced in the list = that the IPPM MIB will be removed = from the = charter if there were not more interest: You should = never = have said that this WG item will = became informational.

So I = consider that the IPPM MIB should become an informational WG document as = proposed in the ippm list in August and = because this WG item was accepted and motivated by both the chairs and the = TA.

Regards

Emile

-----Message d'origine-----

De : = ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] = De la part de Henk Uijterwaal (RIPE NCC)

Envoy=E9 = : jeudi 7 octobre 2004 19:59

=C0 : = ippm@ietf.org

Cc : = Matthew J Zekauskas; Allison Mankin

Objet : = [ippm] IPPM MIB (fwd)

IPPM = group,

On = August 16, we asked the working group for feedback on the = question

"what information would you like to see in the = management interface of a

network measurement system".  There have been almost no responses to = the

list = on this question.

We = conclude that the members of this WG are, at the moment, not = interested

in = the development of an IPPM MIB.  As a result, we propose to remove this

work = item from the agenda.

We = realize that a considerable amount of work has been put = into

draft-ietf-ippm-reporting-mib-06.txt. In order to save = this work for the

future, we encourage the authors to finish this document, = then submit it

as an = individual, informational RFC.

The = chairs,

Matt = & Henk

----------------------------------------------------------= --------------------

Henk = Uijterwaal          &nb= sp;           &nbs= p;    Email: = henk.uijterwaal(at)ripe.net

RIPE = Network Coordination = Centre          http://www.amsterdamned.org/~h= enk

P.O.Box = 10096          Singel = 258         Phone: = +31.20.5354414

1001 = EB Amsterdam      1016 AB Amsterdam  Fax: = +31.20.5354445

The = Netherlands        The = Netherlands    Mobile: +31.6.55861746

----------------------------------------------------------= --------------------

In a = room with a window in the corner, I found = truth.           <= /FONT> (Ian Curtis)

_______________________________________________

ippm = mailing list

ippm@ietf.org

https://www1.ietf.org= /mailman/listinfo/ippm

------_=_NextPart_001_01C4AD61.0FC69A1C-- --===============1796170326== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1796170326==-- From ippm-bounces@ietf.org Sat Oct 9 11:47:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21791 for ; Sat, 9 Oct 2004 11:47:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGJPx-0000S7-7Z; Sat, 09 Oct 2004 11:45:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGJPV-0000Fk-Dv for ippm@megatron.ietf.org; Sat, 09 Oct 2004 11:45:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21603 for ; Sat, 9 Oct 2004 11:45:27 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGJZd-0000Gc-Dl for ippm@ietf.org; Sat, 09 Oct 2004 11:55:58 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id CEDD34FDC3; Sat, 9 Oct 2004 17:44:56 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 65F624FD66; Sat, 9 Oct 2004 17:44:56 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i99FiurL003229; Sat, 9 Oct 2004 17:44:56 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i99Fit0U001246; Sat, 9 Oct 2004 17:44:56 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Sat, 9 Oct 2004 17:44:55 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: STEPHAN Emile RD-CORE-LAN Subject: RE: [ippm] IPPM MIB (fwd) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000005 / 0.0 / 0.0 / disabled X-RIPE-Signature: a1c12e6c631e72dbec3cc6a56fc0d6f0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Allison Mankin , Matthew J Zekauskas , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear Emile, > In the mail sent in the list you never proposed that the IPPM MIB will > be removed from the charter. You said "...In that case, the existing > document will be finished and a published as an informational RFC." > > I consider that what is happening is against the spirit of a > standardization process for the following reasons: I agree that I could have put the word "individual" in the sentence above. However, you are quoting only 1 sentence out of a fairly long mail. The same mail said that if there was little or no feedback on the questions asked in the mail, we would conclude that the IPPM WG had no interest in producing a MIB at this time. There was, in fact, very little feedback, so I believe the conclusion that the WG is not interested in this, is correct. I think the key of a standardization process in a working group, is that the participants get together and discuss what should be in the standard. That has not happened for this document in the past 3 years: the 2 authors were the only (major) contributors to the document and the document was read by maybe 3 to 6 people. So, the document that is there now, IMHO, cannot be considered a product of the working group and thus should not be published as the product of the working group. And this is exactly what we propose: the WG is not interested in this at the moment, but a significant amount of work has been done by a small group of people. That should be saved for the future, so we encourage you to finish the document and publish it as your work under your name. Obviously, I'll be happy to explain all this to the IESG when you submit your document. > -2- Making an implementation is part of the standardization process of > the IETF. France Telecom decided to make an implementation to validate > the specification I appreciate the work done by France Telecom, but none of the other operators I spoke to appeared to be interested in this work. > [...] after the document became a WG item and after the mail > from Andy (19/11/2001) telling both to ippm and rmon lists that he > wanted a MIB that exposed aggregated statistics based directly on the > IPPM metrics. I wasn't a WG chair at the time but I was in the meeting where this happened. At that point, there was some interest in this and the WG expected that a number of people would stand up and contribute. Now, 3 years later, it turns out that this conclusion was wrong. > -4- Before the last meeting, an expert from another WG proposed to co > author the IPPM MIB [...] He retracted because he heard > that the IPPM MIB was kill. Until the beginning of this week, no decision had been made. In fact, I had hoped that others would stand up and contribute to this effort. That did not happen. Kind regards, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Oct 12 09:56:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21006 for ; Tue, 12 Oct 2004 09:56:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMy3-0003mG-VO; Tue, 12 Oct 2004 09:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMir-0000Nt-I6 for ippm@megatron.ietf.org; Tue, 12 Oct 2004 09:29:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19413 for ; Tue, 12 Oct 2004 09:29:48 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMtZ-000597-9Y for ippm@ietf.org; Tue, 12 Oct 2004 09:40:56 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 15:26:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Oct 2004 15:26:46 +0200 Message-ID: Thread-Topic: IPPM Registry Thread-Index: AcSuFu3XRSLrHU57QFW8Wm4A0hvcXgCRf0Zg From: "STEPHAN Emile RD-CORE-LAN" To: "Henk Uijterwaal \(RIPE NCC\)" X-OriginalArrivalTime: 12 Oct 2004 13:26:47.0588 (UTC) FILETIME=[1FD87E40:01C4B05F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: Allison Mankin , Matthew J Zekauskas , ippm@ietf.org Subject: [ippm] IPPM Registry X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear All, What is the next step for the ippm registry?=20 The TPM MIB is 'Proposed Standard' and has a normative reference to the ippm registry. So I am not sure that 'BCP' is the right category for the ippm registry. My thinking is that it is ready for another WG last call.=20 Regards Emile _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Oct 17 22:39:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16187 for ; Sun, 17 Oct 2004 22:39:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJNOk-00043P-H8; Sun, 17 Oct 2004 22:37:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJNNA-0001Tf-UF for ippm@megatron.ietf.org; Sun, 17 Oct 2004 22:35:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15829 for ; Sun, 17 Oct 2004 22:35:40 -0400 (EDT) Received: from halls-mailgw.acns.colostate.edu ([129.82.100.23] helo=mail.halls.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJNZ2-0004WJ-NV for ippm@ietf.org; Sun, 17 Oct 2004 22:48:01 -0400 Received: from [192.168.0.2] (univ096242.halls.colostate.edu [129.82.96.242]) by mail.halls.colostate.edu (8.12.11/8.12.11) with ESMTP id i9I2ZcYF000675 for ; Sun, 17 Oct 2004 20:35:38 -0600 Message-ID: <41732C11.1020900@engr.colostate.edu> Date: Sun, 17 Oct 2004 20:36:01 -0600 From: Nischal Piratla User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [ippm] Question about IPPM reordering draft X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit <>In draft-ietf-ippm-reordering-07.txt document, a list of 'MUST" requirements is listed as follows: Reordering Metrics MUST: + have one or more relevant applications, such as receiver design or network characterization. + be computable "on the fly" + work with Poisson and Periodic test streams + work even if the stream has duplicate or lost packets I am trying to understand why Poisson test streams are specifically stated in the third point. Could anyone please elaborate on this particular choice instead of saying all test streams? - Nischal Piratla ****************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) Department of Electrical and Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: +1 970-491-7974 Fax: +1 970-491-2249 CNRL: http://www.engr.colostate.edu/ece/Research/cnrl Home: http://lamar.colostate.edu/~nischal ****************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Oct 17 22:43:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16552 for ; Sun, 17 Oct 2004 22:43:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJNTV-0004VB-8S; Sun, 17 Oct 2004 22:42:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJNSc-0004NP-Ow for ippm@megatron.ietf.org; Sun, 17 Oct 2004 22:41:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16377 for ; Sun, 17 Oct 2004 22:41:20 -0400 (EDT) Received: from halls-mailgw.acns.colostate.edu ([129.82.100.23] helo=mail.halls.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJNeW-0004dS-VD for ippm@ietf.org; Sun, 17 Oct 2004 22:53:41 -0400 Received: from [192.168.0.2] (univ096242.halls.colostate.edu [129.82.96.242]) by mail.halls.colostate.edu (8.12.11/8.12.11) with ESMTP id i9I2fL82000725 for ; Sun, 17 Oct 2004 20:41:21 -0600 Message-ID: <41732D69.6030404@engr.colostate.edu> Date: Sun, 17 Oct 2004 20:41:45 -0600 From: Nischal Piratla User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Subject: [ippm] Question 2 - draft-ietf-ippm-reordering-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit >From the draft-ietf-ippm-reordering-07.txt document, here is a piece of text " 4.2.1 Metric Name: Type-P-packet-Reordering-Extent-Stream 4.2.2 Parameter Notation: Given a stream of packets sent from a source to a destination, let K be the total number of packets in that stream. Assign each packet a sequence number, a consecutive integer from 1 to K in the order of packet transmission (at the source). Let L be the total number of packets received out of the K packets sent. Recall that identical copies (duplicates) have been removed, so L<=K. Let s[1], s[2], ..., s[L], represent the original sequence numbers associated with the packets in order of arrival. Consider a reordered packet (as identified in section 3) with arrival index i and source sequence number s[i]. There exists a set of indexes j (1<=j s[i]. " The metric needs to make sure that there are no duplicates and also there is no in-built mechanism to avoid duplicates. Correct me if I am wrong, but does that mean this metric requires buffering of all the packets til the end of the stream? I look forward to your comments. - Nischal Piratla ****************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) Department of Electrical and Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: +1 970-491-7974 Fax: +1 970-491-2249 CNRL: http://www.engr.colostate.edu/ece/Research/cnrl Home: http://lamar.colostate.edu/~nischal ****************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Oct 17 23:15:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18831 for ; Sun, 17 Oct 2004 23:15:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJNtY-0007Oj-Kx; Sun, 17 Oct 2004 23:09:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJNot-0006te-50 for ippm@megatron.ietf.org; Sun, 17 Oct 2004 23:04:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18016 for ; Sun, 17 Oct 2004 23:04:20 -0400 (EDT) Received: from halls-mailgw.acns.colostate.edu ([129.82.100.23] helo=mail.halls.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJO0k-00056d-K4 for ippm@ietf.org; Sun, 17 Oct 2004 23:16:41 -0400 Received: from [192.168.0.2] (univ096242.halls.colostate.edu [129.82.96.242]) by mail.halls.colostate.edu (8.12.11/8.12.11) with ESMTP id i9I34InV000895 for ; Sun, 17 Oct 2004 21:04:19 -0600 Message-ID: <417332CA.9020003@engr.colostate.edu> Date: Sun, 17 Oct 2004 21:04:42 -0600 From: Nischal Piratla User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Subject: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Here is the definition for Type-P-Reordered from the draft. To explain this concept, the draft presents two terms namely, s and NextEXp. It is also stated that NextExp value cannot decrease. And, if Type-P-Reordered is FALSE, then the NextExp value will increase. The corresponding piece of text from the document is pasted below: "3.3 Definition: If a packet is found to be reordered by comparison with the Next Expected value, its Type-P-Reordered = TRUE; otherwise Type-P- Reordered = FALSE, as defined below: Morton, et al. Standards Track exp. Feb 2005 Page 6 Packet Reordering Metric for IPPM August 2004 The value of Type-P-Reordered is defined as TRUE if s < NextExp (the packet is reordered). In this case, NextExp value does not change. The value of Type-P-Reordered is defined as FALSE if s >= NextExp (the packet is in-order). In this case, NextExp is set to s+1. Since the Next Expected value cannot decrease, it provides a non- reversing order criterion to identify reordered packets. This definition can also be specified in pseudo-code. On successful arrival of a packet with sequence number s: if s >= NextExp then /* s is in-order */ NextExp = s + 1; Type-P-Reordered = False; else /* when s < NextExp */ Type-P-Reordered = True" The question is about the way the Type-P-Reordered is defined. Let us consider the example of two packet reordering from the draft. \/ \/ s = 1, 2, 3, 4, 7, 5, 6, 8, 9, 10 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 /\ /\ In this example, will the arrival of Type-P-Reordered be considered TRUE or FALSE, when packet with sequence number '6' arrives? If it is TRUE then the definition seems to stand good for Reordering-Extent metric where packet '6' is assigned an extent. But n-reordering metric doesn't seem to fit the group of Type-P-Reordered metrics, as it does not account for this reordering. On the other hand, if the Type-P-Reordered is FALSE, then Reordering-Extent doesn't strictly belong to this class as it computes an extent for a packet that is not reordered! In other words, does Type-P-Reordered mean that the above definition is strictly followed in treating a packet as in-order or out-of-order? May be I missed something here. Can someone please clarify the justification on having both the metrics as Type-P-Reordered metrics? Thanks, Nischal Piratla -- ****************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) Department of Electrical and Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: +1 970-491-7974 Fax: +1 970-491-2249 CNRL: http://www.engr.colostate.edu/ece/Research/cnrl Home: http://lamar.colostate.edu/~nischal ****************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Oct 18 00:08:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22923 for ; Mon, 18 Oct 2004 00:08:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJOmw-000846-5h; Mon, 18 Oct 2004 00:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJOmJ-0007w3-N0 for ippm@megatron.ietf.org; Mon, 18 Oct 2004 00:05:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22543 for ; Mon, 18 Oct 2004 00:05:44 -0400 (EDT) Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJOyD-0006TW-FN for ippm@ietf.org; Mon, 18 Oct 2004 00:18:06 -0400 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i9I458S0021630 for ; Mon, 18 Oct 2004 00:05:14 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (7.1.006) id 4156E8DC004BEC07; Mon, 18 Oct 2004 00:05:14 -0400 Received: from acmortonw.att.com ([135.210.105.4]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i9I45CZ08263; Mon, 18 Oct 2004 00:05:12 -0400 (EDT) Message-Id: <6.0.3.0.0.20041018000011.02fe63b0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 18 Oct 2004 00:04:40 -0400 To: Nischal Piratla , ippm@ietf.org From: Al Morton Subject: Re: [ippm] Question about IPPM reordering draft In-Reply-To: <41732C11.1020900@engr.colostate.edu> References: <41732C11.1020900@engr.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 10:36 PM 10/17/2004, Nischal Piratla wrote: >I am trying to understand why Poisson test streams are specifically stated >in the third point. >Could anyone please elaborate on this particular choice instead of saying >all test streams? >- Nischal Piratla Poisson Streams are specifically identified in the RFC 2330 Framework for IPPM, and Periodic Streams in RFC 3432. This requirement does not preclude other streams. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Oct 18 00:17:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24667 for ; Mon, 18 Oct 2004 00:17:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJOvS-0001gh-5c; Mon, 18 Oct 2004 00:15:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJOvB-0001ZR-HM for ippm@megatron.ietf.org; Mon, 18 Oct 2004 00:14:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24089 for ; Mon, 18 Oct 2004 00:14:54 -0400 (EDT) Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJP76-0006ls-Jn for ippm@ietf.org; Mon, 18 Oct 2004 00:27:16 -0400 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i9I4DYkZ023607 for ; Mon, 18 Oct 2004 00:14:24 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (7.1.006) id 4156E8DC004BF04D; Mon, 18 Oct 2004 00:14:23 -0400 Received: from acmortonw.att.com ([135.210.105.4]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i9I4EMZ08272; Mon, 18 Oct 2004 00:14:22 -0400 (EDT) Message-Id: <6.0.3.0.0.20041018000931.02ff1080@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 18 Oct 2004 00:13:50 -0400 To: Nischal Piratla , ippm@ietf.org From: Al Morton Subject: Re: [ippm] Question 2 - draft-ietf-ippm-reordering-07.txt In-Reply-To: <41732D69.6030404@engr.colostate.edu> References: <41732D69.6030404@engr.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 10:41 PM 10/17/2004, Nischal Piratla wrote: >The metric needs to make sure that there are no duplicates and also there >is no in-built mechanism to avoid duplicates. >Correct me if I am wrong, but does that mean this metric requires >buffering of all the packets til the end of the stream? The draft discusses this question, since it came up many times before: From section 3.6 ... If duplicate packets (multiple non-corrupt copies) arrive at the destination, they MUST be noted and only the first to arrive is considered for further analysis (copies would be declared reordered according to the definition above). This requirement has the same storage implications as earlier IPPM metrics, and follows the precedent of RFC 2679. We provide a suggestion to minimize storage size needed in the section on Measurement and Implementation Issues. From section 6. Measurement and Implementation Issues ... The requirement to ignore duplicate packets also mandates storage. Here, tracking the sequence numbers of missing packets may minimize storage size. Missing packets may eventually be declared lost, or reordered if they arrive. The missing packet list and the largest sequence number received thus far (NextExp - 1) are sufficient information to determine if a packet is a duplicate (assuming a manageable storage size for packets that are missing due to loss). ... Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Oct 18 00:36:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26942 for ; Mon, 18 Oct 2004 00:36:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJPEX-0003it-Lz; Mon, 18 Oct 2004 00:34:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJP6U-0003H7-6f for ippm@megatron.ietf.org; Mon, 18 Oct 2004 00:26:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26220 for ; Mon, 18 Oct 2004 00:26:35 -0400 (EDT) Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJPIO-00077a-BW for ippm@ietf.org; Mon, 18 Oct 2004 00:38:57 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i9I4P9fT015753 for ; Sun, 17 Oct 2004 23:26:05 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh0i.attrh.att.com (7.1.006) id 4160235C00266279; Mon, 18 Oct 2004 00:26:05 -0400 Received: from acmortonw.att.com ([135.210.105.4]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i9I4Q3Z08281; Mon, 18 Oct 2004 00:26:03 -0400 (EDT) Message-Id: <6.0.3.0.0.20041018001640.02ff4eb0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 18 Oct 2004 00:25:31 -0400 To: Nischal Piratla , ippm@ietf.org From: Al Morton Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt In-Reply-To: <417332CA.9020003@engr.colostate.edu> References: <417332CA.9020003@engr.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 11:04 PM 10/17/2004, Nischal Piratla wrote: >...In other words, does Type-P-Reordered mean that the above definition is >strictly followed in treating a packet as in-order or out-of-order? >May be I missed something here. Can someone please clarify the >justification on having both the metrics as Type-P-Reordered metrics? > >Thanks, >Nischal Piratla Type-P-Reordered is strictly followed, and packet 6 is TRUE = Reordered. n-reordering exists as a separate metric, with a different name: 5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric 5.1 Metric Name: Type-P-packet-n-Reordering-Stream ... The fact that n-reordered packets are a subset of Type-P-Reordered =TRUE is stated several times in the draft. For example, at the end of section 5.4: ... A packet's n-reordering is sometimes equal to its reordering extent, e. n-reordering is different in the following ways: 1. n is a count of early packets with consecutive arrival positions at the receiver. 2. Reordered packets may not be n-reordered, but will have an extent, e (see the examples). Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Oct 18 03:24:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22449 for ; Mon, 18 Oct 2004 03:24:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJRqQ-00041l-IH; Mon, 18 Oct 2004 03:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJRqA-0003vy-Et for ippm@megatron.ietf.org; Mon, 18 Oct 2004 03:21:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22266 for ; Mon, 18 Oct 2004 03:21:54 -0400 (EDT) Received: from halls-mailgw.acns.colostate.edu ([129.82.100.23] helo=mail.halls.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJS24-0001mp-QT for ippm@ietf.org; Mon, 18 Oct 2004 03:34:17 -0400 Received: from [192.168.0.2] (univ096242.halls.colostate.edu [129.82.96.242]) by mail.halls.colostate.edu (8.12.11/8.12.11) with ESMTP id i9I7LqHr002559 for ; Mon, 18 Oct 2004 01:21:52 -0600 Message-ID: <41736F29.30709@engr.colostate.edu> Date: Mon, 18 Oct 2004 01:22:17 -0600 From: Nischal Piratla User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt References: <417332CA.9020003@engr.colostate.edu> <6.0.3.0.0.20041018001640.02ff4eb0@custsla.mt.att.com> In-Reply-To: <6.0.3.0.0.20041018001640.02ff4eb0@custsla.mt.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Al Morton wrote: > At 11:04 PM 10/17/2004, Nischal Piratla wrote: > >> ...In other words, does Type-P-Reordered mean that the above >> definition is strictly followed in treating a packet as in-order or >> out-of-order? >> May be I missed something here. Can someone please clarify the >> justification on having both the metrics as Type-P-Reordered metrics? >> >> Thanks, >> Nischal Piratla > > Type-P-Reordered is strictly followed, and packet 6 is TRUE = Reordered. > > n-reordering exists as a separate metric, with a different name: > > 5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric > > 5.1 Metric Name: > > Type-P-packet-n-Reordering-Stream > ... > The fact that n-reordered packets are a subset of Type-P-Reordered =TRUE > is stated several times in the draft. For example, at the end of > section 5.4: > ... > A packet's n-reordering is sometimes equal to its reordering extent, > e. n-reordering is different in the following ways: > > 1. n is a count of early packets with consecutive arrival positions > at the receiver. > > 2. Reordered packets may not be n-reordered, but will have an > extent, e (see the examples). > > Al Al, If n-reordered packets are a subset of Type-P-Reordered=TRUE then does it mean that n-reordering considers some Type-P-Reordered =TRUE as reordered and others as not reordered. However, the definition of Type-P-Reordered clearly states when a packet is considered reordered and when it is not. With this subset assumption, the difference between out-of-order and in-order packets is not clear as far as n-reordering is concerned.. Type-P-Reordered is either TRUE or FALSE and if n-reordered packets are a subset of TYPE-P-Reordered then it implies that the metric is not considering all out-of-order packets as reordered. Is n-reordering metric not able to capture reordering completely, as far as the definition of Type-P-Reordered goes? In other words, Type-P-Reordered =TRUE corresponds to reordered packets. What does it mean to say that a subset of these packets are considered by a reorder metric to measure reordering? Are there two different definitions to classify a packet as reordered in this draft? Comments are appreciated. Thanks, Nischal ****************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) Department of Electrical and Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: +1 970-491-7067/7974 Fax: +1 970-491-2249 CNRL: http://www.engr.colostate.edu/ece/Research/cnrl Home: http://lamar.colostate.edu/~nischal ****************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Oct 18 08:26:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11084 for ; Mon, 18 Oct 2004 08:26:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWUz-0000hB-Al; Mon, 18 Oct 2004 08:20:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWUF-0000a6-5H for ippm@megatron.ietf.org; Mon, 18 Oct 2004 08:19:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10550 for ; Mon, 18 Oct 2004 08:19:38 -0400 (EDT) Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJWgD-0007DM-HK for ippm@ietf.org; Mon, 18 Oct 2004 08:32:02 -0400 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i9ICHKfX002376 for ; Mon, 18 Oct 2004 07:19:05 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh2i.attrh.att.com (7.1.006) id 417298600000FA3E; Mon, 18 Oct 2004 08:19:05 -0400 Received: from acmortonw.att.com (acmortonw.mt.att.com [135.16.251.14]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i9ICJ3Z08370; Mon, 18 Oct 2004 08:19:03 -0400 (EDT) Message-Id: <6.0.3.0.0.20041018075405.02d90740@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 18 Oct 2004 08:18:33 -0400 To: Nischal Piratla , ippm@ietf.org From: Al Morton Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt In-Reply-To: <41736F29.30709@engr.colostate.edu> References: <417332CA.9020003@engr.colostate.edu> <6.0.3.0.0.20041018001640.02ff4eb0@custsla.mt.att.com> <41736F29.30709@engr.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 03:22 AM 10/18/2004, Nischal Piratla wrote: >Type-P-Reordered is either TRUE or FALSE and if n-reordered packets are a >subset of TYPE-P-Reordered then it implies that the metric is not >considering all out-of-order packets as reordered. Is n-reordering metric >not able to capture reordering completely, as far as the definition of >Type-P-Reordered goes? The definition of n-reordering does not assign a value of n for all Type-P-Reordered=TRUE packets. So, the short answer is, yes. >In other words, Type-P-Reordered =TRUE corresponds to reordered packets. >What does it mean to say that a subset of these packets are considered by >a reorder metric to measure reordering? Are there two different >definitions to classify a packet as reordered in this draft? n-reordering is a special designation of a reordered packet's position w.r.t. in-order packets, the "n" in n-reordering. n-reordering's relevance to TCP NewReno was considered important enough to include this metric. Several folks have found it useful. hth, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Oct 18 15:25:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15836 for ; Mon, 18 Oct 2004 15:25:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJcWp-0007uB-RS; Mon, 18 Oct 2004 14:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJcQZ-0006FH-J9 for ippm@megatron.ietf.org; Mon, 18 Oct 2004 14:40:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10911 for ; Mon, 18 Oct 2004 14:40:04 -0400 (EDT) Received: from goku.engr.colostate.edu ([129.82.224.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJccP-0006jl-Sb for ippm@ietf.org; Mon, 18 Oct 2004 14:52:32 -0400 Received: from [129.82.228.165] (prolix.engr.colostate.edu [129.82.228.165]) by goku.engr.colostate.edu (8.12.8/8.12.0.Beta7) with ESMTP id i9IIX9a0001130 for ; Mon, 18 Oct 2004 12:33:10 -0600 (MDT) Message-ID: <41740CAD.20306@engr.colostate.edu> Date: Mon, 18 Oct 2004 12:34:21 -0600 From: "Nischal M. Piratla" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt References: <417B8BB7@webmail.colostate.edu> <6.0.3.0.0.20041018084540.02dadd10@custsla.mt.att.com> In-Reply-To: <6.0.3.0.0.20041018084540.02dadd10@custsla.mt.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: nischal@engr.colostate.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Al Morton wrote: > > This draft is in "Last Call", intended for WG members who have been > actively involved in the development to take one last look > before the draft moves on to the next stage of the process. > Since you appear to be reading the draft for the first time, > it might be more appropriate to ask questions off-list with me, > and let the Last Call continue. We can go back on the list > if necessary. > > thanks for your questions and understanding, > Al Al, I assumed that if there are some discrepancies, the ippm members who have not authored the draft can comment too. I did not know that when the draft is in "Last Call", it is intended only for WG members who have been actively involved in the development to take one last look before the draft moves on to the next stage of the process. I apologize for my ignorance. However, I am still concerned for the following reasons: 1) The amount of buffering required to discard duplicate packets in ippm metrics: I did not see any discussion on this forum on orthogonality w.r.t duplication for ippm metrics, except our mention earlier as to ippm metrics not being orthogonal to packet duplication.. "The requirement to ignore duplicate packets also mandates storage. Here, tracking the sequence numbers of missing packets may minimize storage size. Missing packets may eventually be declared lost, or reordered if they arrive. " This statement says that we could track the missing packets. If such a mechanism is not in-built in the metric then how can we come up with computation complexities of the metrics? Henk once sent me a feedback that reads as follows: 1. If I understand the algorithm correctly, then it needs an array in_buffer[N] with N the number of packets in a stream. This is not very practical, when I make a VoIP phonecall, then I never know how long it is going to last in advance and thus how I should dimension this array. 2. Can you include the same examples as in the other reordering metrics so one can compare the algorithms? Henk Same problem as 'point 1' will now exist for ippm metrics. Even if we are tracking lost packets, we could have a multiple bursts of losses, we will need a large buffer size and on top of it, the upper bound could be O(N). We will never know how long it is going to be in advance. 2) In the last meeting that I viewed (thanks to the broadcast facilities), it was clearly mentioned that the Reorder Density draft has a different definition for reordering than ippm metrics. But I see that N-reordering has a different definition for reordering than all other ippm metrics. The concept of subset cannot be accepted. Here, the set has only two types of elements, i.e., for Type-P-Reordered = TRUE and Type-P-Reordered = FALSE. So, a subset of Type-P-Reordered belonging to out of order packets, i.e., only a subset of Type-P-Reordered = TRUE is TRUE and remaining Type-P-Reordered = TRUE is FALSE does not make sense. Also, the definition of out-of-order packets being modified in n-reordering does not meet the fundamental requirement that a reorder metric has to capture reordering. I believe that we MUST meet this requirement first and then we can think of other MUST and SHOULD requirements. There could be useful applications in TCP Reno but then it is a kind of measurement that is useful, however can we really call it a metric for packet reordering? Once Stanislav quoted: Subject: Re: [ippm] New metric for packet reordering. Date: 18 Feb 2003 01:07:27 -0500 From: stanislav shalunov To: Nischal M Piratla CC: ippm@advanced.org References: <3E4D20C4.8070605@engr.colostate.edu> Nischal, It seems that: * When `late' packets are encountered, your metric behaves like N-reordering; * When `early' packets are encountered, your metric reports same degree of reordering as N-reordering, but larger number of packets are reported as reordered; * When there are any missing packets, it reports high degrees of reordering for a whole bunch of packets. This last is a show-stopper as far as I am concerned-- Stanislav Shalunov http://www.internet2.edu/~shalunov/ The n-reordering metric fails to the capture of the amount of reordering. Looking at the second point, on the contrary, n-reordering does not report reordered packets as reordered according to the Type-P-Reordered definition. Though, I do not consider this problem as a show-stopper but I was hoping that we can all follow these useful comments. They were all excellent suggestions at least for us to take Reorder Density metrics to take to the next levels. It is also possible that due to time constraints or whatever reasons, some of us have not read the draft very carefully and now I took the liberty to do so. Thanks & Regards, Nischal Piratla **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7974 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Oct 18 17:26:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24665 for ; Mon, 18 Oct 2004 17:26:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeOP-0008HQ-Ce; Mon, 18 Oct 2004 16:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJe9Y-0005Fz-7x for ippm@megatron.ietf.org; Mon, 18 Oct 2004 16:30:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20444 for ; Mon, 18 Oct 2004 16:30:41 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeLS-0000pP-Fl for ippm@ietf.org; Mon, 18 Oct 2004 16:43:11 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i9IKUZag046231 for ; Mon, 18 Oct 2004 13:30:36 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 44AE877AED0 for ; Mon, 18 Oct 2004 16:30:34 -0400 (EDT) To: ippm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: She Don't Use Jelly MIME-Version: 1.0 Date: Mon, 18 Oct 2004 16:30:34 -0400 Message-Id: <20041018203034.44AE877AED0@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [ippm] reminder: ccr special section on measuring the Internet's vitals X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0907624244==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============0907624244== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Just a reminder (/spam) ... due date is 11/1. allman CALL FOR PAPERS Measuring the Internet's Vital Statistics A Special Issue of ACM SIGCOMM COMPUTER COMMUNICATION REVIEW There are a number of measurements of the Internet's basic properties that are tremendously useful for researchers to know. A solid understanding of key Internet properties is useful for: * creating quality models to evaluate innovative new protocols, algorithms and architectures * understanding the overall context with which a new system will inevitably have to cope if/when deployed * gaining an appreciation for the variety and breadth of situations one may encounter when measuring the Internet Yet, as the Internet has grown, many of these measurements are no longer widely circulated -- often because they are viewed as operational rather than of research interest. Assumptions based on dated information about the operational Internet are used every day by researchers. Unreliable assumptions about the Internet's key properties may lead to everything from wasted time in appreciating the breadth of scenarios one must take into account in measurement analysis to simulation studies that are not of practical import because of the inaccurate models. The goal of this special issue is to begin the practice of periodically publishing measurement studies of the Internet that concisely provide reliable, easily accessible information for researchers to use and build on. Our aim is to complement traditional measurement venues that emphasize new measurement techniques and evaluations of new protocols and architectures, by updating the community's working knowledge of the basic properties. Examples of measurements that would be of interest are: * a breakdown of the types of bad/defective/broken DNS queries received at the typical root server; * how frequently the TCP/UDP checksum and the MAC-layer CRC disagree; * the distribution of traffic among different applications (perhaps, measured at different points in the network); * the ratio of local traffic to global traffic; * how often the forward and return paths of a TCP connection differ; * how often traffic is reordered; * the variation in BGP route prefixes advertised over the course of a typical minute, hour, day, week, and month; * distributions of round-trip times experienced in the network Our expectation is that each paper will be short: a description of the methodology by which the data was captured and where it was gathered, a presentation of results, and where possible, a comparison of the current results with those of prior years (and other researchers). The focus of the papers should be on the data, rather than on developing new methodologies. We encourage authors to collaborate to illustrate information from multiple vantage points in the network. In addition, we especially solicit papers that are coupled to public release of measurement datasets (even if anonymized in some form). Our aim is to initiate a cycle whereby the community constantly updates our collective understanding of the Internet's basic properties. Therefore, following the publication of this special issue, CCR and Sigcomm will endeavor to continuously publish papers on the Internet's basic properties to keep the community's perspective fresh. Please submit papers to the special issue by email to ccr-ivs@lists.csail.mit.edu For further information and submission details please see http://www.acm.org/sigcomm/ccr/ivs Please address questions about content or submission procedure to ccr-ivs@lists.csail.mit.edu Schedule: Submissions due November 1, 2004 Acceptance decisions December 3, 2004 Publication January, 2005 Special Issue Editors Mark Allman, ICIR Craig Partridge, BBN --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBdCfqWyrrWs4yIs4RAsphAJ4+URxkfSMwAnOf/ws9xMKayH/dJwCfWAyo ylilRIFiQ97UBAQx12SRu50= =5sl8 -----END PGP SIGNATURE----- --=-=-=-- --===============0907624244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============0907624244==-- From ippm-bounces@ietf.org Mon Oct 18 23:56:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27454 for ; Mon, 18 Oct 2004 23:56:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJkcK-0002qi-Io; Mon, 18 Oct 2004 23:24:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJkGr-0007wT-T5 for ippm@megatron.ietf.org; Mon, 18 Oct 2004 23:02:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23222 for ; Mon, 18 Oct 2004 23:02:38 -0400 (EDT) Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJkSq-0000yu-Sk for ippm@ietf.org; Mon, 18 Oct 2004 23:15:12 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i9J31w2X020713 for ; Mon, 18 Oct 2004 23:02:05 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh0i.attrh.att.com (7.1.006) id 4160235C00298E55 for ippm@ietf.org; Mon, 18 Oct 2004 23:02:05 -0400 Received: from acmortonw.att.com ([135.210.112.24]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i9J323Z08959 for ; Mon, 18 Oct 2004 23:02:03 -0400 (EDT) Message-Id: <6.0.3.0.0.20041018202111.02db5a50@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 18 Oct 2004 23:01:31 -0400 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt In-Reply-To: <41740CAD.20306@engr.colostate.edu> References: <417B8BB7@webmail.colostate.edu> <6.0.3.0.0.20041018084540.02dadd10@custsla.mt.att.com> <41740CAD.20306@engr.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 02:34 PM 10/18/2004, Nischal M. Piratla wrote: ... >I assumed that if there are some discrepancies, the ippm members who have >not authored the draft can comment too. I did not know that when the draft >is in "Last Call", it is intended only for WG members who have been >actively involved in the development to take one last look before the >draft moves on to the next stage of the process. I apologize for my ignorance. I did not say "only" active members. I simply described the process when it works well, and how it usually works in IPPM WG. You were asking newbie questions that had already been discussed on the list or at meetings, and I answered by quoting from the draft. In my opinion, that sort of exchange should take place before Last Call, so I offered to discuss the draft one-to-one with you (and thanks for sharing my off-list message with everyone). >However, I am still concerned for the following reasons: >1) The amount of buffering required to discard duplicate packets in ippm >metrics: Usually, storing the sequence numbers of missing packets and the the largest sequence number received will be most efficient. If you expect catastrophic loss, then store the numbers of the packets that do arrive, and avoid O(N) that way. Or track both until the storage of one or the other is exhausted. We don't specify implementations, this draft provides definitions. In my day job, I loose interest in reordering if the loss is really high. >I did not see any discussion on this forum on orthogonality w.r.t >duplication for ippm metrics, except our mention earlier as to ippm >metrics not being orthogonal to packet duplication.. This came-up at almost every IPPM meeting for the last 2 years, with the same conclusion. >... >2) In the last meeting that I viewed (thanks to the broadcast facilities), >it was clearly mentioned that the Reorder Density draft has a different >definition for reordering than ippm metrics. >But I see that N-reordering has a different definition for reordering than >all other ippm metrics. You seem to want to equate the designation n-reordering with Type-P-Reordered, but we have stated that Type-P-Reordered is *the* definition of reordered packets in the draft. n-reordering is a special designation of a reordered packet's position w.r.t. in-order packets, and n-reordering only assigns a value of n for some Type-P-Reordered=TRUE packets. I think that if n-reordering were named "n-something_else", this might be more clear, but here we are. In summary, we've discussed both items at some length in IPPM, and reached conclusions that most people seem to be comfortable with. ... >It is also possible that due to time constraints or whatever reasons, some >of us have not read the draft very carefully and now I took the liberty to >do so. OK. I hope this clears-up any misunderstandings. Good luck with your Reordering Density draft. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Oct 21 08:39:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18018 for ; Thu, 21 Oct 2004 08:39:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbLM-0000em-LU; Thu, 21 Oct 2004 07:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUTA-00016U-Se for ippm@megatron.ietf.org; Thu, 21 Oct 2004 00:22:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23265 for ; Thu, 21 Oct 2004 00:22:09 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKUfM-0005eC-P0 for ippm@ietf.org; Thu, 21 Oct 2004 00:35:11 -0400 Received: from h-69-3-26-28.snvacaid.dynamic.covad.net ([69.3.26.28] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CKUSk-00051C-00 for ippm@ietf.org; Wed, 20 Oct 2004 21:22:06 -0700 Message-ID: <00b901c4b725$a11fb820$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <417B8BB7@webmail.colostate.edu><6.0.3.0.0.20041018084540.02dadd10@custsla.mt.att.com><41740CAD.20306@engr.colostate.edu> <6.0.3.0.0.20041018202111.02db5a50@custsla.mt.att.com> Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt Date: Wed, 20 Oct 2004 21:22:51 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi - > From: "Al Morton" > To: > Sent: Monday, October 18, 2004 8:01 PM > Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt ... > >I did not see any discussion on this forum on orthogonality w.r.t > >duplication for ippm metrics, except our mention earlier as to ippm > >metrics not being orthogonal to packet duplication.. > > This came-up at almost every IPPM meeting for the last 2 years, > with the same conclusion. ... > In summary, we've discussed both items at some length in IPPM, > and reached conclusions that most people seem to be comfortable with. ... a comment on this discussion... If the questions keep coming up, and only WG participants are currently able to get through the draft without questions, it would suggest that recording the group's reasoning there might be beneficial. A standard isn't just a memo to be read by the people who helped write it. Randy _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Oct 21 10:00:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00461 for ; Thu, 21 Oct 2004 10:00:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdIf-0001vq-Ms; Thu, 21 Oct 2004 09:48:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdCj-0006VF-0i for ippm@megatron.ietf.org; Thu, 21 Oct 2004 09:42:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28954 for ; Thu, 21 Oct 2004 09:42:06 -0400 (EDT) Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdPJ-0002xl-Ug for ippm@ietf.org; Thu, 21 Oct 2004 09:55:11 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i9LDeW2b011769 for ; Thu, 21 Oct 2004 09:41:32 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh0i.attrh.att.com (7.1.006) id 4160235C0031F48E for ippm@ietf.org; Thu, 21 Oct 2004 09:41:32 -0400 Received: from acmortonw.att.com (acmortonw.mt.att.com [135.16.251.14]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i9LDfVZ10793 for ; Thu, 21 Oct 2004 09:41:31 -0400 (EDT) Message-Id: <6.0.3.0.0.20041021090719.02693260@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 21 Oct 2004 09:41:29 -0400 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt In-Reply-To: <00b901c4b725$a11fb820$7f1afea9@oemcomputer> References: <417B8BB7@webmail.colostate.edu> <6.0.3.0.0.20041018084540.02dadd10@custsla.mt.att.com> <41740CAD.20306@engr.colostate.edu> <6.0.3.0.0.20041018202111.02db5a50@custsla.mt.att.com> <00b901c4b725$a11fb820$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 12:22 AM 10/21/2004, Randy Presuhn wrote: >a comment on this discussion... > >If the questions keep coming up, and only WG participants >are currently able to get through the draft without questions, >it would suggest that recording the group's reasoning there >might be beneficial. A standard isn't just a memo to be read >by the people who helped write it. Agreed. Discussion of duplicates has been documented in the minutes, but not every time. We have added text to the draft based on the discussions (and even put it a forward reference, yuk), but there are limits on how much we can add because this is really an implementation issue. Duplicate packets are also dealt with in several of the existing IPPM RFCs, and what we've done in the reordering metric is consistent with precedent. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Oct 22 18:17:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01873 for ; Fri, 22 Oct 2004 18:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6uH-0006Jc-Te; Fri, 22 Oct 2004 17:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6BW-0001iB-S0; Fri, 22 Oct 2004 16:38:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11046; Fri, 22 Oct 2004 16:38:46 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6OL-0007J0-Ht; Fri, 22 Oct 2004 16:52:06 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8238D1CD559; Fri, 22 Oct 2004 16:38:42 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15104-04; Fri, 22 Oct 2004 16:38:42 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 5FB7D1CD4EC; Fri, 22 Oct 2004 16:38:42 -0400 (EDT) To: Internet-Drafts Administrator From: stanislav shalunov Date: 22 Oct 2004 16:39:01 -0400 Message-ID: <86r7nq1o9m.fsf@abel.internet2.edu> Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 1.2 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Samuel Weiler , IETF IPPM WG Subject: [ippm] draft-ietf-ippm-owdp-11.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Dear Internet-Drafts Administrator, Please publish http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-11.txt (SHA1 = 6bca91ebb1998f3a3bf292e4bcbf74d8d0e92eb5) as an internet-draft. Thank you. Changes: * Multiple minor editorial changes throughout the document. * New section (3.2. Values of the Accept Field) defines computer-readable failure codes. * Fetch-Session results changed to include a list of ranges of sequence numbers that were skipped by the sender due to internal scheduling delays. * The special-case value of 0xFFFFFFFF (unknown) for the number of packets sent in a session is no longer valid. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBQXlv25RUn1EgN49xAQHyIAP/Y5DY03OLrpR2n0PsdO6ZP27VwsUysk8e FtnVU+BmbLb7zARtg9Wp+LF3Pl/B7J9wKrdFUwocoyHByXxJyFe6S1eYQOt8L+bv Y7bMEOGDIC9ZXEVCKqrBhB3sF4+vIs+rLovJe5iBDf4IVCQe8ClQpactiZT/0rUb fT+po+3sp00= =VdkK -----END PGP SIGNATURE----- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Oct 28 13:40:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28865 for ; Thu, 28 Oct 2004 13:40:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCk4-000288-PV; Thu, 28 Oct 2004 12:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBj8-0005BI-NV; Thu, 28 Oct 2004 10:58:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20984; Thu, 28 Oct 2004 10:58:09 -0400 (EDT) Message-Id: <200410281458.KAA20984@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 10:58:09 -0400 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-owdp-11.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --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 (OWAMP) Author(s) : S. Shalunov, et al. Filename : draft-ietf-ippm-owdp-11.txt Pages : 49 Date : 2004-10-27 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. The One-Way Active Measurement Protocol (OWAMP) 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-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-11.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-11.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: <2004-10-28110044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-owdp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-owdp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110044.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --NextPart-- From ippm-bounces@ietf.org Fri Oct 29 04:02:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05210 for ; Fri, 29 Oct 2004 04:02:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRM4-00036p-Jy; Fri, 29 Oct 2004 03:39:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNR5x-0002Xt-ML for ippm@megatron.ietf.org; Fri, 29 Oct 2004 03:22:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02025 for ; Fri, 29 Oct 2004 03:22:42 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRKA-0007RY-3Q for ippm@ietf.org; Fri, 29 Oct 2004 03:37:27 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id E8B0655DEC; Fri, 29 Oct 2004 09:22:09 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D58B455DED for ; Fri, 29 Oct 2004 09:22:08 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i9T7M8x1024114 for ; Fri, 29 Oct 2004 09:22:08 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i9T7M8U5028255 for ; Fri, 29 Oct 2004 09:22:08 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Fri, 29 Oct 2004 09:22:08 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: ippm@ietf.org In-Reply-To: <200410272213.SAA21433@ietf.org> Message-ID: References: <200410272213.SAA21433@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: 06d071bc5c0cb71664e718d391d7ad36 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [ippm] IPPM WG meeting @ 61st IETF X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear All, The IPPM WG will meet in DC on > TUESDAY, November 9, 2004 > 0900-1130 Morning Sessions > TSV ippm IP Performance Metrics WG If you have any topics for dicussion, please drop me a mail, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Oct 29 23:24:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08599 for ; Fri, 29 Oct 2004 23:24:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNjmi-0005Yq-Jc; Fri, 29 Oct 2004 23:20:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNjSG-0005pf-73 for ippm@megatron.ietf.org; Fri, 29 Oct 2004 22:59:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06868 for ; Fri, 29 Oct 2004 22:58:57 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNjgf-0000Lz-0e for ippm@ietf.org; Fri, 29 Oct 2004 23:13:53 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i9U2wZ9l023412; Fri, 29 Oct 2004 19:58:38 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 40AAA77AF8B; Fri, 29 Oct 2004 22:58:33 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1B8501F4F91; Fri, 29 Oct 2004 22:58:34 -0400 (EDT) To: "Henk Uijterwaal (RIPE NCC)" From: Mark Allman Subject: Re: [ippm] WGLC on draft-ietf-ippm-reordering-07.txt In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: 57 Channels MIME-Version: 1.0 Date: Fri, 29 Oct 2004 22:58:33 -0400 Message-Id: <20041030025834.1B8501F4F91@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: ippm@ietf.org, Matthew J Zekauskas , acmorton@att.com X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1725894137==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1725894137== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Folks- Reading this document for the first time in a long time. Alas, early review is better than later review. But, review is better than no review. I don't think this document is yet ready for PS. My comments: * In the first sentence of section 2 you note that "ordered delivery is a property of successful packet transfer". Later you note that "packet order is not expected to change during transfer". I disagree with the first statement and mostly with the spirit in which the second is made. I think this document should specifically note that, in fact, packet reordering is explicitly tolerated by Internet protocols. That is, there is actually no expectation of order. One might argue that there is an expectation of reasonable ordering -- i.e., that packets should not be delayed by minutes, say. But, I think the document really needs to note that reordering is not something "unexpected" in the network. Of course, applications will have more or less ability to cope with reordering, depending on their requirements. But, that is a bit different from this being considered an anomalous event. * Section 2.2 is troubling. First, the bullet with that says a reordering metric MUST "have one or more relevant applications, such as receiver design or network characterization". Isn't this largely a content-free requirement? Damn near anything can be considered "network characterization", right? I just think that this requirement either needs reworded (maybe I am just not Getting It) or just dropped --- because it really adds nothing as it currently sits, IMO. Second, the document notes that reordering metrics MUST "work with Poisson and Periodic test streams". However, one of your "desirable" items will never be met... "have relevance to TCP performance". TCP's sending pattern is neither Poisson nor Periodic and it is not clear to me whether any of your metrics have any relevance to TCP. (More below.) * In section 3 ... I am just confused. First, I'd note that sequence numbers must be unique and increasing (modulo the discussion on wrap, later in the document, of course). The part about being unique should be stated for the time-based scheme whereby the period of the stream could well be faster than some clock tick (i.e., one could be using two different clocks or gross granularity in the packets and finer granularity in the scheduling or whatever). But, let me not get ahead of myself here. I think this whole document could be simplified by using only message numbers in the test stream. In particular, using a timestamp is a thorny notion. How is the receiver supposed to have a good handle on what to expect next? There are tons of things that could mess up that notion (NTP could change the time on the sender, the sender could be busy and a transmission could be delayed a tad, etc., etc.). And, while I can see how the receiver could make a guess at the expected time in a Periodic stream, I have no idea how that works in a Poisson stream. Byte counts are just needless complexity for this section, too it would seem. The test stream contains packets of a given size, right? If so, then the byte counts can easily be calculated from the packet counts in the metrics where we need byte counts (and, those metrics are fine - good even) and we can just use packet counts here to simplify things. I think that it's fine to include a timestamp and include or derive a byte count. But, for the sake of simplicity it seems like requiring a packet count and using that as the key determiner of out-of-orderness is the way to go. If not, then I think a whole lot more discussion of the pitfalls of these other schemes is required to give people a solid understanding of the implications of their choices. * Section 4.4 There are these extrapolations that the document calls for that kind of bug me. This is one case. From what I can tell, the packet streams being called for here are of uniform packet sizes. But, in this section you try to use the byte counts to determine a buffer size in terms of bytes, which may be useful to an application that sends varying sized packets (this is stated in the document). Finding the buffering requirement is a useful thing to want to do. However, there is not even the mention that the test stream could potentially be a poor predictor of the reordering (and therefore the buffer size) required by some application with different sized segments. We have some early results that suggest small segments fall victim to reordering more often than large segments, for instance. I think a note is in order to that effect here. I think this document needs a very careful pass to add such notes anywhere where it advocates for extrapolating something from the measurements that is not actually being measured. Inferring is a tricky game. It's hard to get right and easy to get wrong. * Section 5 Similar to the above, this section is just trying to reach too far, I think. But, this one is even worse. I think section 5 is largely just bogus. There is a caveat in this section: We note that the definition of n-reordering cannot predict the exact number of packets unnecessarily retransmitted by a TCP sender under some circumstances, such as cases with closely-spaced reordered singletons. The definition is less complicated than a TCP implementation where both time and position influence the sender's behavior. But, this doesn't even get to the heart of the matter. The real issue here is that using Periodic or Poisson sending patterns in no way matches or even approximates TCP's sending pattern. And, so n-reordering cannot predict the number of retransmissions because it is not observing the same kinds of reordering phenomena that a TCP stream would. This is another example of trying to infer too much. If this definition were for a stream of packets sent using some BTC tool, then OK. Now, I'd buy it. And, I understand that this document does not preclude doing that. However, it also doesn't suggest it -- or, better yet, require it. In fact, quite the opposite the draft indicates that it is fine to use this metric with Periodic or Poisson because all metrics must "work" with those two stream types. * Section 6 It is not clear to me why (in a test stream) there would be "retransmits". The document notes that one must take care to disambiguate original transmissions and retransmissions. But, why would there be such complexity in a test stream? At the risk of being redundant here, this section discusses TCP advertised window provisioning and discusses segments that are "sufficiently beyond" the window and etc. This again shows the discrepancy with TCP. Unless something is pretty broken, TCP does not send segments beyond the advertised window. So, projecting anything that happens in the great beyond is pretty thorny it seems to me. I am happy to iterate on any/all of the above to clarify or flesh out or whatever. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBgwNZWyrrWs4yIs4RAiIeAJ44W2iWUHQG792VbmuvCZ3oPZnM7ACgjDhY UvOZkncwnfGIbmQeqx5jy58= =TCD9 -----END PGP SIGNATURE----- --=-=-=-- --===============1725894137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1725894137==-- From ippm-bounces@ietf.org Sat Oct 30 13:10:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05445 for ; Sat, 30 Oct 2004 13:10:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNwb5-00043X-SC; Sat, 30 Oct 2004 13:00:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNwUv-000250-Te for ippm@megatron.ietf.org; Sat, 30 Oct 2004 12:54:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04757 for ; Sat, 30 Oct 2004 12:54:34 -0400 (EDT) Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNwjS-0005kL-EN for ippm@ietf.org; Sat, 30 Oct 2004 13:09:38 -0400 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i9UGs56Q023311 for ; Sat, 30 Oct 2004 12:54:06 -0400 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (7.1.006) id 417BD2DE00172E0F; Sat, 30 Oct 2004 12:54:05 -0400 Received: from acmortonw.att.com ([135.210.16.7]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i9UGs3Z17121; Sat, 30 Oct 2004 12:54:03 -0400 (EDT) Message-Id: <6.0.3.0.0.20041030123553.02911c40@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Sat, 30 Oct 2004 12:53:50 -0400 To: mallman@icir.org, "Henk Uijterwaal (RIPE NCC)" From: Al Morton Subject: Re: [ippm] WGLC on draft-ietf-ippm-reordering-07.txt In-Reply-To: <20041030025834.1B8501F4F91@lawyers.icir.org> References: <20041030025834.1B8501F4F91@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Matthew J Zekauskas , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Mark, Thanks for your careful review. At 10:58 PM 10/29/2004, Mark Allman wrote: >Reading this document for the first time in a long time. Alas, early >review is better than later review. But, review is better than no >review. Agreed. Almost all of your comments have the virtue of being "new", so the memo will be improved when we're done. Worth the trip. >... ... >I am happy to iterate on any/all of the above to clarify or flesh out or >whatever. Great, your comments seem clear to me. I'll start working through by sections or topics, which ever makes the most sense, and hopefully we'll have most resolutions agreed by next week. thanks again, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm