From mailman-bounces@ietf.org Tue Jun 1 09:36:50 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 JAA29106 for ; Tue, 1 Jun 2004 09:36:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV67I-0003Zk-G0 for ippm-archive@lists.ietf.org; Tue, 01 Jun 2004 06:03:32 -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: Tue, 01 Jun 2004 05:09:58 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org ) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. 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 mailman-admin@ietf.org Tue Jun 1 13:52:27 2004 Received: from optimus.ietf.org ([132.151.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01925 for ; Tue, 1 Jun 2004 13:52:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BV9KB-0000mL-LD for ippm-archive@lists.ietf.org; Tue, 01 Jun 2004 09:29:03 -0400 Date: Tue, 01 Jun 2004 09:29:03 -0400 Message-ID: <20040601132903.26555.56722.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ippm-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, ippm-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 All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.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 Mon Jun 7 09:52:25 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 JAA15839 for ; Mon, 7 Jun 2004 09:52:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKP8-0007QT-9l; Mon, 07 Jun 2004 09:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXK5u-00025Z-EA for ippm@megatron.ietf.org; Mon, 07 Jun 2004 09:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14095 for ; Mon, 7 Jun 2004 09:23:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXK5t-000398-OL for ippm@ietf.org; Mon, 07 Jun 2004 09:23:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXK50-0002ks-00 for ippm@ietf.org; Mon, 07 Jun 2004 09:22:23 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1BXK4c-0002LQ-00 for ippm@ietf.org; Mon, 07 Jun 2004 09:21:58 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id CD06955C62; Mon, 7 Jun 2004 15:21:27 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 573F951EED; Mon, 7 Jun 2004 15:21:27 +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 i57DLQm0003605; Mon, 7 Jun 2004 15:21:27 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i57DLQiv005847; Mon, 7 Jun 2004 15:21:26 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 7 Jun 2004 15:21:26 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: stanislav shalunov Subject: Re: [ippm] draft-ietf-ippm-owdp-08.txt In-Reply-To: <86smedtt0t.fsf@abel.internet2.edu> Message-ID: References: <200405061527.LAA20089@ietf.org> <86smedtt0t.fsf@abel.internet2.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: U 0.451698 / 0.0 / 0.0 / disabled X-RIPE-Signature: 9195a14e89b5895659ddb6a2b965e8d7 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Stas, others, * General: The document should specify that the implementation MUST have rate limitations in unauthenticated mode (to avoid that we end up with the same discussion as the requirements doc). * Page 4, 2nd drawing. Why is the fetch_client sitting in the sending box. I'd think that results are typically requested by a machine outside the pair sender and receiver. * Section 5.1. Server Greeting: Why does one send 12 unused octets in the server greeting first? * Page 10: I cannot find the definition of MBZ anywhere. * 5.4. First sentence: this is not correct, the receiver only knows that packets were sent _if_ it knows that sending machine did send what it was supposed to send. The receiver cannot tell from the measurements if the sending machine stopped sending or all packets were lost. Same paragraph: are 0 and 1: poisson and periodic the only values that can be used here, or is this a point for future extension? * 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 * Page 18-19: 'if a receiver ... invalidated' Doesn't this mean that if the server crashes near the end, all results are suddenly invalid, even though they are perfectly good measurements? (We typically run measurements for weeks, and the chances that they are terminated by an outside source are pretty close to 1) * Page 21: the test session data. Typically, the error estimates and time stamp will be in 4 variables in the code: Send-error-estimate 16 bits Receive time stamp 32 bits (seconds), 32 bits (microseconds) Receive error estimate 16 bits To store this in the format described here one has to: - Multiply the SEE by 2^16 - Take the seconds word of the RTS and split it into 2 16 bit words - Divide the top half by 2^16 and add to the SEE - Multiply the bottom half by 2^16, store - Take the microsecond word, split in two times 16 bits - Divide the top half by 2^16 and add to the bottom half of the RTS - Multiply the bottom half by 2^16 and add to the REE. Then do exactly the opposite on the receiving side. Wouldn't it make more sense to use the first 2 word for the timestamp, then the next one for the EE. That way, most of this will be a straight copy, one only has to manipulate the SEE bits. * Page 23: Is there a technical reason to start sequence numbers with 0 and not 1? * Page 23: I've made this comment before, but I think this way to express the EE introduces a lot of complexity at a point where one wants to use the minimum number of CPU cycles. When timestamping a packet, one wants to extract a timestamp just before the packet is sent, insert it in the packet, then write the packet to the socket. Any CPU cycle between reading the time stamp and writing the packet means introducing a delay and making the measurement less accurate. Using this method, one has to do a lot of calculations to file the word, if we'd use RFC 1305 timestamps for everything, the operation would be reduced to a simple copy. Also, implementations of the metrics where the ethernet card inserts the timestamp have been suggested. In this case, it is impossible to use this method for inserting errors. 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 Jun 8 11:42:51 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 LAA03324 for ; Tue, 8 Jun 2004 11:42:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXicW-0003BZ-JJ; Tue, 08 Jun 2004 11:34:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXhy7-0001pA-74 for ippm@megatron.ietf.org; Tue, 08 Jun 2004 10:52:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00801 for ; Tue, 8 Jun 2004 10:52:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXhy6-0003X8-E8 for ippm@ietf.org; Tue, 08 Jun 2004 10:52:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXhwt-0002lT-00 for ippm@ietf.org; Tue, 08 Jun 2004 10:51:35 -0400 Received: from frontend-1.cgpmail.ua.pt ([193.136.80.80]) by ietf-mx with esmtp (Exim 4.12) id 1BXhw7-0001cY-00 for ippm@ietf.org; Tue, 08 Jun 2004 10:50:48 -0400 X-UA-Spam: No X-UA-Spam-Status: hits=-5.0 required=5.0 X-UA-Spam-Report: BAYES_44 USER_IN_WHITELIST Received: from [193.136.92.53] (HELO av.it.pt) by frontend-1.cgpmail.ua.pt (CommuniGate Pro SMTP 4.1.8) with ESMTP id 23456619; Tue, 08 Jun 2004 15:50:14 +0100 X-TFF-CGPSA-Version: 1.3.2 X-ITAV-Filter: Scanned Received: from [193.136.93.149] (account ) by av.it.pt (CommuniGate Pro WebUser 4.0.5) with HTTP id 1398565; Tue, 08 Jun 2004 15:50:12 +0100 From: "=?ISO-8859-1?Q?H=E9lder?= Veiga e Teresa Pinho" To: "Jeff W. Boote" X-Mailer: CommuniGate Pro Web Mailer v.4.0.5 Date: Tue, 08 Jun 2004 15:50:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA00801 X-Mailman-Approved-At: Tue, 08 Jun 2004 11:34:29 -0400 Cc: =?ISO-8859-1?Q?Ant=F3nio?= Nogueira , ankarp@yahoo.com, Paulo Salvador Ferreira , matt@internet2.edu, ippm@ietf.org, rv@det.ua.pt, ben@internet2.edu, jlo@det.ua.pt, shalunov@internet2.edu Subject: [ippm] OWAMP implementation X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear Jeff, We have been carrying out conformance tests between our=20 OWAMP implementation and yours. Fortunately for us :)=20 almost all the tests were successful. We still have the=20 following problems: 1. Definition of Timestamp.=20 The date received and decoded in our system doesn?t match=20 with what we are expecting (it represents a date in the=20 past - year 1938 - when we are in year 2004). Maybe there=20 is a problem with the function we are using to decode the=20 time value in the timestamp received (below we send our=20 function). In this function we presume to receive the time=20 value in timestamp format, with the first 32 bits=20 representing the unsigned integer number of seconds=20 elapsed since 0h on 1 January 1900, and the next 32 bits=20 representing the fractional part of a second that has=20 elapsed since then (as it seems the specification in=20 RFC1305). Also we didn?t understand quite well your implementation.=20 Can you explain us what does the function=20 OWPTimespecToNum64? (How it converts the time received=20 with function ?gettimeofday? to Timestamp format?) We also didn?t understand why you use this part of code in=20 it: =20 while(nsec >=3D BILLION){ sec++; nsec -=3D BILLION; } =20 2. Another problem that we have with our implementation is=20 how to compute the estimate for error and synchronization.=20 We don?t know how to calculate and use the fields of the=20 Error Estimate format used in OWAMP. Can you help us on=20 it? Sorry for bother you with all these issues. Best regards. Teresa Pinho H=E9lder Veiga Jos=E9 Luis Oliveira Rui Valadas *** Our Function *** /** * This is a constructor of class Timestamp. It receives=20 a time in milliseconds since 0h 1 =20 * Jan 1970 and creates a variable of class Timestamp. * NTP2UNIX =3D (70 * 365 + 17) * 86400 Seconds between=20 1900-01-01 and 1970-01-01 * @param secondsSince0h1Jan1970 long */ public Timestamp(long milliSecondsSince0h1Jan1970){ long milliSecondsSince0h1Jan1900 =3D=20 milliSecondsSince0h1Jan1970 + NTP2UNIX*1000; integerPartOfSeconds =3D=20 (int)(milliSecondsSince0h1Jan1900/1000); fractionalPartOfSeconds =3D=20 (int)(((milliSecondsSince0h1Jan1900)%1000)*1000); //=20 Resolution to microsecond } /** * This method returns the time in milliseconds since=20 0h 1 Jan 1970 * @param time Timestamp - time in milliseconds since=20 0h 1 Jan 1900 * @return long - time in milliseconds since 0h 1 Jan=20 1970 */ public long timeInMillisecondsSince1970(Timestamp=20 time){ return ((long)(((long)time.integerPartOfSeconds*1000=20 )+(long)time.fractionalPartOfSeconds/1000) -=20 NTP2UNIX*1000); } *** Your Function *** /* * Function: OWPTimespecToNum64 * * Description:=09 * * Convert a time value in timespec representation to an=20 OWPNum64 * representation. These are "relative" time values.=20 (Not absolutes - i.e. * they are not relative to some "epoch".) OWPNum64=20 values are * unsigned 64 integral types with the Most Significant=20 32 of those * 64 bits representing seconds. The Least Significant=20 32 bits * represent fractional seconds at a resolution of 32=20 bits. * * In Args:=09 * * Out Args:=09 * * Scope:=09 * Returns:=09 * Side Effect:=09 */ void OWPTimespecToNum64( OWPNum64 *to, struct timespec *from ) { u_int32_t sec =3D from->tv_sec; u_int32_t nsec =3D from->tv_nsec; *to =3D 0; /* * Ensure nsec's is only fractional. */ while(nsec >=3D BILLION){ sec++; nsec -=3D BILLION; } /* * Place seconds in MS 32 bits. */ *to =3D (u_int64_t)MASK32(sec) << 32; /* * Normalize nsecs to 32bit fraction, then set that to LS=20 32 bits. */ *to |=3D MASK32(((u_int64_t)nsec << 32)/BILLION); return; } _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 8 20:01:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11862 for ; Tue, 8 Jun 2004 20:01:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXqRs-00012X-P9; Tue, 08 Jun 2004 19:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXj4f-00024g-99 for ippm@megatron.ietf.org; Tue, 08 Jun 2004 12:03:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04766 for ; Tue, 8 Jun 2004 12:03:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXj4e-0001mW-Ga for ippm@ietf.org; Tue, 08 Jun 2004 12:03:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXj3X-0000yT-00 for ippm@ietf.org; Tue, 08 Jun 2004 12:02:32 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1BXj2J-0007U2-00 for ippm@ietf.org; Tue, 08 Jun 2004 12:01:16 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D3248328B; Tue, 8 Jun 2004 12:01:15 -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 01363-05; Tue, 8 Jun 2004 12:01:15 -0400 (EDT) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AA72330F7; Tue, 8 Jun 2004 12:01:14 -0400 (EDT) Message-ID: <40C5E2CE.29F4A388@internet2.edu> Date: Tue, 08 Jun 2004 10:01:18 -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: =?iso-8859-1?Q?H=E9lder?= Veiga e Teresa Pinho References: Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA04766 X-Mailman-Approved-At: Tue, 08 Jun 2004 19:55:59 -0400 Cc: =?iso-8859-1?Q?Ant=F3nio?= Nogueira , ankarp@yahoo.com, Paulo Salvador Ferreira , matt@internet2.edu, ippm@ietf.org, rv@det.ua.pt, ben@internet2.edu, jlo@det.ua.pt, shalunov@internet2.edu Subject: [ippm] Re: OWAMP implementation 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 H=E9lder Veiga e Teresa Pinho wrote: > 1. Definition of Timestamp. > The date received and decoded in our system doesn?t match > with what we are expecting (it represents a date in the > past - year 1938 - when we are in year 2004). Maybe there > is a problem with the function we are using to decode the > time value in the timestamp received (below we send our > function). In this function we presume to receive the time > value in timestamp format, with the first 32 bits > representing the unsigned integer number of seconds > elapsed since 0h on 1 January 1900, and the next 32 bits > representing the fractional part of a second that has > elapsed since then (as it seems the specification in > RFC1305). You say unsigned here, but in your implementation you cast to (int) in a = number of places. This is highly suspect... > Also we didn?t understand quite well your implementation. > Can you explain us what does the function > OWPTimespecToNum64? (How it converts the time received > with function ?gettimeofday? to Timestamp format?) > We also didn?t understand why you use this part of code in > it: >=20 > while(nsec >=3D BILLION){ > sec++; > nsec -=3D BILLION; > } The function you pulled out is not used to create a true timestamp. It is= used to create a relative time value. There are places in the implementation w= here I do arithmetic on time values. Sometimes I do that with timespec structure= s. If I add two timespec structures - it could be possible to get more than 1 bil= lion nsec's in the tv_nsec portion of the structure. This would represent more= than one second. This loop ensures that the nsec variable holds less than 1 bi= llion nsecs and therefore less than one second. This ensures I can compute the fractional part of the timestamp without overflowing. > 2. Another problem that we have with our implementation is > how to compute the estimate for error and synchronization. > We don?t know how to calculate and use the fields of the > Error Estimate format used in OWAMP. Can you help us on > it? Those fields are only useful if you are synchronizing your clock with an external standard for time. Say UTC. If you are not synchronizing the tim= e, then set the S bit to 0. I'm not sure how I could help you on it more than jus= t pointing you at the sample implementation. There are functions in there t= hat convert from a floating point double representation of the error to the f= ormat in the timestamp and back. If you have specific questions about them, I c= ould answer them. > *** Our Function *** > /** > * This is a constructor of class Timestamp. It receives > a time in milliseconds since 0h 1 > * Jan 1970 and creates a variable of class Timestamp. > * NTP2UNIX =3D (70 * 365 + 17) * 86400 Seconds between > 1900-01-01 and 1970-01-01 > * @param secondsSince0h1Jan1970 long > */ > public Timestamp(long milliSecondsSince0h1Jan1970){ > long milliSecondsSince0h1Jan1900 =3D > milliSecondsSince0h1Jan1970 + NTP2UNIX*1000; You certainly overflow right here. It takes an unsigned 32 bit integer to= hold the number of SECONDS since Jan1900. If you are counting seconds, a signe= d 32 bit integer can only go ~68 years. An unsigned can go ~136 years. (So, my= code will need something more by the year 2036 - but I hope to be retired by t= hen, or at least working on something else. ;) ) If you are counting the number of MSEC, it would be far less than 68 year= s - I'll let you do the math. In other words, you are not going to be able to= hold the number of MSEC since 1900 in a 32 bit integer. There may be other ove= rflow errors in this code... I stopped here because you already have no hope of= this working. jeff _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jun 8 20:03:03 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 UAA11981 for ; Tue, 8 Jun 2004 20:03:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXqRt-00013A-HJ; Tue, 08 Jun 2004 19:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjxx-0005qz-TC for ippm@megatron.ietf.org; Tue, 08 Jun 2004 13:00:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08326 for ; Tue, 8 Jun 2004 13:00:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjxw-00015y-UB for ippm@ietf.org; Tue, 08 Jun 2004 13:00:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjx8-0000HL-00 for ippm@ietf.org; Tue, 08 Jun 2004 12:59:59 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1BXjwF-0007Et-00 for ippm@ietf.org; Tue, 08 Jun 2004 12:59:03 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 6F4123084; Tue, 8 Jun 2004 12:59:03 -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 11335-07; Tue, 8 Jun 2004 12:59:03 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 4E38C2EF8; Tue, 8 Jun 2004 12:59:03 -0400 (EDT) To: ippm@ietf.org References: From: stanislav shalunov Date: 08 Jun 2004 12:59:12 -0400 In-Reply-To: Message-ID: <86oenuyoin.fsf@abel.internet2.edu> Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA08326 X-Mailman-Approved-At: Tue, 08 Jun 2004 19:56:00 -0400 Cc: =?koi8-r?b?QW50825pbyBOb2d1ZWly?= =?koi8-r?b?YQ==?= , Paulo Salvador Ferreira , =?koi8-r?b?SOlsZGVyIFZlaWdhIGUg?= =?koi8-r?b?VGVyZXNhIFBpbmhv?= , jlo@det.ua.pt, rv@det.ua.pt Subject: [ippm] Re: OWAMP implementation 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 [Trimmed co-authors in the CC line.] The answer to your first question is being researched. "H=E9lder Veiga e Teresa Pinho" writes: > 2. Another problem that we have with our implementation is how to > compute the estimate for error and synchronization. We don't know > how to calculate and use the fields of the Error Estimate format > used in OWAMP. Can you help us on it? Where do you get the time? From the rest of your message it seems apparent that you call gettimeofday() to read the system clock to produce timestamps. This is fine, but where does the system time come from? One approach is to use NTP. NTP, if configured properly (with at least four servers) will tell you if a clock is synchronized and what it thinks the error estimate is. If you're assuming that NTP will be used, you could propagate these values from NTP (after suitable format conversion). If you do not use NTP, the time still has to come from somewhere. The semantics of the error estimate field are defined in the specification as follows: # The Error Estimate specifies the estimate of the error and # synchronization. It has the following format: # # 0 1 # 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # |S|Z| Scale | Multiplier | # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # # The first bit S SHOULD be set if the party generating the timestamp # has a clock that is synchronized to UTC using an external source # (e.g., the bit should be set if GPS hardware is used and it indicates # that it has acquired current position and time or if NTP is used and # it indicates that it has synchronized to an external source, which # includes stratum 0 source, etc.); if there is no notion of external # synchronization for the time source, the bit SHOULD NOT be set. The # next bit has the same semantics as MBZ fields elsewhere: it MUST be # set to zero by the sender and ignored by everyone else. The next six # bits Scale form an unsigned integer; Multiplier is an unsigned # integer as well. They are interpreted as follows: the error estimate # is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation # clarification: 2^Scale is two to the power of Scale.] Multiplier # MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be # considered corrupt and discarded. So, if you read the system clock on a system with a clock untrained by NTP or anything else, the S bit SHOULD NOT be set. The Z bit is always set to zero and ignored by all data consumers. Scale and Multiplier form a number that has units of seconds and presents your best conservative guess of clock precision. If the clock is untrained, this should probably be some huge number that should, perhaps, come from configuration. --=20 Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed with 0.06479891g of NaCl. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jun 9 11:36: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 LAA21575 for ; Wed, 9 Jun 2004 11:36: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 1BY4vc-0007hf-I0; Wed, 09 Jun 2004 11:23:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4cq-0001dy-0w for ippm@megatron.ietf.org; Wed, 09 Jun 2004 11:04:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16239 for ; Wed, 9 Jun 2004 10:08:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY3ko-0001He-Od for ippm@ietf.org; Wed, 09 Jun 2004 10:08:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY3jm-0000S5-00 for ippm@ietf.org; Wed, 09 Jun 2004 10:07:31 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1BY3iu-0007Q3-00 for ippm@ietf.org; Wed, 09 Jun 2004 10:06:36 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3649E3100 for ; Wed, 9 Jun 2004 10:06: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 15331-03 for ; Wed, 9 Jun 2004 10:06:36 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 017D830FD for ; Wed, 9 Jun 2004 10:06:36 -0400 (EDT) To: ippm@ietf.org Subject: Re: [ippm] Re: OWAMP implementation References: <86oenuyoin.fsf@abel.internet2.edu> From: stanislav shalunov Date: 09 Jun 2004 10:06:10 -0400 In-Reply-To: Message-ID: <86oensvnal.fsf@abel.internet2.edu> Lines: 17 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: > Then, NTP can also be used to sync the machine to a hardware device > connected to the machine running OWAMP. In that case, there is even an > advantage in configuring NTP with just that peer. While it's not on topic for IPPM, it turns out you need at least four NTP servers to get meaningful error estimates. If you have a local stratum 0 source, that's what would normally be used because of stratum selection. (If you configure one server---wherever it is and whatever its stratum---you'll get an unrealistically low error estimate.) -- 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 Wed Jun 9 17:09: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 RAA22286 for ; Wed, 9 Jun 2004 17:09: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 1BY95F-0002ZE-F1; Wed, 09 Jun 2004 15:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4oW-0002aa-64 for ippm@megatron.ietf.org; Wed, 09 Jun 2004 11:16:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02726 for ; Wed, 9 Jun 2004 04:31:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXyUU-0004t3-Kb for ippm@ietf.org; Wed, 09 Jun 2004 04:31:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXyTk-00043Y-00 for ippm@ietf.org; Wed, 09 Jun 2004 04:30:37 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1BXySk-0002nt-00 for ippm@ietf.org; Wed, 09 Jun 2004 04:29:34 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id D4F0751EEE; Wed, 9 Jun 2004 10:29:04 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7BD5551EEA; Wed, 9 Jun 2004 10:29:04 +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 i598T4m0022663; Wed, 9 Jun 2004 10:29:04 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i598T4aD014385; Wed, 9 Jun 2004 10:29:04 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 9 Jun 2004 10:29:04 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: "Jeff W. Boote" Subject: Re: [ippm] Re: OWAMP implementation In-Reply-To: <40C5E2CE.29F4A388@internet2.edu> Message-ID: References: <40C5E2CE.29F4A388@internet2.edu> 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: 39dddf5060be5d97ef31df7cbed4a45c X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 X-Mailman-Approved-At: Wed, 09 Jun 2004 15:49:41 -0400 Cc: =?iso-8859-1?Q?Ant=F3nio?= Nogueira , ankarp@yahoo.com, Paulo Salvador Ferreira , =?iso-8859-1?Q?H=E9lder?= Veiga e Teresa Pinho , matt@internet2.edu, ippm@ietf.org, rv@det.ua.pt, ben@internet2.edu, jlo@det.ua.pt, shalunov@internet2.edu 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 On Tue, 8 Jun 2004, Jeff W. Boote wrote: > > *** Our Function *** > > /** > > * This is a constructor of class Timestamp. It receives > > a time in milliseconds since 0h 1 > > * Jan 1970 and creates a variable of class Timestamp. > > * NTP2UNIX = (70 * 365 + 17) * 86400 Seconds between > > 1900-01-01 and 1970-01-01 > > * @param secondsSince0h1Jan1970 long > > */ > > public Timestamp(long milliSecondsSince0h1Jan1970){ > > long milliSecondsSince0h1Jan1900 = > > milliSecondsSince0h1Jan1970 + NTP2UNIX*1000; > > You certainly overflow right here. It takes an unsigned 32 bit integer > to hold the number of SECONDS since Jan1900. If you are counting > seconds, a signed 32 bit integer can only go ~68 years. An unsigned can > go ~136 years. (So, my code will need something more by the year 2036 - > but I hope to be retired by then, or at least working on something else. > ;) ) (Speaking as a potential implementor): Is there any particular reason why we start on 1-1-1900 and not 1-1-1970? (as NTP does). I'd hate to do a calculation every time I read a timestamp. 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 Jun 9 17:09:49 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 RAA22312 for ; Wed, 9 Jun 2004 17:09:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY95G-0002ZJ-D4; Wed, 09 Jun 2004 15:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5Rn-0007uq-3L for ippm@megatron.ietf.org; Wed, 09 Jun 2004 11:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03073 for ; Wed, 9 Jun 2004 04:40:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXydB-0003sC-LF for ippm@ietf.org; Wed, 09 Jun 2004 04:40:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXycZ-00032k-00 for ippm@ietf.org; Wed, 09 Jun 2004 04:39:43 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1BXyba-0002CZ-00 for ippm@ietf.org; Wed, 09 Jun 2004 04:38:43 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 1FA1532FF; Wed, 9 Jun 2004 04:38:44 -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 14317-10; Wed, 9 Jun 2004 04:38:44 -0400 (EDT) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 0B24232FD; Wed, 9 Jun 2004 04:38:43 -0400 (EDT) Message-ID: <40C6CC95.E857A6FA@internet2.edu> Date: Wed, 09 Jun 2004 02:38:45 -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] Re: OWAMP implementation References: <40C5E2CE.29F4A388@internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 09 Jun 2004 15:49:41 -0400 Cc: =?iso-8859-1?Q?Ant=F3nio?= Nogueira , ankarp@yahoo.com, Paulo Salvador Ferreira , =?iso-8859-1?Q?H=E9lder?= Veiga e Teresa Pinho , matt@internet2.edu, ippm@ietf.org, rv@det.ua.pt, ben@internet2.edu, jlo@det.ua.pt, shalunov@internet2.edu 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 "Henk Uijterwaal (RIPE NCC)" wrote: > (Speaking as a potential implementor): Is there any particular reason why > we start on 1-1-1900 and not 1-1-1970? (as NTP does). We use exactly what RFC 1305 (NTP) specifies. NTP does not use 1970. In fact, it was very useful to be able to download the ntp source code and look at the time conversion functions it uses... jeff _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jun 9 17:10:00 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 RAA22331 for ; Wed, 9 Jun 2004 17:10:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY95H-0002ZR-2J; Wed, 09 Jun 2004 15:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5S5-0007uq-25 for ippm@megatron.ietf.org; Wed, 09 Jun 2004 11:57:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03058 for ; Wed, 9 Jun 2004 04:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXyd9-0003rw-Ds for ippm@ietf.org; Wed, 09 Jun 2004 04:40:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXycU-000327-00 for ippm@ietf.org; Wed, 09 Jun 2004 04:39:38 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1BXybC-0001RJ-00 for ippm@ietf.org; Wed, 09 Jun 2004 04:38:18 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 36BAD51EFE; Wed, 9 Jun 2004 10:37:50 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C2B1951EFD; Wed, 9 Jun 2004 10:37:49 +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 i598bnm0025880; Wed, 9 Jun 2004 10:37:49 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i598bnRg014679; Wed, 9 Jun 2004 10:37:49 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 9 Jun 2004 10:37:49 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: stanislav shalunov Subject: Re: [ippm] Re: OWAMP implementation In-Reply-To: <86oenuyoin.fsf@abel.internet2.edu> Message-ID: References: <86oenuyoin.fsf@abel.internet2.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: c6bbb4d3ac3cf0e27c3273448910e1a8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailman-Approved-At: Wed, 09 Jun 2004 15:49:41 -0400 Cc: =?koi8-r?b?QW50825pbyBOb2d1ZWly?= =?koi8-r?b?YQ==?= , Paulo Salvador Ferreira , =?koi8-r?b?SOlsZGVyIFZlaWdhIGUg?= =?koi8-r?b?VGVyZXNhIFBpbmhv?= , rv@det.ua.pt, ippm@ietf.org, jlo@det.ua.pt 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 On Tue, 8 Jun 2004, stanislav shalunov wrote: > [Trimmed co-authors in the CC line.] > > The answer to your first question is being researched. > > "H=E9lder Veiga e Teresa Pinho" writes: > > > 2. Another problem that we have with our implementation is how to > > compute the estimate for error and synchronization. We don't know > > how to calculate and use the fields of the Error Estimate format > > used in OWAMP. Can you help us on it? > > Where do you get the time? From the rest of your message it seems > apparent that you call gettimeofday() to read the system clock to > produce timestamps. This is fine, but where does the system time come > from? One approach is to use NTP. NTP, if configured properly (with > at least four servers) will tell you if a clock is synchronized and > what it thinks the error estimate is. This is not entirely correct. Not only the number of peers matters, their location is important as well. One NTP peer on the same network segment will give better results than 4 peers farther away. In fact, NTP might not even use those peers (except as a backup). Then, NTP can also be used to sync the machine to a hardware device connected to the machine running OWAMP. In that case, there is even an advantage in configuring NTP with just that peer. Henk ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.ne= t 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)= =2E _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jun 10 02:46:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08884 for ; Thu, 10 Jun 2004 02:46:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYJAe-0005H4-3z; Thu, 10 Jun 2004 02:36:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYJ52-0003ik-J0 for ippm@megatron.ietf.org; Thu, 10 Jun 2004 02:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08229 for ; Thu, 10 Jun 2004 02:30:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYJ4z-0003rO-Og for ippm@ietf.org; Thu, 10 Jun 2004 02:30:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYJ3y-0002p4-00 for ippm@ietf.org; Thu, 10 Jun 2004 02:29:23 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1BYJ2u-0001NL-00 for ippm@ietf.org; Thu, 10 Jun 2004 02:28:16 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id AE2AB4E33C; Thu, 10 Jun 2004 08:27:47 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5B1894E1B4; Thu, 10 Jun 2004 08:27:47 +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 i5A6Rlm0018642; Thu, 10 Jun 2004 08:27:47 +0200 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i5A6RlIU010030; Thu, 10 Jun 2004 08:27:47 +0200 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Thu, 10 Jun 2004 08:27:47 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: "Jeff W. Boote" Subject: Re: [ippm] Re: OWAMP implementation In-Reply-To: <40C6CC95.E857A6FA@internet2.edu> Message-ID: References: <40C5E2CE.29F4A388@internet2.edu> <40C6CC95.E857A6FA@internet2.edu> 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: ff88c369b149cf7cecf4a7ed54789917 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 On Wed, 9 Jun 2004, Jeff W. Boote wrote: > "Henk Uijterwaal (RIPE NCC)" wrote: > > (Speaking as a potential implementor): Is there any particular reason why > > we start on 1-1-1900 and not 1-1-1970? (as NTP does). > > We use exactly what RFC 1305 (NTP) specifies. NTP does not use 1970. > > In fact, it was very useful to be able to download the ntp source code and look > at the time conversion functions it uses... Oops, you're right, forget it, Henk > > jeff > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > ------------------------------------------------------------------------------ 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 Jun 29 19:02:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05841 for ; Tue, 29 Jun 2004 19:02:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfRS2-0004tz-Uu; Tue, 29 Jun 2004 18:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfROL-0001z1-26 for ippm@megatron.ietf.org; Tue, 29 Jun 2004 18:47:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04673 for ; Tue, 29 Jun 2004 18:47:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfROJ-00044f-Jw for ippm@ietf.org; Tue, 29 Jun 2004 18:47:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfRNB-0003fl-00 for ippm@ietf.org; Tue, 29 Jun 2004 18:46:41 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1BfRML-0003IG-00 for ippm@ietf.org; Tue, 29 Jun 2004 18:45:49 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D377E1CD610; Tue, 29 Jun 2004 18:45:49 -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 18858-10; Tue, 29 Jun 2004 18:45:49 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id B63E41CD4FA; Tue, 29 Jun 2004 18:45:49 -0400 (EDT) To: Roman Lapacz References: <1088434703.2108.89.camel@vaja.man.poznan.pl> From: stanislav shalunov Date: 29 Jun 2004 18:45:51 -0400 In-Reply-To: <1088434703.2108.89.camel@vaja.man.poznan.pl> Message-ID: <86659augo0.fsf@abel.internet2.edu> Lines: 50 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: e2eperf-interest@internet2.edu, internet2-geant2 , ippm@ietf.org Subject: [ippm] Re: owamp protocol 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@ietf.org added to CC] Roman Lapacz writes: > very soon I will deploy OWAMP implementation in PSNC (there was the > discussion about this with Eric Boyd during Terena 2004 Conference) but > before that I would like to have a solid knowledge about OWAMP protocol > (and furthermore its implementation on the C code level). > > I've read the draft of the protocol and I have few questions. First, the > process of establishing an encrypted and authenticated connection is > rather unclear for me. I know MD5 and AES, what is for and how it works > generally, but according to the draft I can't understand exactly the use > (step-by-step) of Username, Token and Client-IV fields. Roman, I presume you're talking about the instructions in section 5.1 of draft-ietf-ippm-owdp-08.txt. Which part do you have difficulty interpreting? It would be helpful if you asked more specific questions. Username is a string, 16-octet long, used to refer to a particular shared secret. The server might be prepared to conduct encrypted sessions with more than one client. The Username tells the server which key to use. Token is described in the paragraph starting with ``Otherwise, [...]''. It is necessary to know what Cipher Block Chaining means. This has the standard meaning, i.e., the plain text of second block is XORed with the cipher text of the first block before the former is encrypted. It might help to take a look at a cryptography book to refresh the terminology. For example, the _Handbook of Applied Cryptography_ is immediately available for free in electronic format at http://www.cacr.math.uwaterloo.ca/hac/, but Bruce Schneier's _Applied Cryptography_ might be a better source. If you have more specific questions, please do not hesitate to ask them: if you have difficulty understanding something, there will be, no doubt, someone else with the same difficulty. But to make the text better and more understandable, it must be known what is the exact part that causes problems. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Sex is the mathematics urge sublimated. -- M. C. Reed. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jun 30 08:38: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 IAA13906 for ; Wed, 30 Jun 2004 08:38: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 1BfeEU-0001M9-Du; Wed, 30 Jun 2004 08:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfd4T-0000aF-2g for ippm@megatron.ietf.org; Wed, 30 Jun 2004 07:16:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09160 for ; Wed, 30 Jun 2004 07:16:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfd4S-0006Rl-H3 for ippm@ietf.org; Wed, 30 Jun 2004 07:16:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfd3R-00064b-00 for ippm@ietf.org; Wed, 30 Jun 2004 07:15:05 -0400 Received: from rose.man.poznan.pl ([150.254.173.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bfd2Q-0005bc-00 for ippm@ietf.org; Wed, 30 Jun 2004 07:14:02 -0400 Received: from [150.254.160.193] (vaja.man.poznan.pl [150.254.160.193]) (authenticated bits=0) by rose.man.poznan.pl (8.12.10/8.12.10/auth/ldap/milter/tls) with ESMTP id i5UBDsi7025634 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 30 Jun 2004 13:13:55 +0200 (CEST) From: Roman Lapacz To: stanislav shalunov In-Reply-To: <86659augo0.fsf@abel.internet2.edu> References: <1088434703.2108.89.camel@vaja.man.poznan.pl> <86659augo0.fsf@abel.internet2.edu> Content-Type: text/plain Message-Id: <1088594136.3411.57.camel@vaja.man.poznan.pl> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-1) Date: Wed, 30 Jun 2004 13:15:36 +0200 Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.1(snapshot 20020919) (rose) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 30 Jun 2004 08:30:32 -0400 Cc: e2eperf-interest@internet2.edu, internet2-geant2 , ippm@ietf.org Subject: [ippm] Re: owamp protocol 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 On Wed, 2004-06-30 at 00:45, stanislav shalunov wrote: > Roman, > > I presume you're talking about the instructions in section 5.1 of > draft-ietf-ippm-owdp-08.txt. > Which part do you have difficulty > interpreting? > > It would be helpful if you asked more specific questions. > > Username is a string, 16-octet long, used to refer to a particular > shared secret. The server might be prepared to conduct encrypted > sessions with more than one client. The Username tells the server > which key to use. Stanislav, finally, I understand section 5.1 (it took me a while :). I think (maybe I'm wrong) there should be exact information in the text that there are the same bindings 'username-secret_key' stored on both sides (client ad server) before the protocol starts. Maybe this could clarify the description of secured session establishing. Roman _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm