From ippm-bounces@ietf.org Sun Aug 1 01:18:01 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 BAA08250 for ; Sun, 1 Aug 2004 01:18:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Br8WT-0004Fn-4R; Sun, 01 Aug 2004 01:04:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Br8TL-0003hE-IV for ippm@megatron.ietf.org; Sun, 01 Aug 2004 01:01: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 BAA07726 for ; Sun, 1 Aug 2004 01:01:22 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Br8Vv-00022u-Uj for ippm@ietf.org; Sun, 01 Aug 2004 01:04:04 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id DE75C1CD612 for ; Sun, 1 Aug 2004 01:01:21 -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 00307-02 for ; Sun, 1 Aug 2004 01:01:21 -0400 (EDT) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 578B51CD4DC for ; Sun, 1 Aug 2004 01:01:21 -0400 (EDT) Date: Sun, 01 Aug 2004 01:01:20 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Message-ID: X-Mailer: Mulberry/3.1.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: quoted-printable Subject: [ippm] Surveyor implementation report for RFC 2679-2680 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 I don't believe we attempted to implement RFC 2678, and certainly not RFC 2681 for Surveyor. I'm also trying to get an implementation report on the metrics for the Internet2 OWAMP implementation (I believe we also implement periodic streams, although we haven't used them in practice to date). --Matt - - - - - General =3D=3D=3D=3D=3D=3D=3D Name of Implementation: Surveyor Organization: Advanced Network & Services, Inc. Contact details: (original) Advanced Network & Services, Inc. 200 Business Park DR, Armonk, NY 10504, USA Advanced is essentially defunct as of this writing (30-Jul-2004); for details on the implementation see the INET'99 paper Sunil Kalidindi and Matt Zekauskas. "Surveyor: An Infrastructure for Internet Performance Measurements." INET =9299, June 1999. or contact Matt Zekauskas, matt@internet2.edu. The Surveyor code and data from 1997-2002 was donated to the Wisconsin Advanced Internet Lab; contact is Paul Barford, pb@cs.wisc.edu Origin of code: Written from scratch. Platform: BSDI/OS 3.2+ TrueTime GPS-PC card, with custom device driver This platform is IPv4-only; while the code should be IP-address independent, this was never verified, and would likely require some tweaking. Metrics =3D=3D=3D=3D=3D=3D=3D RFC2679/Type-P-One-way-Delay ---------------------------- Parameters: Implemented? + Src, the IP address of a host Yes + Dst, the IP address of a host Yes + T, a time Yes Units: + dT Yes Methodology: + According to section 3.6 of RFC 2679 + Synchronization via GPS time cards + Timestamping in software (and not in the network driver, although we did have an experimental version that did this) Comments (Type-P): + UDP packets are being used. + The port numbers for test traffic varied (and could not be specified) among sessions, although for any given session port numbers were fixed + User data length was 12 bytes (32 bit sequence number, 64 bit time value) + In general, no special IP bits are set, but there was a version of the code which allowed the user to set the TOS/DSCP values. + If a packet is duplicated, any duplicates are ignored (the delay of the first packet to arrives is used). + Corrupted packets are generally counted as lost; they will fail either a hardware CRC check, or IP or UDP checksum verification. Features included: + If either end lost synchronization with GPS (as reported by the timing card) the session was broken and measurement ceased. Features not implemented: Reporting the metric: + Because measurements ceased when GPS synchronization was lost, and the errors (typically 50 to 100 microseconds with our densest measurement mesh) were much smaller than instrumented paths, negative values were not reported, but flagged as a possible software error. + The loss threshold was 400 received packets in our implementation. For typical paths where two packets per second (on average) were sent, the loss threshold was about 200 seconds, or 3 1/3 minutes. + In our implementation the distinguished value 10,000,000 was used to signify infinite delay (a loss).(10 seconds -- although in practice I don't believe we saw anything greater than ~3 sec.) + All systematic errors are removed from the timestamps before reporting the metrics + Paths are being determined by running the well-known traceroute tool approximately 6 times an hour (on a Poisson schedule with average 10 seconds, but also clamped to 10 seconds maximum). Paths were stored independent of delays, but displayed along with delays in our graphical displays. Tests performed: + Back-to-back tests of typical machines in the field was performed for calibration. For our worst-case fan-out (due to the software implementation, error became worse the more paths that were measured), 80 paths, the calibration error was 100 microseconds. + Cross check of measurements against the RIPE-TT implementation (reported at the 44th IETF IPPM WG meeting by Henk Uijterwaal). RFC2679/Type-P-One-way-Delay-Poisson-Stream ------------------------------------------- Parameters: + Src, the IP address of a host Yes + Dst, the IP address of a host Yes + T0, a time Yes + Tf, a time Yes + lambda, a rate in reciprocal seconds Yes Note: Lambda is reported as packets per second. Units: + T, a time, and Yes + dT, either a real number or an undefined number of seconds. Yes Report consists of series of measurements for Type-P-One-Way-Delay. All the Type-P-One-Way-Delay features and comments above apply here. Features: + The receiver knew the send schedule (passed as a seed to the random number generated used for the Poisson schedule) so it could independently determine if packets were lost. + As with the singleton, he loss threshold was 400 received packets in our implementation. For typical paths where two packets per second (on average) were sent, the loss threshold was about 200 seconds, or 3 1/3 minutes. + This 400 packet window was also used to correct for reordering. + All delay values were kept to allow computation of arbitrary percentiles on demand. RFC2679/Type-P-One-way-Delay-Percentile --------------------------------------- By default, the 50th percentile (median) and 90th percentile are calculated and reported for one minute intervals. A separate Java-based UI could ask for arbitrary percentiles over arbitrary intervals (provided the raw data was on-line) -- typically 6 months of raw data were on-line. RFC2679/Type-P-One-way-Delay-Median ----------------------------------- This value is calculated and reported for one minute intervals, although we did have a separate Java-based UI that could vary the reporting period RFC2679/Type-P-One-way-Delay-Minimum ------------------------------------ This value is calculated and reported for one minute intervals, although we did have a separate Java-based UI that could vary the reporting period. RFC2679/Type-P-One-way-Delay-Inverse-Percentile ----------------------------------------------- Not implemented. Our implementation did not calculate any inverse percentiles. One could ask for the raw data and calculate the inverse percentile yourself. Our implementation did, however, provide a histogram of delay values, by default ranging from 0 to 300mS in 10mS buckets. RFC2680/Type-P-One-way-Packet-Loss ---------------------------------- Metric Parameters: Implemented + Src, the IP address of a host Yes + Dst, the IP address of a host Yes + T, a time Yes Metric Units: + Type-P-One-way-Packet-Loss =3D [0,1] Yes Comments: + The time is the time the packet was sent, rounded to the nearest microsecond. + Packets that arrive at the machine corrupted are generally dropped either by the hardware CRC failure, or by IP or UDP checksum failure. Hence, corrupted packets are counted as lost. + If a packet is duplicated, any duplicates are ignored. Further comments: This metric has been implemented in combination with RFC2679/Type-P-One-way-Delay. All comments made there apply. If a packet arrives, it's Type-P-One-way-Packet-Loss is 0. If a packet does not arrive in the specified window (200 seconds by default) the delay is infinite (undefined), and the Type-P-One-way-Packet-Loss is 1. RFC2680/Type-P-One-way-Packet-Loss-Poisson-Stream ------------------------------------------------- This has been implemented as part of RFC2679/Type-P-OWD-Poisson-Stream. Results consists of a series of measurements for the One Way Delay, with values of 10,000,000 for packets that were sent but did not arrive. RFC2680/Type-P-One-way-Packet-Loss-Average ------------------------------------------ By default, the Surveyor reporting mechanisms calculate this on one-minute intervals. A Java UI allows calculations on different intervals. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From mailman-bounces@ietf.org Sun Aug 1 08:49: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 IAA19067 for ; Sun, 1 Aug 2004 08:49: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 1BrCm9-0006nj-Sk for ippm-archive@lists.ietf.org; Sun, 01 Aug 2004 05:37:05 -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: Sun, 01 Aug 2004 05:10:42 -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 Sun Aug 1 10:34: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 KAA03049 for ; Sun, 1 Aug 2004 10:34: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 1BrGmD-0002Pt-Ue; Sun, 01 Aug 2004 09:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrEHz-0008WO-Pf for ippm@megatron.ietf.org; Sun, 01 Aug 2004 07:14:03 -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 HAA12571 for ; Sun, 1 Aug 2004 07:14:01 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrEKc-0001R8-Ks for ippm@ietf.org; Sun, 01 Aug 2004 07:16:48 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 601831CD6F1; Sun, 1 Aug 2004 07:14: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 04403-07; Sun, 1 Aug 2004 07:14:01 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id BD9091CD6FD; Sun, 1 Aug 2004 07:14:00 -0400 (EDT) To: "Henk Uijterwaal (RIPE NCC)" Subject: Re: [ippm] draft-ietf-ippm-owdp-08.txt References: <200405061527.LAA20089@ietf.org> <86smedtt0t.fsf@abel.internet2.edu> <86bricy79c.fsf@abel.internet2.edu> From: stanislav shalunov Date: 01 Aug 2004 00:00:49 -0400 In-Reply-To: Message-ID: <86n01fv766.fsf@abel.internet2.edu> Lines: 91 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: 0.6 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: 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 "Henk Uijterwaal (RIPE NCC)" writes: > > > * Page 16: 'The server should start ...'. > > > Suppose the start time is specified as t=0 with a rate of 100 packets. > > > For some reason, the server takes more time to start, so the first > > > packet cannot be sent before t=1. What should be done with the 100 > > > packets that had to be sent between t=0 and t=1? > > > > > > - Send as fast as possible? Possibly overloading the network, > > > with the risk of making a complete run invalid. > > > - Send with a (minimum) gap? > > > - Skip > > > > The way it is written now, the implication is that they should be > > skipped. The send schedule is rigid and reproducible, with exact > > timestamps attached to every packet to be sent. If some packets are > > in the past, they would have to be skipped. > > > > Is this reasonable? > > Perfectly reasonable, this is just so we know how to implement this, I > don't think that there is a need for anything more complex. After re-reading and conferring with Jeff I think this aspect will need to be clarified. The feature that I originally put in with starts in the past---which enable you to start a session ``as soon as this OWAMP-Control message gets to you''---is more trouble than it's worth. If it's taken out, everything falls into place nicely: You'd send the packets that you were supposed to send less than timeout time ago as quickly as you can. (This prevents a large burst of packets that would be discarded by the receiver anyway because they are too late.) > Well, yes, I know it can be done somewhat more efficient, but whatever you > do, you will end up splitting 2 16-bits and 2 32-bits numbers over 3 32 > bit words. If the order is changed to 32 bits for the 2 timestamps, then > 1 word for the 2 16 bit EE, you have to put 2x16 bits into one word (and > this requires some manipulation) but the rest are straight copies. This is > code that is sitting in the most time-critical part of your application, > anything we can do to reduce the number of operations there, will improve > the measurements. > > If there is a techical argument for this, then please tell me, if not, I > don't see why the order cannot be changed. I'm not sure I understand the packet format you describe. Why don't we talk about it in San Diego? Otherwise, could you elaborate a bit---perhaps a diagram with bits allocated or another description would help me. > > Regarding error estimates: Firstly, there is no need to generate the > > error estimate in the protocol format for every packet. The error > > estimate changes infrequently. > > I tend to disagree. That is certainly true for NTP. It's difficult to imagine the semantics of a frequently changing error estimate. > Also, if one decides that error estimate is only checked and > recalculated once every N seconds, then there will be 2 classes of > packets: one where the error estimation code was called and one > where it was not. In the former case, the systematic errors will be > different than in the latter, but the user has no way to tell. Not necessarily. You don't want the error estimate preparation in the critical path (between obtaining a timestamp and issuing the send() call---in Unix-speak) at all. One way to accomplish this is to prepare the error estimate before obtaining the timestamp. (If the interface for getting the error estimate also gives you time, as is the case, with, e.g., ntp_gettime(), you discard the timestamp obtained in the call to the interface made to obtain the error estimate. By the way, for whatever reasons, on FreeBSD ntp_gettime() produces about three times the overhead of gettimeofday(), if I am not mistaken; so it is anyway preferable to separate the two functions---frequently obtaining timestamps and infrequently obtaining error estimates---into two different calls.) Maybe we should add an implementor's note to describe all this. > The set of natural numbers excluding 0 is smaller but still contains > sufficient numbers for all packets :-) Well, we could have saved 0 for special value. I think 0xFFFFFFFF (which is already used as a special value, by the way) is more convenient. I don't think this really matters. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed upside down. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Aug 1 10:47:54 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 KAA04267 for ; Sun, 1 Aug 2004 10:47: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 1BrHLw-0000Q7-Vc; Sun, 01 Aug 2004 10:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrG3J-00066F-PE for ippm@megatron.ietf.org; Sun, 01 Aug 2004 09:07:03 -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 JAA20723 for ; Sun, 1 Aug 2004 09:06:58 -0400 (EDT) Received: from rms06.rommon.net ([212.54.5.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrG5x-0002hx-Ox for ippm@ietf.org; Sun, 01 Aug 2004 09:09:47 -0400 Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by rms06.rommon.net (Postfix) with ESMTP id 5706933C35; Sun, 1 Aug 2004 16:06:52 +0300 (EEST) Message-ID: <410CEAEE.70303@he.iki.fi> Date: Sun, 01 Aug 2004 16:06:54 +0300 From: Petri Helenius 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: David Murray Subject: Re: [ippm] IETF Session Live Internet Broadcast (MBONE **NOT NEEDED** TO VIEW) References: <97D194594651E6F44DCA30D1@pwolf.WV.CC.CMU.EDU> In-Reply-To: <97D194594651E6F44DCA30D1@pwolf.WV.CC.CMU.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: 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 Content-Transfer-Encoding: 7bit David Murray wrote: > For the IETF meeting coming up, a number of events (including one for > this group) will be broadcast publicly via a technology called ESM > through Carnegie Mellon University. > > To tune to any broadcasts, visit http://esm.cs.cmu.edu during the > meetings (August 2-5) and click "Watch". > > To participate, you need a system with the following requirements: > - A machine with Windows 98 or later, Linux, or Mac OS X > - You need to have a DSL, Cable Modem, or better connection (you do > *not* need mbone to view this event) > Looking at the pages it made me wonder if this actually is standard RTSP/RTP or not? Pete _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Aug 1 17:18: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 RAA24610 for ; Sun, 1 Aug 2004 17:18: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 1BrNR1-0000XQ-35; Sun, 01 Aug 2004 16:59:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrNIe-0005mI-W4 for ippm@megatron.ietf.org; Sun, 01 Aug 2004 16:51:21 -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 QAA23842 for ; Sun, 1 Aug 2004 16:51:18 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrNLM-0000gr-Lu for ippm@ietf.org; Sun, 01 Aug 2004 16:54:10 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 0D2E14ECCC; Sun, 1 Aug 2004 22:46:11 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 9BC664EC85; Sun, 1 Aug 2004 22:46:10 +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 i71KkAx0023219; Sun, 1 Aug 2004 22:46:10 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i71KkA01002974; Sun, 1 Aug 2004 22:46:10 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Sun, 1 Aug 2004 22:46:10 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: stanislav shalunov Subject: Re: [ippm] draft-ietf-ippm-owdp-08.txt In-Reply-To: <86n01fv766.fsf@abel.internet2.edu> Message-ID: References: <200405061527.LAA20089@ietf.org> <86smedtt0t.fsf@abel.internet2.edu> <86bricy79c.fsf@abel.internet2.edu> <86n01fv766.fsf@abel.internet2.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000003 / 0.0 / 0.0 / disabled X-RIPE-Signature: c28c9bd69525b5791b715672af8890c9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 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 > > Well, yes, I know it can be done somewhat more efficient, but whatever you > > do, you will end up splitting 2 16-bits and 2 32-bits numbers over 3 32 > > bit words. If the order is changed to 32 bits for the 2 timestamps, then > > 1 word for the 2 16 bit EE, you have to put 2x16 bits into one word (and > > this requires some manipulation) but the rest are straight copies. This is > > code that is sitting in the most time-critical part of your application, > > anything we can do to reduce the number of operations there, will improve > > the measurements. > > > > If there is a techical argument for this, then please tell me, if not, I > > don't see why the order cannot be changed. > > I'm not sure I understand the packet format you describe. Why don't > we talk about it in San Diego? Otherwise, could you elaborate a > bit---perhaps a diagram with bits allocated or another description > would help me. Right now, we have: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Send Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| Receive Timestamp | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| | Receive Error Estimate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with 2 32 bit quantities starting halfway a 32 bit word. That makes it hard to map the packet on an array of 32 bit words. I suggest: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Send Error Estimate | Receive Error Estimate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 16| Receive Timestamp | 20| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ so everything is nicely aligned. 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Aug 1 17:40:52 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 RAA25593 for ; Sun, 1 Aug 2004 17:40: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 1BrNmn-0002e3-5I; Sun, 01 Aug 2004 17:22:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHQq-00046L-O6 for ippm@megatron.ietf.org; Sun, 01 Aug 2004 10:35:24 -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 KAA03180 for ; Sun, 1 Aug 2004 10:35:22 -0400 (EDT) Received: from orient.cmcl.cs.cmu.edu ([128.2.220.47]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BrHTT-0003oc-IJ for ippm@ietf.org; Sun, 01 Aug 2004 10:38:10 -0400 Received: from orient.cmcl.cs.cmu.edu ([127.0.0.1]) by orient.cmcl.cs.cmu.edu id aa10224; 1 Aug 2004 10:34 EDT Date: Sun, 1 Aug 2004 10:34:51 -0400 (EDT) From: Jibin Zhan X-X-Sender: To: pete@he.iki.fi MMDF-Warning: Parse error in original version of preceding line at orient.cmcl.cs.cmu.edu MMDF-Warning: Parse error in original version of preceding line at orient.cmcl.cs.cmu.edu Subject: Re: [ippm] IETF Session Live Internet Broadcast (MBONE **NOT NEEDED** TO VIEW) (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Sun, 01 Aug 2004 17:22:28 -0400 Cc: dim@andrew.cmu.edu, 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 Yes. Our system is based on those standards. thanks, Jibin On Sun, 1 Aug 2004, David Murray wrote: > > > ------------ Forwarded Message ------------ > Date: Sunday, August 01, 2004 4:06 PM +0300 > From: Petri Helenius > To: David Murray > Cc: ippm@ietf.org > Subject: Re: [ippm] IETF Session Live Internet Broadcast (MBONE **NOT > NEEDED** TO VIEW) > > David Murray wrote: > > > For the IETF meeting coming up, a number of events (including one for > > this group) will be broadcast publicly via a technology called ESM > > through Carnegie Mellon University. > > > > To tune to any broadcasts, visit http://esm.cs.cmu.edu during the > > meetings (August 2-5) and click "Watch". > > > > To participate, you need a system with the following requirements: > > - A machine with Windows 98 or later, Linux, or Mac OS X > > - You need to have a DSL, Cable Modem, or better connection (you do > > *not* need mbone to view this event) > > > Looking at the pages it made me wonder if this actually is standard > RTSP/RTP or not? > > Pete > > > > ---------- End Forwarded Message ---------- > > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Aug 2 18:55:44 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 SAA12417 for ; Mon, 2 Aug 2004 18:55:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brk3O-0004uA-3s; Mon, 02 Aug 2004 17:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brjyc-00007C-Q2 for ippm@megatron.ietf.org; Mon, 02 Aug 2004 17:04:10 -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 RAA05183 for ; Mon, 2 Aug 2004 17:04:08 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brk1X-0004Rq-Ts for ippm@ietf.org; Mon, 02 Aug 2004 17:07:13 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3D9561CD5B7; Mon, 2 Aug 2004 17:04:07 -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 27559-06; Mon, 2 Aug 2004 17:04:07 -0400 (EDT) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A83641CD5A0; Mon, 2 Aug 2004 17:04:06 -0400 (EDT) Message-ID: <410EAC69.E304259F@internet2.edu> Date: Mon, 02 Aug 2004 15:04:41 -0600 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henk Uijterwaal (RIPE NCC)" Subject: Re: [ippm] draft-ietf-ippm-owdp-08.txt References: <200405061527.LAA20089@ietf.org> <86smedtt0t.fsf@abel.internet2.edu> <86bricy79c.fsf@abel.internet2.edu> <86n01fv766.fsf@abel.internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: stanislav shalunov , 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 Content-Transfer-Encoding: 7bit > hard to map the packet on an array of 32 bit words. I suggest: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 12| Send Error Estimate | Receive Error Estimate | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ > 16| Receive Timestamp | > 20| | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > so everything is nicely aligned. Speaking as an implementor... I don't think this is much of a big deal. From the point of view of a typical C program it is simply a matter of a memcpy verses an assignment. This would be a very minimal difference for any reasonable compiler/hardware. However, the only down side to this change would be the fact that currently deployed software would not be compatible. But, the TTL and lost packet changes already make our currently deployed software incompatible. Therefore, I would say that as long as this change happens quickly, it would not bother me. (I have not deployed the "ttl/lost packet version yet and could just put this additional change into that version.) jeff _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Aug 2 18:55:56 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 SAA12478 for ; Mon, 2 Aug 2004 18:55:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrkTU-0007E2-Pn; Mon, 02 Aug 2004 17:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrkLJ-0002HL-6a for ippm@megatron.ietf.org; Mon, 02 Aug 2004 17:27:37 -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 RAA06482 for ; Mon, 2 Aug 2004 17:27:35 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrkOC-0004p7-KC for ippm@ietf.org; Mon, 02 Aug 2004 17:30:39 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id DABB11CD514; Mon, 2 Aug 2004 17:27:32 -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 32406-10; Mon, 2 Aug 2004 17:27:32 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A91C01CD4EF; Mon, 2 Aug 2004 17:27:32 -0400 (EDT) To: "Henk Uijterwaal (RIPE NCC)" Subject: Re: [ippm] draft-ietf-ippm-owdp-08.txt References: <200405061527.LAA20089@ietf.org> <86smedtt0t.fsf@abel.internet2.edu> <86bricy79c.fsf@abel.internet2.edu> <86n01fv766.fsf@abel.internet2.edu> From: stanislav shalunov Date: 02 Aug 2004 17:27:35 -0400 In-Reply-To: Message-ID: <86brht2ptk.fsf@abel.internet2.edu> Lines: 38 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: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 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 "Henk Uijterwaal (RIPE NCC)" writes: > Right now, we have: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 12| Send Error Estimate | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > 16| Receive Timestamp | > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 20| | Receive Error Estimate | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Is that in the response to the Fetch-Session command? (The OWAMP-Test packets don't have receive timestamps.) Fetch-Session response isn't necessarily aligned (each packet record contains 25 octets), so it would not let you replace memory copy calls with assignments in the C code. (I mention C code, because the compiled version would be scarcely different even if you did replace the memcpy() calls with assignments to *(this+that).) Note that when the response is generated and transmitted, you don't actually need to deal with packet records individually---these would only need to be generated once when the packets are received and the session data is stored. Jeff said it's OK with him to change this, from the point of view of compatibility. If no-one chimes in and objects in a few days, I would put the change in since it doesn't hurt anything and might perhaps save a cycle or two for some implementations. Note that the proposed change does not affect OWAMP-Test, so it wouldn't break, e.g., the just-described hardware implementation. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "The power of accurate observation is commonly called cynicism by those who have not got it." -- G. B. Shaw _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Aug 3 12:34: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 MAA19585 for ; Tue, 3 Aug 2004 12:34: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 1Bs2C0-00009d-QS; Tue, 03 Aug 2004 12:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs27B-00082j-RG for ippm@megatron.ietf.org; Tue, 03 Aug 2004 12:26:13 -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 MAA19023 for ; Tue, 3 Aug 2004 12:26:11 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2AF-000486-JD for ippm@ietf.org; Tue, 03 Aug 2004 12:29:26 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 73D0351DD9; Tue, 3 Aug 2004 18:24:18 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 2B31F51CC1; Tue, 3 Aug 2004 18:24:18 +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 i73GOIW7010670; Tue, 3 Aug 2004 18:24:18 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i73GOIxS007494; Tue, 3 Aug 2004 18:24:18 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Tue, 3 Aug 2004 18:24:18 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: Lei Liang Subject: Re: [ippm] why no considerations on the multi-to-multi measurement Metrics? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.004049 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8bfcbccc38261703cd1a76862806498f X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 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 Lei, > The enclosed document shows some intitial thoughts on this issue. I will > be very glad to hear any comments regarding this consideration. We discussed this briefly yesterday and suggest that you turn your note into an Internet draft (Individual submission) and submit that. On the list, we can then discuss to pick this up as a working group item. 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Aug 3 19:11:54 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 TAA20456 for ; Tue, 3 Aug 2004 19:11: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 1Bs8L1-0007Ph-9E; Tue, 03 Aug 2004 19:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7Ko-0002JG-CY for ippm@megatron.ietf.org; Tue, 03 Aug 2004 18:00: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 SAA15683 for ; Tue, 3 Aug 2004 18:00:35 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7Nx-0002LE-V8 for ippm@ietf.org; Tue, 03 Aug 2004 18:03:54 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id C11BA1CD4FD; Tue, 3 Aug 2004 18:00:36 -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 27487-02; Tue, 3 Aug 2004 18:00:36 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 5AADD1CD4EC; Tue, 3 Aug 2004 18:00:36 -0400 (EDT) To: Sam Weiler , Bernard Aboba Subject: [ippm] security review of draft-ietf-ippm-owdp-09.txt References: <20040803202804.EF8B51AE93@berkshire.research.att.com> From: stanislav shalunov Date: 03 Aug 2004 18:00:38 -0400 In-Reply-To: <20040803202804.EF8B51AE93@berkshire.research.att.com> Message-ID: <86d627g9vd.fsf@abel.internet2.edu> Lines: 99 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: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-Mailman-Approved-At: Tue, 03 Aug 2004 19:04:53 -0400 Cc: Allison Mankin , Henk Uijterwaal , Matt Zekauskas , ippm@ietf.org, Steve Bellovin 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 "Steven M. Bellovin" writes: > Sam Weiler and Bernard Aboba > are looking at it. Sam and Bernard, The OWAMP specification document is now almost ready for working group last call (and implemented by several people, including a SONET hardware implementation of OWAMP-Test). One area that bothered me was security; I did not feel like it received adequate review. In order to catch potential problems earlier rather than at the stage of IESG review, we asked for a security review now. Should you need clarifications, you can contact me directly (or publicly, if you wish). The results of your review, of course, should be posted to ippm@ietf.org; I wouldn't mind taking a look at them beforehand, but it's up to you. Keep in mind that the requirements document for OWAMP is RFC 3763. The changes that are currently pending according to my TODO file (I plan to make them when submissions are accepted again) are as follows: - decide whether to communicate actual start time explicitly via OWAMP-Control - change order of error estimate and timestamp, per Henk - remove start-in-the-past feature - add to security consideration required properties of AES and CBC mode - clarify behavior of sender in case of scheduling delays - acknowledgments section - id-nits None of them should materially affect the security of the protocol. At an early stage in designing the protocol, we considered using TLS and IPsec as cryptographic security mechanisms for OWAMP. The disadvantages of those are as follows (not an exhaustive list): Regarding TLS: * Could be used to secure TCP-based OWAMP-Control, but difficult to use to secure UDP-based OWAMP-Test: OWAMP-Test packets, if lost, are not resent, so packets have to be (optionally) encrypted and authenticated while retaining individual usability. Stream-based TLS is not conducive of this. * Dealing with streams, does not authenticate individual messages (even in OWAMP-Control). The easiest way out would be to add some known-format padding to each message and verify that the format of the padding is intact before using the message. The solution would thus lose some of its appeal (``just use TLS''); it would also be much more difficult to evaluate the security of this scheme with the various modes and options of TLS---it would almost certainly not be secure with all. The capacity of an attacker to replace parts of messages (namely, the end) with random garbage could have serious security implications and would need to be analyzed carefully: suppose, for example, that a parameter that is used in some form to control the rate were replaced by random garbage---chances are the result (an unsigned integer) would be quite large. * Dependent on the mode of use, one can end up with a requirement for certificates for all users and a PKI. Even if one is to accept that PKI is desirable, there just isn't a usable one today. * Requires a large implementation. OpenSSL, for example, is larger than the implementation of OWAMP as a whole. This can matter for embedded implementations. Regarding IPsec: * What we now call authenticated mode would not be possible (in IPsec you can't authenticate part of a packet). * The deployment paths of IPsec and OWAMP could be separate if OWAMP does not depend on IPsec. After nine years of IPsec, only 0.05% of traffic on an advanced network such as Abilene is IPsec (for comparison purposes with encryption above layer 4, SSH is 2-4% and HTTPS is 0.2-0.6%). It is desirable to be able to deploy OWAMP on as large of a number of different platforms as possible. * The deployment problems of a protocol dependent on IPsec would be especially acute in the case of lightweight embedded devices. Ethernet switches, DSL ``modems,'' and other such devices mostly do not support IPsec. * The API for manipulation IPsec from an application is poorly understood. Writing a program that needs to encrypt some packets, authenticate some packets, and leave some open---for the same destination---would become more of an exercise in IPsec rather than IP measurement. For the enumerated reasons, we decided to use a simple cryptographic protocol that is different from TLS and IPsec. Thank you very much for agreeing to review, -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Just my 0.086g of Ag. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Aug 4 19:58:29 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 TAA21625 for ; Wed, 4 Aug 2004 19:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVZ7-0006nC-0q; Wed, 04 Aug 2004 19:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVPa-0004ZT-6q for ippm@megatron.ietf.org; Wed, 04 Aug 2004 19:43:10 -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 TAA20669 for ; Wed, 4 Aug 2004 19:43:08 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsVSw-0002uM-Kj for ippm@ietf.org; Wed, 04 Aug 2004 19:46:40 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 610A44FC1B; Thu, 5 Aug 2004 01:42:37 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C91A84ED2E for ; Thu, 5 Aug 2004 01:42:36 +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 i74NgaW7021175 for ; Thu, 5 Aug 2004 01:42:36 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i74NgaJH011035 for ; Thu, 5 Aug 2004 01:42:36 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Thu, 5 Aug 2004 01:42:36 +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.000132 / 0.0 / 0.0 / disabled X-RIPE-Signature: b5ed9a4509dd4589b6237363fa9994a7 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [ippm] The next steps for the 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, Following the IPPM WG meeting in San Diego, the chairs of the WG met with (some of) the authors of the 2 reordering metrics currently under discussion in the IPPM WG, in order to discuss the next steps. The drafts are: draft #1: draft-ietf-ippm-reordering-06.txt draft #2: draft-jayasumana-reorder-density-03.txt We agreed that merging the 2 drafts will be close to impossible due to differences in the basic definitions. We also concluded that both drafts contain metrics that are relevant for applications that have to deal with reordering. However, in this area, more study is needed for the second draft. This research is in progress. We think that the best way forward is: 1. Add a statement to the introduction of the first draft saying that the current metrics are limited to those that provide some clear insight into network characterization or receiver design, and are not likely to be exhaustive in their coverage of the applications with respect to packet reordering effects. Likewise, additional measurements may be possible. 2. Finalize the first draft and publish as a standard track RFC 3. Suggest to the WG to take the second draft up as a WG item. 4. When the research related to the second draft is done, publish the second draft as either an experimental RFC, or as a followup to the first RFC. For technical details regarding this discussion, please refer to earlier postings. Comments to the list please, 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Aug 4 20:02:35 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 UAA21935 for ; Wed, 4 Aug 2004 20:02:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVd5-0007QF-Ia; Wed, 04 Aug 2004 19:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVTO-0005Gc-QS for ippm@megatron.ietf.org; Wed, 04 Aug 2004 19:47:06 -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 TAA20966 for ; Wed, 4 Aug 2004 19:47:05 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsVWl-0002zt-Fq for ippm@ietf.org; Wed, 04 Aug 2004 19:50:36 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id B9E394FD38; Thu, 5 Aug 2004 01:46:34 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 72B9F4FD10 for ; Thu, 5 Aug 2004 01:46:34 +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 i74NkYW7022449 for ; Thu, 5 Aug 2004 01:46:34 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i74NkYbC011218 for ; Thu, 5 Aug 2004 01:46:34 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Thu, 5 Aug 2004 01:46:34 +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: 7a708657ffee6981188a08bde7c66663 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [ippm] Bandwidth 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 IPPM group, After Monday's call for an editor for the bandwidth draft, Phil Chimento has voluntered for the job. 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Aug 10 03:42:39 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 DAA28980 for ; Tue, 10 Aug 2004 03:42:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuREJ-0003qj-Ux; Tue, 10 Aug 2004 03:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuR72-0002a1-Is for ippm@megatron.ietf.org; Tue, 10 Aug 2004 03:32: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 DAA28294; Tue, 10 Aug 2004 03:31:58 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuRBW-0006Nd-Ga; Tue, 10 Aug 2004 03:36:39 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 22A501CD689; Tue, 10 Aug 2004 03:31:58 -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 22210-03; Tue, 10 Aug 2004 03:31:58 -0400 (EDT) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 93B861CD5E3; Tue, 10 Aug 2004 03:31:57 -0400 (EDT) Date: Tue, 10 Aug 2004 03:31:56 -0400 From: Matthew J Zekauskas To: proceedings@ietf.org Message-ID: 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: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: Henk Uijterwaal , Matt Zekauskas , ippm@ietf.org Subject: [ippm] Presentations from IPPM session at IETF 60 in San Diego 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 All the presentations are linked off of The minutes still in preparation. --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Aug 10 16:31:30 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 QAA01420 for ; Tue, 10 Aug 2004 16:31:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bucle-0004UC-2Z; Tue, 10 Aug 2004 15:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BucV0-0000Gk-Ot; Tue, 10 Aug 2004 15:41:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24869; Tue, 10 Aug 2004 15:41:28 -0400 (EDT) Message-Id: <200408101941.PAA24869@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 10 Aug 2004 15:41:28 -0400 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION: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 --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-07.txt Pages : 33 Date : 2004-8-10 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. 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 with purely receiver analysis orientation. 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-07.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-07.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-07.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-8-10160453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-10160453.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 Mon Aug 16 04:58:13 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 EAA19230 for ; Mon, 16 Aug 2004 04:58: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 1Bwd8D-0008NQ-6p; Mon, 16 Aug 2004 04:46:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwd5v-0007td-0g for ippm@megatron.ietf.org; Mon, 16 Aug 2004 04:43:55 -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 EAA18578 for ; Mon, 16 Aug 2004 04:43:53 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwdBc-0004u1-A3 for ippm@ietf.org; Mon, 16 Aug 2004 04:49:52 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 48C984E313; Mon, 16 Aug 2004 10:43:19 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DFEEF4E087 for ; Mon, 16 Aug 2004 10:43:18 +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 i7G8hIW7007931 for ; Mon, 16 Aug 2004 10:43:18 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i7G8hIbR030126 for ; Mon, 16 Aug 2004 10:43:18 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 16 Aug 2004 10:43:18 +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: 645a42a8c69c7db47482cdeb562e1335 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [ippm] 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, 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Aug 25 09:21: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 JAA13057 for ; Wed, 25 Aug 2004 09:21: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 1BzxBG-0006T9-Eq; Wed, 25 Aug 2004 08:47:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzjz9-00036X-Og for ippm@megatron.ietf.org; Tue, 24 Aug 2004 18:41:52 -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 SAA19964 for ; Tue, 24 Aug 2004 18:41:39 -0400 (EDT) Received: from [69.84.11.62] (helo=mail.qosmetrics.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bzjzf-0002eq-9d for ippm@ietf.org; Tue, 24 Aug 2004 18:42:20 -0400 Received: (qmail 3999 invoked from network); 24 Aug 2004 22:41:26 -0000 Received: from unknown (HELO yves) (69.84.11.62) by bugs.internal.qosmetrics.com with SMTP; 24 Aug 2004 22:41:26 -0000 Message-ID: <026401c48a2b$5c7ae040$870110ac@yves> From: "Yves Cognet" To: Date: Wed, 25 Aug 2004 00:40:31 +0200 MIME-Version: 1.0 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.8 (/) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 X-Mailman-Approved-At: Wed, 25 Aug 2004 08:47:09 -0400 Cc: STEPHAN Emile FTRD/DAC/LAN , joeo@qosmetrics.com Subject: [ippm] Implementation report X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yves Cognet List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1902945371==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============1902945371== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0260_01C48A3C.1FE6B260" This is a multi-part message in MIME format. ------=_NextPart_000_0260_01C48A3C.1FE6B260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all I'm not sure this is the right channel, but we do have an iplementation of IPPM and you will find some more detail herafter. We are working closely with FT R&D Emile Stephan on several subjects including the IPPM MIB. Feel free to contact me or us regards Yves Cognet President yves_cognet@qosmetrics.com General ======= Name of Implementation: NetWarrior Organization: QoSmetrics, SA. Contact details: QoSmetrics, Inc. Joe Ovanesian VP Engineering 802 Calle Plano Camarillo, CA 93012 USA joe_ovanesian@qosmetrics.com www.qosmetrics.com Origin of code: Written from scratch. Platform: Last release run on Linux 2.4.22 Hardware time stamping engine TSE (tx and rx) with built-in GPS and TXC0 This platform is running IPv4 and IPv6, PPPoE with both static, dynamic and Nated IP address. The platform has been tested in both ipv4 and ipv6 environment (except PPPoE) Metrics considered ---------------------------- RFC2330 IPPM sync method RFC2678 Connectivity RFC2679 One way delay RFC2680 Packet Loss RFC2681 Round trip Delay RFC2678/Type-P-Instantaneous-Bidirectional-Connectivity ------------------------------------------------------- Parameters: Implemented? + Src, the IP address of a host Yes + Dst, the IP address of a host Yes + T, a time Yes + TTL Yes + payload length Yes + TOS/DSCP Yes + VLAN Yes Units: + dT Yes Methodology: + According to section 3.1 of RFC 2678 + Synchronization via TSE card + Timestamping in hardware via TSE card Comments (Type-P): + TCP packets are being used over ipv4 and ipv6. + TCP checksum is over written when the frame is sent and when the TSE is appending the time stamp + The port numbers for test traffic can be specified + User data length is user defined + access to special IP bits ( TOS/DSCP values ) + If a packet is duplicated, any duplicates are counted (the delay of the first packet to arrives is used). + Corrupted packets are counted as lost; they will fail either a hardware CRC check, or IP or UDP checksum verification. Features included: + path variation (TTL variation) Features not implemented: Reporting the metric: + all results are recorded in an SQL database, good and bad records (lost of synchronization) + all timestamps are reported in UTC + local aggregation can be done + TTL variation are being recorded RFC2679/Type-P-One-way-Delay ---------------------------- Parameters: Implemented? + Src, the IP address of a host Yes + Dst, the IP address of a host Yes + T, a time Yes + Payload yes + VLAN ID Yes Units: + dT Yes Methodology: + According to section 3.6 of RFC 2679 + Synchronization via TSE card + Timestamping in hardware via TSE card Comments (Type-P): + UDP and TCP packets are being used over ipv4 and ipv6. + TCP checksum is over written when the frame is sent and when the TSE is appending the time stamp + The port numbers for test traffic can be specified among sessions, although for any given session port numbers were fixed + User data length was 12 bytes (32 bit sequence number, 64 bit time value) + access to special IP bits ( TOS/DSCP values ) + If a packet is duplicated, any duplicates are counted (the delay of the first packet to arrives is used). + Corrupted packets are counted as lost; they will fail either a hardware CRC check, or IP or UDP checksum verification. Features included: + If either end lost synchronization (as reported by the TSE timing card) the session is kept but results are marked invalid. + path variation (TTL variation) Features not implemented: Reporting the metric: + all results are recorded in an SQL database, good and bad records (lost of synchronization) + The loss threshold is 1 received packets for UPD traffic. + all timestamps are reported in UTC + local aggregation can be done + TTL variation are being recorded Tests performed: + calibration, measured time uncertainty is in the 450 ns range end to end once TSE cards are in sync RFC2679/Type-P-One-way-Delay-Poisson-Stream ------------------------------------------- not implemented RFC2679/Type-P-One-way-Delay-Percentile --------------------------------------- By default, the 50th percentile (median) and 90th percentile are calculated and reported for x minute intervals.(user setup) RFC2679/Type-P-One-way-Delay-Median ----------------------------------- This value can be calculated and reported from the database RFC2679/Type-P-One-way-Delay-Minimum ------------------------------------ This value is reported for x minute intervals (user setup) RFC2679/Type-P-One-way-Delay-Inverse-Percentile ----------------------------------------------- Not implemented. RFC2680/Type-P-One-way-Packet-Loss ---------------------------------- Metric Parameters: Implemented + Src, the IP address of a host Yes + Dst, the IP address of a host Yes + T, a time Yes Metric Units: + Type-P-One-way-Packet-Loss Yes Comments: + The time is the time the packet was sent, (40 nano second ticks). + Packets that arrive at the machine corrupted are dropped (CRC failure or by IP or UDP checksum failure) + If a packet is duplicated, any duplicates are ignored. RFC2680/Type-P-One-way-Packet-Loss-Poisson-Stream ------------------------------------------------- Not implemented RFC2680/Type-P-One-way-Packet-Loss-Average ------------------------------------------ Not implemented RFC2681 Round trip Delay -------------------------- Not implemented , comuted - (we make use of One Way Delay) Other features implemented -------------------------- Our system is implementing the E Model as defined by ITU for accumulated loss and jitter over period of time IPPM MIB (experimental) - the test has been done with FT R&D Lannion and San Francisco: contact name Emile Stephan IPFIX (passive monitoring) ------=_NextPart_000_0260_01C48A3C.1FE6B260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all
I'm not sure this is the right channel, = but we do=20 have an iplementation of IPPM and you will find some more detail = herafter. We=20 are working closely with FT R&D Emile Stephan on several subjects = including=20 the IPPM MIB.
Feel free to contact me or = us
regards
Yves Cognet
President
 
General
=3D=3D=3D=3D=3D=3D=3D
 
Name of=20 Implementation:      =  NetWarrior
 
Organization:        &nb= sp;      =20        QoSmetrics, SA.
 
Contact=20 details:           = ; =20       QoSmetrics,=20 Inc. 
          = ;            =       =20 Joe Ovanesian VP=20 Engineering
         &nbs= p;            = ;      =20  802 Calle=20 Plano
          &nbs= p;            = ;     =20  Camarillo, CA 93012 USA
          &nbs= p;            = ;       joe_ovanesian@qosmetrics.com=
           = ;            =      =20  www.qosmetrics.com
  =             &= nbsp;           &n= bsp;   
 
Origin of=20 code:        Written from=20 scratch.
 
Platform:         &= nbsp;      Last=20 release run on Linux=20 2.4.22
          &nb= sp;           &nbs= p;     =20 Hardware time stamping engine TSE (tx and rx) with built-in GPS and=20 TXC0
 
          &nbs= p;            = ;     =20 This platform is running IPv4 and IPv6, PPPoE with both=20 static, dynamic and Nated IP address.
          &nbs= p;            = ;     =20 The platform has been tested in both ipv4 and ipv6 environment  = (except=20 PPPoE)
 
 
Metrics=20 considered
----------------------------
RFC2330   IPPM = sync=20 method
RFC2678   Connectivity
RFC2679   One = way=20 delay
RFC2680   Packet Loss
RFC2681   Round = trip=20 Delay
 
 
RFC2678/Type-P-Instantaneous-Bidirectional-Connectivity
-----= --------------------------------------------------
Parameters: &n= bsp;           &nb= sp;           &nbs= p;      =20 Implemented?
 + Src, the IP address of a=20 host           =20 Yes
 + Dst, the IP address of a=20 host           =20 Yes
 + T, a=20 time           =20            =20             &= nbsp;   =20 Yes
 +=20 TTL           &nbs= p;            = ;     =20           =20         Yes
 + payload=20 length           &= nbsp;        =20             = Yes
 +=20 TOS/DSCP           = ;            =      =20          Yes
+=20 VLAN           &nb= sp;           &nbs= p;            = ;          =20 Yes
 
Units:
 +=20 dT            = ;            =             &= nbsp;           &n= bsp; =20 Yes
 
Methodology:
 + According to = section 3.1 of=20 RFC 2678
 + Synchronization via TSE card
 + Timestamping = in=20 hardware via TSE card
 
Comments (Type-P):
 + TCP = packets are being=20 used over ipv4 and ipv6.
 + TCP checksum is over written when = the frame=20 is sent and when the TSE is appending the time stamp
 + The port = numbers=20 for test traffic can be specified 
 + User data length is = user=20 defined 
 + access to special IP bits ( TOS/DSCP values=20 )
 + If a packet is duplicated, any duplicates are counted (the = delay=20 of
    the first packet to arrives is = used).
 +=20 Corrupted packets are counted as lost; they will
    = fail=20 either a hardware CRC check, or IP or UDP checksum = verification.
 
Features included:
 + path = variation (TTL=20 variation)
 
Features not implemented:
 
Reporting the metric:
 + all = results are=20 recorded in an SQL database, good and bad records (lost of=20 synchronization)
 + all timestamps are reported in = UTC
 + local=20 aggregation can be done
 + TTL variation are being = recorded
 

RFC2679/Type-P-One-way-Delay
----------------------------
 
Parameters:         &nb= sp;           &nbs= p;          =20 Implemented?
 + Src, the IP address of a=20 host           =20 Yes
 + Dst, the IP address of a=20 host           =20 Yes
 + T, a=20 time           &nb= sp;           &nbs= p;            = ;   =20 Yes
+=20 Payload           =             &= nbsp;           &n= bsp;       yes
+ VLAN=20 ID            = ;            =             &= nbsp;     Yes
 
Units:
 +=20 dT            = ;            =             &= nbsp;           &n= bsp;=20 Yes
 
Methodology:
 + According to section 3.6 of RFC = 2679
 +=20 Synchronization via TSE card
 + Timestamping in hardware via TSE = card
 
Comments (Type-P):
 + UDP and TCP packets are being used = over ipv4=20 and ipv6.
 + TCP checksum is over written when the frame is sent = and=20 when the TSE is appending the time stamp
 + The port numbers for = test=20 traffic can be specified
    among sessions, although = for any=20 given session port numbers were fixed 
 + User data length = was 12=20 bytes (32 bit sequence number, 64 bit time value) 
 + = access to=20 special IP bits ( TOS/DSCP values )
 + If a packet is = duplicated, any=20 duplicates are counted (the delay of
    the first = packet to=20 arrives is used).
 + Corrupted packets are counted as lost; they = will
    fail either a hardware CRC check, or IP or = UDP=20 checksum verification.
 
Features included:
 + If either end lost synchronization = (as=20 reported by the TSE
    timing card) the session is = kept but=20 results are marked invalid.
 + path variation (TTL = variation)
 
Features not implemented:
 
Reporting the metric:
 + all results are recorded in an SQL = database, good and bad records (lost of synchronization)
 + The = loss=20 threshold is 1 received packets for UPD traffic.
 + all = timestamps are=20 reported in UTC
 + local aggregation can be done
 + TTL=20 variation are being recorded
 
Tests performed:
 + calibration, measured time uncertainty = is in=20 the 450 ns range end to end once TSE cards are in sync
 

RFC2679/Type-P-One-way-Delay-Poisson-Stream
-----------------= --------------------------
not=20 implemented
 
RFC2679/Type-P-One-way-Delay-Percentile
-------------------------= --------------
By=20 default, the 50th percentile (median) and 90th percentile are calculated = and=20 reported for x minute intervals.(user setup)
 
RFC2679/Type-P-One-way-Delay-Median
-----------------------------= ------
This=20 value can be calculated and reported from the database
 

RFC2679/Type-P-One-way-Delay-Minimum
------------------------= ------------
This=20 value is reported for x minute intervals (user setup)
 

RFC2679/Type-P-One-way-Delay-Inverse-Percentile
-------------= ----------------------------------
Not=20 implemented.
 

RFC2680/Type-P-One-way-Packet-Loss
--------------------------= --------
 
Metric=20 Parameters:          &n= bsp;           &nb= sp;          =20 Implemented
 +  Src, the IP address of a=20 host           &nb= sp;       =20 Yes
 +  Dst, the IP address of a=20 host           &nb= sp;       =20 Yes
 +  T, a=20 time           &nb= sp;           &nbs= p;            = ;   =20 Yes
 
Metric Units:
 +=20 Type-P-One-way-Packet-Loss        = ;            =     =20 Yes
 
Comments:
 + The time is the time the packet was sent, (40 = nano=20 second ticks).
 + Packets that arrive at the machine corrupted = are=20 dropped (CRC failure or by IP or UDP checksum failure)
 + If a = packet is=20 duplicated, any duplicates are ignored.
 

RFC2680/Type-P-One-way-Packet-Loss-Poisson-Stream
-----------= --------------------------------------
Not=20 implemented
 
RFC2680/Type-P-One-way-Packet-Loss-Average
----------------------= --------------------
Not=20 implemented
 
RFC2681   Round trip = Delay
--------------------------
Not=20 implemented , comuted - (we make use of One Way Delay)
 

Other features implemented
--------------------------
Our = system=20 is implementing the E Model as defined by ITU for accumulated loss and = jitter=20 over period of time
IPPM MIB (experimental) - the test has been done = with FT=20 R&D Lannion and San Francisco: contact name Emile Stephan
IPFIX = (passive=20 monitoring)
------=_NextPart_000_0260_01C48A3C.1FE6B260-- --===============1902945371== 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 --===============1902945371==-- From ippm-bounces@ietf.org Fri Aug 27 02:09: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 CAA25491 for ; Fri, 27 Aug 2004 02:09: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 1C0Zrc-0004aw-5Q; Fri, 27 Aug 2004 02:05:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZrS-0004OP-Ix; Fri, 27 Aug 2004 02:05: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 CAA21669; Fri, 27 Aug 2004 02:05:16 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ZsW-00014a-Cq; Fri, 27 Aug 2004 02:06:25 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3D7A81CD85B; Fri, 27 Aug 2004 02:05:13 -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 24137-08; Fri, 27 Aug 2004 02:05:13 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id EFE9F1CD7CD; Fri, 27 Aug 2004 02:05:12 -0400 (EDT) To: Internet-Drafts Administrator , Bernard Aboba , Sam Weiler , IETF IPPM WG From: stanislav shalunov Date: 27 Aug 2004 02:05:16 -0400 Message-ID: <86acwht8tf.fsf@abel.internet2.edu> Lines: 42 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: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [ippm] draft-ietf-ippm-owdp-10.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, Would you please publish http://www.internet2.edu/~shalunov/ippm/draft-ietf-ippm-owdp-10.txt (SHA1=e29ece3a942d3501e4a4d9ec262ae04ea38a9e8b, size=110583) as an internet-draft. Bernard and Sam, This is a new version of the OWAMP specification, which you agreed to review. There are no changes that should affect the security of the protocol. However, this version significantly expands security considerations: The section more than tripled in size from less than 700 to over 2100 words. Motivations and required properties of primitives are spelled out better. Incidentally, do you know about when we might expect the review? IPPM, This version closes all issues that were raised up to and including IETF 60. The only wire format change is the switch of order of receive timestamp and its error estimate in the response to Fetch-Session. The only other substantial change is the removal of the start-in-the-past feature. - -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed with 0.06479891g of NaCl. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBQS7O5JRUn1EgN49xAQFjYQQAwJ3QwrKOIwABEMO0NJ3LRyhYVeGHjq92 k5DK6DJtcOBz6AW7tcm6XR3vQi6ha1loQgAZwjf4ulZrdK2rX0Jral4dY7+JKXfc BZkjDNU4Il1DHYZnGBXNmj4ZA4go8T5KGZtczdZMML7P50KMdeUtFu/bW38fp/+9 VRWz5rtJ1ho= =sCYS -----END PGP SIGNATURE----- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Aug 27 16:29: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 QAA05939 for ; Fri, 27 Aug 2004 16:29: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 1C0moU-0004jn-FJ; Fri, 27 Aug 2004 15:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0mcK-00061c-40; Fri, 27 Aug 2004 15:42:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29266; Fri, 27 Aug 2004 15:42:29 -0400 (EDT) Message-Id: <200408271942.PAA29266@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 27 Aug 2004 15:42:29 -0400 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-owdp-10.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-10.txt Pages : 48 Date : 2004-8-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-10.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-10.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-10.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-8-27151216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-owdp-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-owdp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-27151216.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 Aug 27 18:15: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 SAA15590 for ; Fri, 27 Aug 2004 18:15:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0onW-0003br-Pn; Fri, 27 Aug 2004 18:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0okS-00016s-1o for ippm@megatron.ietf.org; Fri, 27 Aug 2004 17:59:05 -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 RAA14074 for ; Fri, 27 Aug 2004 17:59:00 -0400 (EDT) Received: from goku.engr.colostate.edu ([129.82.224.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0olf-00063D-Lb for ippm@ietf.org; Fri, 27 Aug 2004 18:00:20 -0400 Received: from [129.82.228.162] (c201d2.engr.colostate.edu [129.82.228.162]) by goku.engr.colostate.edu (8.12.8/8.12.0.Beta7) with ESMTP id i7RLwbOB016916; Fri, 27 Aug 2004 15:58:37 -0600 (MDT) Message-ID: <412FAE8C.3080801@Colostate.edu> Date: Fri, 27 Aug 2004 15:58:36 -0600 From: Anura Jayasumana User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: shalunov@internet2.edu X-ECS-MailScanner: Found to be clean X-Spam-Score: 1.0 (+) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: ippm@ietf.org Subject: [ippm] RD and number of TCP retransmissions 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="===============0191539143==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============0191539143== Content-Type: multipart/alternative; boundary="------------050602050603020903070500" This is a multi-part message in MIME format. --------------050602050603020903070500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stanislav: Here is our response to the question you posed at the IETF meeting in San Diego. Q: "Suppose you have RD for a TCP stream. No packets were lost. How many packets were retransmitted? Assume standard TCP - for example free BSD 4.X TCP or the RFC TCP with fast retransmissions." Short answer is "Sum of RD[k] for k> C," where C is a constant that can be found for a given implementation. We consider the case in which there are no duplications or packet losses introduced by the network.. Now a detailed example with fast retransmit and delayed ACK implemented as follows: Fast retransmit ( RFC 2581): The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire. Delayed ACK (RFC1122): TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. (These criteria used, for example, in Solaris 2.6 implementation.) It means that a packet is retransmitted after it is not found in next 8 arrivals : [**, **, **, **,] . (Here a * indicates the arrival of a packet at the receiver, and a "," indicates the transmission of an ACK by the receiver. Thus, the displacement (according to RD definitions) is greater than 6 for retransmitted packets. Therefore, "Sum of (all RD[k] for k > 6) corresponds to the fraction of packets that is retransmitted." Example: Arrivals: 1 3 4 5 6 7 8 9 2 10 ACKs: 2 2 2 2 11 Receive_index: 1 2 3 4 5 6 7 8 9 10 Displacement: 0 -1 -1 -1 -1 -1 -1 -1 7 0 However, there would be a discrepancy, if 500msec is less than one-way delay or even instead of 500msec, an implementation uses lower maximum that which is less than one-way delay. In such cases, receiver may send ACK for every packet [*, *, *, *,]. We can modify the above statement to "Sum of (all RD[k] for k > 2) corresponds to the fraction of packets that is retransmitted." Example: Arrivals: 1 3 4 5 2 6 ACKs 2 2 2 2 6 7 Receive_index: 1 2 3 4 5 6 Displacement: 0 -1 -1 -1 3 0 An exception would occur to the above statements, if there is internal reordering, e.g., consider Arrivals: 1 4 5 6 7 8 9 10 2 3 ACKs: 2 2 2 2 11 Receive_index: 1 2 3 4 5 6 7 8 9 10 Displacement: 0 -2 -2 -2 -2 -2 -2 -2 7 7 Here packet 3 contributes to RD[7] component, but it is not retransmitted. Such occurrences are rare in networks (based on our measurements). We have not worked through the details of such a case yet. However, we believe that an expression for the appropriate correction due to internal reordering can be found (on going work). Comments and suggestions are always welcome... Regards! Anura P. Jayasumana Professor, Electrical & Computer Engineering and Computer Science Department of Electrical and Computer Engineering Colorado State University Fort Collins, CO 80523 Phone: (970) 491-7855 Fax: (970) 491-2249 Email: --------------050602050603020903070500 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit


Stanislav:
Here is our response to the question you posed at the IETF meeting in San Diego.

Q: "Suppose you have RD for a TCP stream. No packets were lost. How many packets were retransmitted? Assume standard TCP - for example free BSD 4.X TCP or the RFC TCP with fast retransmissions."

Short answer is    "Sum of RD[k] for k> C," where C is a constant that can be found for a given  implementation.
We consider the case in which there are no duplications or  packet losses introduced by the network.. 

Now a detailed example with fast retransmit and delayed ACK  implemented as follows:
Fast retransmit ( RFC 2581):
   The TCP sender SHOULD use the "fast retransmit" algorithm to detect
   and repair loss, based on incoming duplicate ACKs. The fast
   retransmit algorithm uses the arrival of 3 duplicate ACKs (4
   identical ACKs without the arrival of any other intervening packets)
   as an indication that a segment has been lost. After receiving 3
   duplicate ACKs, TCP performs a retransmission of what appears to be
   the missing segment, without waiting for the retransmission timer to
   expire.

Delayed ACK (RFC1122):
   TCP SHOULD implement a delayed ACK, but an ACK should not
   be excessively delayed; in particular, the delay MUST be
   less than 0.5 seconds, and in a stream of full-sized
   segments there SHOULD be an ACK for at least every second
   segment.

(These criteria used, for example, in Solaris 2.6 implementation.)


It means that a packet is retransmitted after it is not found in next 8 arrivals : [**, **, **, **,] . (Here a * indicates the arrival of a packet at the receiver, and a "," indicates the transmission of an ACK by the receiver.
Thus, the displacement (according to RD definitions) is greater than 6 for retransmitted packets.

Therefore, "Sum of (all RD[k] for k > 6) corresponds to the fraction of packets that is retransmitted."

Example:
Arrivals:       1   3   4   5   6   7   8   9   2   10
ACKs:                 2      2        2      2         11

Receive_index:  1   2   3   4   5   6   7   8   9   10
Displacement:   0  -1  -1   -1  -1  -1  -1  -1  7   0



However, there would be a discrepancy, if 500msec is less than one-way delay or even instead of 500msec, an implementation uses lower maximum that which is less than one-way delay. In such cases, receiver may send ACK for every packet [*, *, *, *,]. We can modify the above statement to

"Sum of (all RD[k] for k > 2) corresponds to the fraction of packets that is retransmitted."


Example:
Arrivals:      1   3   4   5   2   6
ACKs            2   2   2   2   6   7
Receive_index: 1   2   3   4   5   6
Displacement:   0  -1  -1   -1  3   0


An exception would occur to the above statements, if there is internal reordering, e.g., consider

Arrivals:       1   4   5   6   7   8   9   10   2   3
ACKs:                 2      2        2       2        11

Receive_index:  1   2   3   4   5   6   7   8   9   10
Displacement:   0  -2  -2   -2  -2  -2  -2  -2  7   7


Here packet 3 contributes to RD[7] component, but it is not retransmitted. Such occurrences are rare in networks (based on our measurements). We have not worked through the details of such a case yet. However, we believe that an expression for the appropriate correction due to internal reordering can be found (on going work).

Comments and suggestions are always welcome...
Regards!

Anura P. Jayasumana
Professor, Electrical & Computer Engineering
                           and Computer Science
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins, CO 80523
Phone: (970) 491-7855
Fax: (970) 491-2249
Email: <Anura.Jayasumana@Colostate.edu>
--------------050602050603020903070500-- --===============0191539143== 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 --===============0191539143==-- From ippm-bounces@ietf.org Mon Aug 30 12:37:39 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 MAA06692 for ; Mon, 30 Aug 2004 12:37:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1p4Z-00031y-4C; Mon, 30 Aug 2004 12:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1oxU-0002Bf-3n for ippm@megatron.ietf.org; Mon, 30 Aug 2004 12:24:40 -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 MAA05730 for ; Mon, 30 Aug 2004 12:24:37 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1ozH-0007qR-PT for ippm@ietf.org; Mon, 30 Aug 2004 12:26:32 -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 i7UGOb8Z019232 for ; Mon, 30 Aug 2004 09:24:38 -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 CC7A777ADC0 for ; Mon, 30 Aug 2004 12:24:36 -0400 (EDT) To: ippm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Revolution MIME-Version: 1.0 Date: Mon, 30 Aug 2004 12:24:36 -0400 Message-Id: <20040830162436.CC7A777ADC0@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [ippm] CFP for special issue of CCR on the Internet's Vital Signs 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="===============0358666222==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============0358666222== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=us-ascii Folks- I thought some of the folk on this list would be particularly interested in the following call for papers. E.g., it'd be nice to see some of the IPPM metrics used to provide some data about what the network actually looks like these days. 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) iD8DBQFBM1TEWyrrWs4yIs4RArqrAKCbNLXR0EXisaHWKERTN2vJrOJ5xACfb8VQ mAmo8OK8J0WAPWyVqeNsg3c= =XNGf -----END PGP SIGNATURE----- --=-=-=-- --===============0358666222== 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 --===============0358666222==--