Reordering Metrics papers

From ippm-bounces@ietf.org Thu Dec 01 09:14:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpCZ-0007ZA-O5; Thu, 01 Dec 2005 09:14:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpCY-0007Yu-8U for ippm@megatron.ietf.org; Thu, 01 Dec 2005 09:14:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25090 for ; Thu, 1 Dec 2005 09:13:34 -0500 (EST) Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpX0-00070r-7i for ippm@ietf.org; Thu, 01 Dec 2005 09:35:33 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp12.clb.oleane.net with ESMTP id jB1EDws1026514 for ; Thu, 1 Dec 2005 15:14:03 +0100 Message-Id: <200512011414.jB1EDws1026514@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 1 Dec 2005 15:13:25 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX2gWTQS5xTbIeISyOfxfV3/DUeyg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Subject: [ippm] Wireless/WiFi Convergence Conference - Call for Papers 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="===============1249277319==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============1249277319== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0155_01C5F689.C9563630" This is a multi-part message in MIME format. ------=_NextPart_000_0155_01C5F689.C9563630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Wireless/WiFi Convergence Conference will be held in Paris on May 16 to May 19, 2006 http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006cfp.htm It is still time to submit proposals. Organizers are looking for UMA papers. ------=_NextPart_000_0155_01C5F689.C9563630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Wireless/WiFi Convergence = Conference will be held in Paris on May 16 to May 19, 2006

http://www.upperside.fr/wirelessconvergence2006/wwconvergence200= 6cfp.htm

It is still time to submit proposals. = Organizers are looking for UMA papers.

------=_NextPart_000_0155_01C5F689.C9563630-- --===============1249277319== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1249277319==-- From ippm-bounces@ietf.org Fri Dec 09 09:27:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkjDO-0004MG-Sc; Fri, 09 Dec 2005 09:27:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkcAO-0000rP-D9 for ippm@megatron.ietf.org; Fri, 09 Dec 2005 01:55:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19696 for ; Fri, 9 Dec 2005 01:54:45 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkcAW-0007Br-Bi for ippm@ietf.org; Fri, 09 Dec 2005 01:55:49 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8E7EA1CD583; Fri, 9 Dec 2005 01:55:38 -0500 (EST) 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 03528-01; Fri, 9 Dec 2005 01:55:38 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D12441CD4EE; Fri, 9 Dec 2005 01:55:37 -0500 (EST) Date: Fri, 09 Dec 2005 01:55:34 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Message-ID: <7CA138910641C007BBD83ECA@DCFF15AFC1F6764BA3927E50> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========684199BF2E618F0DA131==========" X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c X-Mailman-Approved-At: Fri, 09 Dec 2005 09:27:12 -0500 Cc: Henk Uijterwaal , Matt Zekauskas , Jon Peterson , Allison Mankin Subject: [ippm] Draft minutes from IPPM at IETF64 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 --==========684199BF2E618F0DA131========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Draft minutes from the IPPM meeting at IETF64 are attached. These minutes and the presentations are all on the IETF64 meeting materials site: If anyone has any comments, please send them to either the list or directly to the chairs. --Matt --==========684199BF2E618F0DA131========== Content-Type: text/plain; charset=us-ascii; name="ippm-minutes-00.txt" Content-Disposition: attachment; filename="ippm-minutes-00.txt"; size=14003 Content-Transfer-Encoding: 7bit IP Performance Metrics WG (ippm) Monday, November 7, 2005 - 09:00--11:30 ======================================= The meeting was chaired by Henk Uijterwaal and Matt Zekauskas. Benoit Claise and Al Morton took notes, which were edited into these minutes by the chairs. AGENDA: 1. Administrivia: Agenda, Status of Drafts and Milestones 2. Temporal Aggregation (and Composition Framework) draft-svdberg-ippm-temporal-00.txt 3. Spatial Composition Draft and an overall Framework Proposal draft-morton-ippm-composition-00.txt 4. Spatial and Multicast Metrics draft-stephan-ippm-multimetrics-02.txt 5. Jitter Definitions discussion 6. Traceroute Metrics and Data Model draft-niccolini-ippm-storetraceroutes-02.txt 7. TWAMP Draft draft-ippm-two-way-active-measurement-protocol-00.txt 8. Recent ITU Liaison statements Loki Jorgenson was unable to attend, thus he did not present his opinions on the ITU's IP Performance documents (specifically, Y.1541). 1. Administrivia: Agenda, Status of Drafts and Milestones --Henk Uijterwaal for both chairs Henk opened the meeting with the usual working group information boilerplate. He then talked about the state of the existing drafts, in particular, that OWAMP has been stuck in a security review (we're going to talk with Russ Housley; unfortunately, Stanislav Shalunov couldn't make the Vancouver meeting); and also we're going to need advice from the ADs as to what (if anything) to do with the implementation reports we've gathered for the extant IPPM metrics. Henk did another revision of the implementation report, taking comments into account. There is work going on in the background on the capacity draft, but there is no report today. [After the meeting Russ and Stanislav had a productive email email exchange solving most of the issues; Stanislav is to work on the last two after the conference he is attending is over. Henk also sent out email on the implementation reports after the meeting.] Henk then discussed the state of the reordering drafts. There are two drafts, a group draft and a individual submission from a group at Colorado State University. The latter has been presented but hasn't drawn much interest from the working group. The group draft has been reviewed seriously by a number of people, and it has been stable for about a year. He also discussed the claim from the CSU group that the byte-offset definition in the WG draft is derived from reorder-buffer-density. Henk noted that both he and Matt had reviewed this claim and found that the editor was reflecting consensus from the working group. It appears that the two efforts appeared to be working in parallel towards the same idea from different directions. Also, the ideas had been publicly discussed at IPPM meetings and elsewhere, and that therefore it did not appear that byte-offset was directly derived from reorder-buffer-density (and in any case it is hard to analyze years after the fact). Henk proposed that a stable reference to the Colorado work be added to the draft discussing reordering approaches, that we ensure there is an acknowledgement to the individuals that participated in meetings and email discussions (we believe this exists already), and that we will go to WGLC on the group's draft. Unless the reorder buffer density draft gets any outside support we will not pursue making the Colorado draft a working group document. This decision will be posted to the mailing list shortly. Those present in the room agreed with this approach. The dates on the milestones are being revised. Authors should give Henk good estimates for their milestones. 2. Temporal Aggregation (and Composition Framework) --Steven Van den Berghe Steven Van den Berghe (who has been doing some work for GEANT2's JRA1 group) presented a short draft on thoughts on a unified framework for thinking about temporal and spatial composition of IPPM metrics, and then some examples of temporal aggregation, and concerns that need to be addressed. One example of temporal aggregation is taking a measurement every five seconds, and then creating a meaningful summary of an hour. [See slides.] Kaynam Hedayat asked if Steven had thought about jitter. Steven says that they had, and have some ideas, but haven't worked them out. Another participant asked about how precedence, or treatment of packets would fit in. The underlying measurements take that into account, as part of Type-P. You can say something about one forwarding behavior directly; aggregating packets with different forwarding behaviors would take more work, and may not be possible. Emile Stephan asked about error propagation, and what error should be reported. Steven said that error propagation needs to be worked out as well. Matt asked the group if they thought this would be useful; there were a few (4-5) nodding heads, including some new participants. Matt stated that personally, he felt the useful work was the work that wasn't completed -- error propagation, jitter propagation, considering values that are not averages. 3. Spatial Composition Draft and an overall Framework Proposal -- Al Morton Al Morton presented spatial composition, and a more formal proposal for a framework for composition (that included discussion with Steven). This draft's example just talks about composition of finite one-way delays. The framework is such that you could also include the multimetrics draft as a different approach within the framework. [See slides.] Al would like comment on the overall framework, and then the individual drafts. Roman Krzanowski stated that from his perspective the composition and decomposition of metrics has been on his mind for a while, and that providers have no guidance, and he thought we should work on drafts like this to get some consensus. 4. Spatial and Multicast Metrics -- Emile Stephan Emile Stephan then gave an update on the multimetrics draft. This is looking at measurements that are taken on the same stream at multiple points. The latest version adds a new metric that more clearly defines a two point one way delay -- one where you passively measure (possibly a synthetic stream) at two points. He also discussed where this draft fit with the other two, and in a general composition framework. He was looking for feedback as to whether a purely passive metric was the right approach, compared to something like an applicability statement for the current one-way delay metric. [See slides.] The result of the discussion on these three drafts (Van den Berghe, Morton, Stefan) is that there will be four drafts: A framework draft with common text, and the three discussing temporal, spatial, and multi-point composition. 5. Jitter Definitions discussion --Roman Krzanowski Roman Krzanowski then presented a problem he saw working on an MIT study of metrics used by multiple operators, both in the US and abroad. [See slides.] The basic issue was with jitter, and that US operators tend to use inter-packet delay variation, where the European operators tend to use delay variation from a single reference point. The issue is not one of definition -- the IPPM IPDV metric can capture either, but one of "best practice" or recommendations. He is going to see if there is enough interest (among US and European operators) generate an applicability statement -- especially with respect to sharing measurement results. Matt said that we'd like to see some interest, and if so set a deadline to see progress or declare failure since previous efforts to get providers to agree on sharing results had not been fruitful within the IETF. Roman said he would summarize the discussion, send it to the group, and a few select people working for service providers, and see if we can generate some enthusiasm. 6. Traceroute Metrics and Data Model --Martin Stiemerling Martin Stiemerling presented the individual traceroute metric and data model draft. They have been talking to folks in the GGF Network Measurement Working Group. This draft shows a complete traceroute schema in XML, and an alternative one based on the GGF work, and a preliminary sketch of how to combine approaches. Issues to be resolved include (1) seeing if the GGF intends to create a standard (2) see if a merged approach with the GGF structure and IETF information model makes sense (3) if a merged effort succeeds, should the work be published in the IETF, the GGF, or both? There is a naming issue - the GGF has it's own way of naming things, this draft tries to use existing DISMAN names; a common namespace is desirable. The authors were going to compare the GGF document series with the IETF one to see if the GGF is even a possible alternative, but the authors strongly prefer something that uses IETF naming. There were about 10 bobbing heads when asked if people thought this was important; it seems clear that the work would be welcome, the question is if anything should be done within IPPM. 7. TWAMP Draft [no slides] --Keynam Heyadat Next, Keynam Heyadat presented the TWAMP draft, and current status. There have been some changes based on implementation experience, mainly relating to time stamps, and some text cleanup. The timestamps and sequence numbers are now in fixed locations so that a hardware implementation is possible. There was also a correction to the draft; TWAMP packets fit in ATM cells only in unauthenticated mode. Henk wanted to make sure the authors are aware of the OWAMP security considerations so that TWAMP does not run into the same issues (TWAMP is based on OWAMP). Keynam stated that he knows of four implementations that are underway; three of which are substantially done. He feels that after there is some interoperability experience with them, the draft may be close to being done. He thought doing a report on implementation experience would be a good idea. 8. Recent ITU Liaison statements --Al Morton Finally Al pointed out the recent Liaison Statements from the ITU to the group. He showed how to find them, and gave a synopsis of what they were. Start at the IETF home page, select liaison activities, and then liaison statements. The two of interest were one to NSIS, which includes Y1541 (so we can get it "for free") and the most recent one which talks about a potential project, G.chirp, which uses packet chirps to characterize available bandwidth (and eventually the download time for web pages). It's an experimental thing, but a stable draft is expected about January of 2007. People should look at them, and let the group know if they have any comments. SG12 doesn't meet until June of next year, so there is plenty of time to comment. The NSIS statement: 'Communication of Recommendation Y.1541, "Network Performance Objectives for IP-based Services"', September 2005. >From ITU-T Study Group 12, Question 17 to NSIS. https://datatracker.ietf.org/documents/LIAISON/file183.doc "Question 17/12 has been following the development of the Next Steps In Signalling (NSIS) framework, requirements and protocols, and notes with particular interest the work on QSpec Templates and QoS Models. We understand your desire to reference Recommendation Y.1541 (published 05/02), and so communicate it to you such that a copy can be referenced and accessed by the IETF community in a persistent way." NSIS is working on signalling protocols that could communicate requests for QOS, beyond IP stuff in Y.1541: bandwidth, priority, etc. This liaison is sent to them, so that they would have a persistent URL in order to access the recommendation easily for all members of the IETF. There are two copies available in the liaison. There is a version that shows some revisions recently added; classes with additional performance objectives, for high bandwidth and high sensitivity to loss applications, such as "big TCPs", and emulation of TDM services over IP networks. A third kind of thing that these classes support is transport of IPTV. The G.chirp statement: "Liaison statement on the Development of New Recommendation on measuring file download and session time", November 2005. >From ITU-T SG12, Questions 13 and 17, to IPPM. https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=148 "Q.13/12 would like to inform IETF IPPM Working Group that we have started developing a new Recommendation G.chirp, which provides a means for measuring file download and session time in a simplified way. The technical content can be found in the attached document (COM12-C11). We expect to produce a stable draft in January 2007. It is very much appreciated if your group gives any suggestions or comments on this topic." G.chirp is active sending sequence which intends to characterize available bandwidth, and eventually file download time. It is an experimental thing that was proposed by TNO of The Netherlands. The method is described in the contribution. It sends packets in closer spacing using an algorithm for spacing, and attempts to assess the download times from that. A formal reply could be prepared back to SG 12 and the questions. If folks would like to try out, TNO probably has some intellectual property covering it. However, trying it out experimentally and publishing results would probably be reasonable. The most powerful way to communicate back to the ITU is via additional liaison statements. If the group looks and thinks it is great idea, or bad idea, it is best if a response comes back formally. However, given that certain people participate in both the IETF and ITU, any response is useful, even if it is informal. The meeting was then closed. --==========684199BF2E618F0DA131========== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --==========684199BF2E618F0DA131==========-- From ippm-bounces@ietf.org Fri Dec 09 09:30:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkjG5-0005xO-JV; Fri, 09 Dec 2005 09:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVyt-0000n3-L9 for ippm@megatron.ietf.org; Thu, 08 Dec 2005 19:19:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11044 for ; Thu, 8 Dec 2005 19:18:18 -0500 (EST) Received: from chico.itss.auckland.ac.nz ([130.216.190.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkVym-0003GM-O4 for ippm@ietf.org; Thu, 08 Dec 2005 19:19:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 5340934C2A for ; Fri, 9 Dec 2005 13:18:55 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06109-22 for ; Fri, 9 Dec 2005 13:18:55 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 35D4B34C25 for ; Fri, 9 Dec 2005 13:18:55 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id jB90Itu24398 for ippm@ietf.org; Fri, 9 Dec 2005 13:18:55 +1300 Received: from nevil-laptop.cs.auckland.ac.nz (nevil-laptop.cs.auckland.ac.nz [130.216.38.130]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Fri, 9 Dec 2005 13:18:54 +1300 Message-ID: <1134087534.a78591583b8d0@webmail.auckland.ac.nz> Date: Fri, 9 Dec 2005 13:18:54 +1300 From: Nevil Brownlee To: ippm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.38.130 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Dec 2005 09:29:59 -0500 Cc: Subject: [ippm] E2MON Call for Papers (reminder) 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 all: The e2emon Workshop will be held in Vancouver early in April 2006; if you haven't seen it already, e2emon's CFP is available at http://www.mnlab.cs.depaul.edu/events/e2emon06/cfp.htm The submission deadline (1 Jan 06) is getting closer, but there's still time! Cheers, Nevil PS: Apologies to those who recieve multiple copies of this note. ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Dec 09 10:56:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekkby-0000FL-JP; Fri, 09 Dec 2005 10:56:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekkbs-0000B0-PA for ippm@megatron.ietf.org; Fri, 09 Dec 2005 10:56:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22571 for ; Fri, 9 Dec 2005 10:55:34 -0500 (EST) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ekkbt-0000QM-LW for ippm@ietf.org; Fri, 09 Dec 2005 10:56:41 -0500 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1134143772!10394803!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 19275 invoked from network); 9 Dec 2005 15:56:13 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-10.tower-120.messagelabs.com with SMTP; 9 Dec 2005 15:56:13 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20051209155612gw100lgg7ge>; Fri, 9 Dec 2005 15:56:12 +0000 Message-Id: <6.2.1.2.0.20051209104339.040b6840@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 09 Dec 2005 10:56:12 -0500 To: Lei Liang , Spiros Spirou From: Al Morton Subject: Re: [ippm] Type-P-Reordered Dst param In-Reply-To: <1132317926.15191.41.camel@ccsrlt115.ee.surrey.ac.uk> References: <004b01c5eab7$eb485cb0$bd2c7c92@intranet.gr> <6.2.3.4.2.20051116150915.02c404c0@localhost> <6.2.1.2.0.20051116135531.03f019a0@postoffice.maillennium.att.com> <010d01c5ec3e$8d168d00$bd2c7c92@intranet.gr> <1132317926.15191.41.camel@ccsrlt115.ee.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Henk Uijterwaal , 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 At 07:45 AM 11/18/2005, Lei Liang wrote: >... The solution is actually simple as we put in the multimetrics draft >by specifying both multicast group address and the address of the >measurement point. In that case, please see the comments in line. > > >On Fri, 2005-11-18 at 13:49 +0100, Spiros Spirou wrote: >... > > Al wrote: > > > In the Reordering draft, section 2.3 > > > "Required Context for All Reordering Metrics" gives the opportunity > > > to report any and all relevant information under the > > > "Packet of Type-P" category (including transport addresses). > > > > I would prefer not to abuse the elasticity provided by section 2.3 because > > it might undermine the draft's intention, which, in my mind at least, is to > > define a common "language" for reporting reordering. IMHO, multicast > traffic > > is not that uncommon to be handled by the "extension mechanism" of the > > draft. > > >I don't know that the metrics of reordering should actually report >whether unicast of multicast coz the operation will not be affected by >any transport mechanism. But I'd leave this question to Al. I think it's fair to say that evaluation of reordering at any one of multiple destinations (e.g., in a multicast group) would follow the same methods we've described in draft-ippm-reordering. I'd prefer to deal with the multicast case explicitly in the multi-party metrics draft, where we describe the problem space much more completely. In the mean time, the Context section 2.3 can suffice until the multiparty metrics draft is done. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Dec 13 18:50:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJuk-0004ze-Eq; Tue, 13 Dec 2005 18:50:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJuH-0004r0-F1; Tue, 13 Dec 2005 18:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15396; Tue, 13 Dec 2005 18:49:06 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmJvK-0007pd-VK; Tue, 13 Dec 2005 18:51:11 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EmJuE-0003Zt-7v; Tue, 13 Dec 2005 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Dec 2005 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-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 : Packet Reordering Metric for IPPM Author(s) : A. Morton, et al. Filename : draft-ietf-ippm-reordering-11.txt Pages : 38 Date : 2005-12-13 This memo defines metrics to evaluate if a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessing reordering affects on TCP. Several examples of evaluation using the various sample metrics are included. An Appendix gives extended definitions for evaluating order with packet fragmentation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-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-reordering-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-reordering-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: <2005-12-13161555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-13161555.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --NextPart-- From ippm-bounces@ietf.org Mon Dec 19 14:57:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoR83-0005Xl-Ug; Mon, 19 Dec 2005 14:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em8D6-0006sz-HS for ippm@megatron.ietf.org; Tue, 13 Dec 2005 06:21:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07836 for ; Tue, 13 Dec 2005 06:19:36 -0500 (EST) Received: from mail.av.it.pt ([193.136.92.53] helo=av.it.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em8Dp-0003XV-JX for ippm@ietf.org; Tue, 13 Dec 2005 06:21:35 -0500 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.av.it.pt X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MSGID_FROM_MTA_ID autolearn=no version=3.1.0 X-TFF-CGPSA-Version: 1.4 X-TFF-CGPSA-Filter: Scanned Received: from [193.136.93.123] (HELO acer3f05b2af82) by av.it.pt (CommuniGate Pro SMTP 4.3.7) with ESMTP id 3703982; Tue, 13 Dec 2005 11:18:43 +0000 From: =?iso-8859-1?Q?H=E9lder_Veiga?= To: , , , "'Henk Uijterwaal $RIPE NCC$'" , , , , , "'Patrik Arlos'" , "'Geraldine Texier'" , "'Dario Rossi'" , "'Marco Mellia'" , "'Thomas Pfeiffenberger'" , "'Felix Strohmeier'" , , , "'Pin Hu'" , "'Zhan Xiaoying'" , "'Dunn, Jeffrey'" , "'Martin, Cynthia'" Date: Tue, 13 Dec 2005 11:20:05 -0000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXsYdTseoXGvfuUTHGuXXI9r2M2xgCKxF2wAA+pBMAAUuVksAPT1iFwABsnGpAAAJo1MA== Message-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 X-Mailman-Approved-At: Mon, 19 Dec 2005 14:57:02 -0500 Cc: nogueira , jolival@av.it.pt, Paulo Salvador , Rui Valadas , jlo@det.ua.pt, =?iso-8859-1?Q?'Jo=E3o_Silva'?= Subject: [ippm] J-OWAMP, new version and site 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="===============0879783814==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============0879783814== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C5FFD7.2B1A69D0" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C5FFD7.2B1A69D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please accept our apologies if you receive multiple copies of this announcement. -------------------------------------------------------------------------= --- ---------------------------------------- =20 Dear all, =20 This is to announce that we have completed the third phase of = development of a Java implementation of OWAMP. We added two new versions (1.2 and 2.1 = ) of our implementation to the J-OWAMP web site. The current version of = J-OWAMP (version 2.1 ) implements the December 2004 draft proposal of OWAMP ( http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-14.txt). = The previous versions of J-OWAMP (versions 1.0 and 1.2) implement the May = 2004 draft proposal of OWAMP ( http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-08.txt). =20 =20 On the new versions: * J-OWAMP includes a NTP client which can be used to get the time reference directly from a NTP server, without the requirement of a synchronized clock on the machine hosting J-OWAMP; * The user can choose the local IP address to bind to. This address can be used on a multi-homed host for an OWAMP element that will only = accept connection requests to one of its addresses. If not defined, it will by default accept connections on any/all local addresses; * some others improvements were made. You can find more information on this platform in http://www.av.it.pt/jowamp. =20 Any comments are welcome. =20 Best regards. =20 H=E9lder Veiga Rui Valadas Jos=E9 Lu=EDs Oliveira Paulo Salvador Ant=F3nio Nogueira Jo=E3o Silva ------=_NextPart_000_0007_01C5FFD7.2B1A69D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please accept our apologies if you receive multiple = copies of this announcement.

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

Dear all,

This is to announce that we have completed = the third phase of development of a Java implementation of OWAMP. We added two new = versions (1.2 and 2.1 ) of our implementation to the J-OWAMP web site. = The current version of J-OWAMP (version 2.1 ) implements the December = 2004 draft proposal of OWAMP = (http://www.internet2.edu/~shalunov/ippm/draft= -ietf-ippm-owdp-14.txt). The previous versions of J-OWAMP (versions 1.0 and = 1.2) implement the May 2004 draft proposal of OWAMP (http://www.internet2.edu/~shalunov/ippm/draft= -ietf-ippm-owdp-08.txt).

On the new versions:

J-OWAMP includes a NTP client which can = be used to get the time reference directly from a NTP server, without the requirement of a synchronized clock on the machine hosting = J-OWAMP;

The user can choose the local IP = address to bind to. This address can be used on a multi-homed host for = an OWAMP element that will only accept connection requests to one of = its addresses. If not defined, it will by default accept connections on any/all local addresses;

some others improvements were = made.

You can find more information on this platform = in http://www.av.it.pt/jowamp.

Any comments are welcome.

Best regards.

H=E9lder Veiga

Rui Valadas

Jos=E9 Lu=EDs Oliveira

Paulo Salvador

Ant=F3nio Nogueira

Jo=E3o Silva

------=_NextPart_000_0007_01C5FFD7.2B1A69D0-- --===============0879783814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============0879783814==-- From ippm-bounces@ietf.org Tue Dec 20 12:01:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eokrv-0002di-39; Tue, 20 Dec 2005 12:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eokrt-0002dW-En for ippm@megatron.ietf.org; Tue, 20 Dec 2005 12:01:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00573 for ; Tue, 20 Dec 2005 12:00:38 -0500 (EST) Received: from brixcorp.brixnet.com ([63.122.27.50] helo=brixmail.ma.brixnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EokuK-00053R-Or for ippm@ietf.org; Tue, 20 Dec 2005 12:04:14 -0500 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, 20 Dec 2005 12:01:31 -0500 Message-ID: Thread-Topic: draft-hedayat-two-way-active-measurement protocol-01.txt TWAMPLight Thread-Index: AcX2Ih3P0SpfWCD1RySSIL/yqhIpNgPVDbRw From: "Hedayat, Kaynam" To: "sharee mcnab" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: nick kinraid Subject: [ippm] RE: draft-hedayat-two-way-active-measurement protocol-01.txt TWAMPLight 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 Shree, 1. Per section 5.1 of TWAMP, "sender behavior is as defined in section 4.1 of OWAMP [OWAMP] for both packet timing and packet format". The intent is to follow the OWAMP implementations as much as possible. 2. I am not clear on what you mean by packet record. Please clarify. On the timestamp concern I am not convinced that the saving on number of bytes justifies the deviation from OWAMP. Regards, Kaynam -----Original Message----- From: sharee mcnab [mailto:sharee.mcnab@alliedtelesyn.co.nz]=20 Sent: Wednesday, November 30, 2005 9:51 PM To: Hedayat, Kaynam; ippm@ietf.org Cc: nick kinraid Subject: draft-hedayat-two-way-active-measurement protocol-01.txt TWAMPLight Further comments/questions on the TWAMP draft - 1. In the TWAMP draft the format of the send packet is not explictly stated. Should we assume a) the send packet is the same as the OWAMP send packet (ie 14 octets unauthenticated, 32 authenticated/encrypted) which then leaves the send and reflected packets with a different size (undesirable) unless the payload is adjusted by the reflector. OR b) the send packet is the same format as that of the reflected packet (ie 40 octets unauthenticated, 80 authenticated/encrypted), here both packets are the same size (desirable) with a larger bandwidth requirement. I assume b) but think clarification should be in the draft. 2. An explicit packet record is not defined for TWAMP. Is this considered within the scope of the TWAMP draft to provide a packet record for this protocol? Given the excessive number of time stamps for a two-way measurement I would propose that a single time reference be used and then offsets to reduce the size of the packet record. Cheers Sharee NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Dec 21 09:15:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep4kj-0002OK-Uv; Wed, 21 Dec 2005 09:15:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep4kh-0002No-ND for ippm@megatron.ietf.org; Wed, 21 Dec 2005 09:15:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17847 for ; Wed, 21 Dec 2005 09:14:31 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep4nK-0006J3-V9 for ippm@ietf.org; Wed, 21 Dec 2005 09:18:19 -0500 Received: by postman.ripe.net (Postfix, from userid 4008) id D568F24246; Wed, 21 Dec 2005 15:15:09 +0100 (CET) Received: from cod.ripe.net (cod.ripe.net [193.0.1.202]) by postman.ripe.net (Postfix) with ESMTP id C8F5F23F73; Wed, 21 Dec 2005 15:15:06 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by cod.ripe.net (Postfix) with ESMTP id 9D091726A3; Wed, 21 Dec 2005 15:15:06 +0100 (CET) Message-Id: <6.2.3.4.2.20051221151008.02c934a0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 21 Dec 2005 15:14:45 +0100 To: ippm@ietf.org, Matthew J Zekauskas , mankin@psg.com From: Henk Uijterwaal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000070 / -5.9 X-RIPE-Signature: fd43767ac8e7aa8b14039d624e093bea X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Subject: [ippm] Reordering drafts 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 WG has been discussing reordering since (at least) the London IETF in 2001. A metric was proposed at this meeting. At the Salt Lake City IETF in the same year, 3 more metrics were proposed. Drafts were published at the IETF53 (March 2002). These were later merged into one document, draft-ietf-ippm-reordering (mid 2002). This document was adopted by the WG as a group document. We will refer to this draft as the group draft. In parallel, a group from Colorado State University (CSU) started to work on another metric. This resulted in a individual submission draft (draft-jayasumana-reorder-density, with the first version from 2003). We will refer to this draft as the CSU draft. There appear to be 3 issues with these drafts. 1. Contents. The authors of the second draft claim that the group draft does not describe suitable metrics for measuring reordering. They have made their argument at several meetings and in postings, the latest one is http://www.cnrl.colostate.edu/Reorder/compmetrics_for_ietf.pdf. In our judgement, they seem to be alone in their opinion. The group draft been actively reviewed by at least 10 people in the group and has been in its current state for at least a year (except for minor changes in wording and clarifications). In short, we believe that this draft meets the "rough consensus" guideline, even though we recognize that the CSU folks disagree with the draft. 2. Origin of the byte-offset metrics. In parallel, the CSU group also claims that this metric has been derived from their Reorder Buffer Density metric. We seriously doubt the validity of this claim. The ideas behind the group draft were discussed in 2001-2002 and the CSU draft is from a later date. Also, at least one of the authors of the CSU draft participated in the early discussions on the group draft. 3-4 years after the discussion, it is of course impossible to say who exactly made which point in these discussions. We also find it strange that this claim comes up years after the fact. A more extensive analysis of this issue can be found at http://people.internet2.edu/~matt/IPPM/Reordering/PiratlaCommented.html 3. Should the CSU draft become a WG document? The CSU group has repeatedly asked the WG to adopt their document as a WG document. So far, there has been no support for this, either on the mailing list or in any of the meetings where the topic was discussed. While we acknowledge the work done by the CSU group, we believe that there is currently no support or interest from the WG for the CSU draft. Next steps: * The group draft has been stable for a year and the majority of the WG supports it. We therefor propose to declare "rough consensus", do a WGLC and move the document forward. * We will add a stable reference to the CSU draft in the group draft. * We propose that the WG will not pick up the CSU draft as a WG document, as there seems to be no support for this. Our position has been communicated to the AD. We will make our final decision in about 2 weeks time. Please raise any points that you might have on the above on the list before January 3, 2006. 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 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Dec 28 17:34:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erjsn-0004WZ-4t; Wed, 28 Dec 2005 17:34:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erjsl-0004WC-37 for ippm@megatron.ietf.org; Wed, 28 Dec 2005 17:34:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27872 for ; Wed, 28 Dec 2005 17:33:44 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erjws-0000Ft-UH for ippm@ietf.org; Wed, 28 Dec 2005 17:39:11 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id jBSMYoM853422 for ; Wed, 28 Dec 2005 15:34:50 -0700 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id jBSMYo418563 for ; Wed, 28 Dec 2005 15:34:50 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Wed, 28 Dec 2005 15:34:54 -0700 From: Nischal M Piratla To: ippm X-EXP32-SerialNo: 00002247, 00002264 Subject: RE: [ippm] Reordering drafts Message-ID: <43B4E7D3@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: 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 >We will make our final decision in about 2 weeks time. Please raise >any points that you might have on the above on the list before >January 3, 2006. > >Matt & Henk > Dear IPPM-Reordering-draft Authors, After looking at the ippm reordering draft references, I would suggest that a references to RD publications be also placed, along with RBD publication[TBABAJ02] from us (CSU). Here are the citations for suggested additions, to the list of references: Nischal M. Piratla, Anura P. Jayasumana and Tarun Banka, "On Reorder Density and its Application to Characterization of Packet Reordering," Proceedings 30th IEEE Local Computer Networks Conference (LCN 2005, Sydney, Australia, Nov. 2005, pp: 156-163. Nischal M. Piratla, Anura Jayasumana and Abhijit Bare, "RD: A Formal, Comprehensive Metric for Packet Reordering," Proceedings, 4th International IFIP-TC6 Networking Conference (Networking 2005), Waterloo, Canada, May 2-6, 2005, LNCS 3462, pp: 78-89. Thank you, Nischal Piratla [This email id. may not be active after few months, please use nischal_piratla at "yahoo" dot "com"] Senior Research Scientist Deutsche Telekom AG Laboratories Ernst-Reuter-Platz 7, D10587 Berlin, Germany _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Dec 28 22:48:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erolo-00031n-P5; Wed, 28 Dec 2005 22:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erk6d-0001uC-33 for ippm@megatron.ietf.org; Wed, 28 Dec 2005 17:49:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29594 for ; Wed, 28 Dec 2005 17:48:04 -0500 (EST) Received: from tcmail21.telekom.de ([217.6.95.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErkAk-0000mp-Tn for ippm@ietf.org; Wed, 28 Dec 2005 17:53:31 -0500 Received: from g9jbq.mgb01.telekom.de (g9jbq.mgb01.telekom.de [164.20.31.5]) by tcmail21.dmz.telekom.de with ESMTP for ippm@ietf.org; Wed, 28 Dec 2005 23:49:04 +0100 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Dec 2005 23:49:04 +0100 Message-Id: <74786E53E28B4D49B86B31C87D32FE55B4ACCE@S4DE9JSAAMV.ost.t-com.de> From: "Piratla, Nischal" To: ippm@ietf.org Date: Wed, 28 Dec 2005 23:48:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-Mailman-Approved-At: Wed, 28 Dec 2005 22:48:03 -0500 Cc: Subject: [ippm] Reordering Metrics papers 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="===============0847776437==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0847776437== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60C00.E2D9C3C1" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C60C00.E2D9C3C1 Content-Type: text/plain Dear ippm members, As per the recommendation of Henk, I have listed the most recent papers that we published (&submitted) in the area of reordering, and characterization/modeling of reordering: N. M. Piratla, A. P. Jayasumana and A. A. Bare, "RD: A Formal, Comprehensive Metric for Packet Reordering ," Proc. IFIP Networking Conference 2005, Ontario, Canada, May 2005, LNCS 3462, pp: 78-89. N. M. Piratla, A. P. Jayasumana and T. Banka, "On Reorder Density and its Application to Characterization of Packet Reordering ," Proc. 30th IEEE Local Computer Networks (LCN) Conference, Sydney, Australia, Nov. 2005. N. M. Piratla, A. P. Jayasumana and A. A. Bare, "A Comparative Analysis of Packet Reordering Metrics," (To appear) Proc. 1st International Conference on COMmunication System softWAre and MiddlewaRE (COMSWARE 2006), New Delhi, India, Jan. 2006. http://www.cnrl.colostate.edu/Reorder/compmetrics_for_ietf.pdf N. M. Piratla and A. P. Jayasumana, " Reordering of Packets due to Multipath Forwarding - An Analysis" (submitted for publication) -------------------------------------------------- Dr. Nischal Piratla Senior Research Scientist Deutsche Telekom AG Laboratories Ernst-Reuter-Platz 7, D10587 Berlin, Germany Off: +49 30 8353 58472 Fax: +49 30 8353 58409 These papers are presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder. ------_=_NextPart_001_01C60C00.E2D9C3C1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Reordering Metrics papers

Dear ippm members,
As per the recommendation of Henk, I = have listed the most recent papers that we published (&submitted) = in the area of reordering, and characterization/modeling of = reordering:

N. M. Piratla, A. P. Jayasumana and = A. A. Bare, "RD: A Formal, = Comprehensive Metric for Packet Reordering," Proc. IFIP Networking Conference 2005, = Ontario, Canada, May 2005, LNCS 3462, pp: 78-89.

N. M. Piratla, A. P. Jayasumana and = T. Banka, "On Reorder = Density and its Application to Characterization of Packet = Reordering," Proc. = 30th IEEE Local Computer Networks (LCN) Conference, Sydney, Australia, = Nov. 2005.

N. M. Piratla, A. P. Jayasumana and = A. A. Bare, "A Comparative Analysis of Packet Reordering = Metrics," (To appear) Proc. 1st International Conference on = COMmunication System softWAre and MiddlewaRE (COMSWARE 2006), New = Delhi, India, Jan. 2006. = http://www.cnrl.colostate.edu/Reorder/compmetrics_for_ietf.pdf

N. M. Piratla and A. P. Jayasumana, = " Reordering of Packets due to Multipath Forwarding - An = Analysis" (submitted for publication)

--------------------------------------------------=
Dr. Nischal Piratla
Senior Research = Scientist
Deutsche Telekom AG = Laboratories
Ernst-Reuter-Platz 7, = D10587
Berlin, Germany
Off: +49 30 8353 = 58472
Fax: +49 30 8353 = 58409

These papers are presented to ensure = timely dissemination of scholarly and technical work. Copyright and all = rights therein are retained by authors or by other copyright holders. = All persons copying this information are expected to adhere to the = terms and constraints invoked by each author's copyright. In most = cases, these works may not be
reposted without the explicit permission of the copyright holder.

------_=_NextPart_001_01C60C00.E2D9C3C1-- --===============0847776437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============0847776437==--