From matt@advanced.org Thu Dec 2 16:32:06 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12378 for ; Thu, 2 Dec 1999 16:32:05 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id QAA04659 for ippm-l@advanced.org; Thu, 2 Dec 1999 16:10:47 -0500 (EST) Received: from uni04du.unity.ncsu.edu (uni04du.unity.ncsu.edu [152.1.2.81]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id QAA06833 for ; Thu, 2 Dec 1999 16:10:46 -0500 (EST) Received: (from cwu4@localhost) by uni04du.unity.ncsu.edu (8.8.4/EC02Jan97) id QAA11902; Thu, 2 Dec 1999 16:10:44 -0500 (EST) Date: Thu, 2 Dec 1999 16:10:44 -0500 (EST) From: Chien-Lung Wu To: ippm@advanced.org cc: cwu4@eos.ncsu.edu, wu@eos.ncsu.edu Subject: One-way delay Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, all: There are a lot of discussions about one-way delay metrics on IPPM. Can anybody show me or point out how to measure one-way delay? I think many works have been done on round-trip delay. Why do we need "one-way delay"? Thanks in advance. Regards, Chien-Lung **************************************************************************** Chien-Lung Wu cwu4@eos.ncsu.edu Graduate Student of ECE (O) 919-513-1894 at North Carolina State University (H) 919-233-6724 **************************************************************************** From matt@advanced.org Fri Dec 3 09:01:04 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04022 for ; Fri, 3 Dec 1999 09:01:03 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id IAA08095 for ippm-l@advanced.org; Fri, 3 Dec 1999 08:54:23 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id IAA22371 for ; Fri, 3 Dec 1999 08:54:22 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id GAA01953 for ; Fri, 3 Dec 1999 06:54:21 -0700 (MST)] Received: [from s-il06ar.corp.mot.com (s-il06ar.corp.mot.com [199.2.152.27]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA29272 for ; Fri, 3 Dec 1999 06:54:21 -0700 (MST)] Received: by s-il06ar.corp.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Dec 1999 07:54:19 -0600 Message-ID: <8D7C90A17A94D211830100805FA785527ACE38@il06exm01.corp.mot.com> From: Grotefeld Glenn-cecl03 To: "'Chien-Lung Wu'" , ippm@advanced.org Cc: cwu4@eos.ncsu.edu, wu@eos.ncsu.edu Subject: RE: One-way delay Date: Fri, 3 Dec 1999 07:54:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" The most prevalent reason is that certain applications, such as streaming video and/or audio, are most influenced by one-way delay. Glenn Grotefeld Corporate Standards Motorola, Inc. ~-----Original Message----- ~From: Chien-Lung Wu [mailto:cwu4@unity.ncsu.edu] ~Sent: Thursday, December 02, 1999 3:11 PM ~To: ippm@advanced.org ~Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu ~Subject: One-way delay ~ ~ ~Hi, all: ~There are a lot of discussions about one-way delay metrics on ~IPPM. Can ~anybody show me or point out how to measure one-way delay? I think many ~works have been done on round-trip delay. Why do we need ~"one-way delay"? ~Thanks in advance. ~ ~Regards, ~ ~Chien-Lung ~ ~ ~*************************************************************** ~************* ~Chien-Lung Wu ~cwu4@eos.ncsu.edu ~Graduate Student of ECE (O) 919-513-1894 ~at North Carolina State University (H) 919-233-6724 ~*************************************************************** ~************* ~ ~ From matt@advanced.org Fri Dec 3 09:57:26 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01992 for ; Fri, 3 Dec 1999 09:57:25 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id JAA10702 for ippm-l@advanced.org; Fri, 3 Dec 1999 09:50:50 -0500 (EST) Received: from sjgw.ipo.att.com (gate.ipo.att.com [135.197.57.2]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id JAA28112 for ; Fri, 3 Dec 1999 09:50:48 -0500 (EST) Received: from exchsj02.ipo.att.com (exchsj02.ipo.att.com [135.197.72.7]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id GAA26264; Fri, 3 Dec 1999 06:49:35 -0800 (PST) Received: by exchsj02.ipo.att.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Dec 1999 06:51:32 -0800 Message-ID: <75BEB9AD0860D311A57B009027551386081C18@lzexchcl.ipo.att.com> From: "Glossbrenner, Kenneth C." To: "'Chien-Lung Wu'" , ippm@advanced.org Cc: "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" Subject: RE: One-way delay Date: Fri, 3 Dec 1999 06:51:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" IMHO there are no significant applications that care at all about one-way delay, they only care about round-trip delay. If, for example, the round-trip delay is X, I know of no real application that can even tell the difference between X=X/2+X/2, X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot distinguish between these three cases. If I finish my sentence and it always takes at least X time before I get a reply, how can I tell which of the aforementioned three cases was in effect? There was an undocumented agreement about this point in the ITU about a year and a half ago. One-way delay might be interesting for some telemetry applications. If an alarm goes off, the quicker it gets to the alarm monitoring station, the sooner mitigation can be initiated. Of course, one-way delay is only important to telemetry applications if the mitigation is effected out-of-band. If the mitigation is a command that returns across the same communication network that carried the alarm, then once again it doesn't matter whether the round-trip communications is X=X/2+X/2, X=X+0, or X=0+X, it still takes at least X time to effect the mitigation. (I also note that if the out-of-band mitigation is out-of-band, e.g. rolling a repair truck and if is X on the order of 100s or 1000s of milliseconds, then how much does it really help to roll trucks a few milliseconds earlier?) The reason the ITU has steadfastly defined one-way delay metrics instead of two-way delay metrics is that if you can afford to measure them (measurement requires synchronized measurement devices, see e.g. X.138 for measurement techniques), they provide additional diagnostic capabilities. If your RT-delay is high, you will want to know why, and for IP networks in particular, delay asymmetries are quite possible. If you can't afford to measure one-way, then two-way measurements divided by two are usually taken to be acceptable approximations of the one-way performance. Ken Glossbrenner -----Original Message----- From: Grotefeld Glenn-cecl03 [mailto:G.Grotefeld@motorola.com] Sent: Friday, December 03, 1999 8:54 AM To: 'Chien-Lung Wu'; ippm@advanced.org Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu Subject: RE: One-way delay The most prevalent reason is that certain applications, such as streaming video and/or audio, are most influenced by one-way delay. Glenn Grotefeld Corporate Standards Motorola, Inc. ~-----Original Message----- ~From: Chien-Lung Wu [mailto:cwu4@unity.ncsu.edu] ~Sent: Thursday, December 02, 1999 3:11 PM ~To: ippm@advanced.org ~Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu ~Subject: One-way delay ~ ~ ~Hi, all: ~There are a lot of discussions about one-way delay metrics on ~IPPM. Can ~anybody show me or point out how to measure one-way delay? I think many ~works have been done on round-trip delay. Why do we need ~"one-way delay"? ~Thanks in advance. ~ ~Regards, ~ ~Chien-Lung ~ ~ ~*************************************************************** ~************* ~Chien-Lung Wu ~cwu4@eos.ncsu.edu ~Graduate Student of ECE (O) 919-513-1894 ~at North Carolina State University (H) 919-233-6724 ~*************************************************************** ~************* ~ ~ From matt@advanced.org Fri Dec 3 10:35:11 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22448 for ; Fri, 3 Dec 1999 10:35:09 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA10671 for ippm-l@advanced.org; Fri, 3 Dec 1999 10:29:30 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id KAA10451 for ; Fri, 3 Dec 1999 10:29:28 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Dec 1999 15:29:08 +0000 To: "Glossbrenner, Kenneth C." cc: "'Chien-Lung Wu'" , ippm@advanced.org, "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" , J.Crowcroft@cs.ucl.ac.uk Subject: Re: One-way delay In-reply-to: Your message of "Fri, 03 Dec 1999 06:51:52 PST." <75BEB9AD0860D311A57B009027551386081C18@lzexchcl.ipo.att.com> Date: Fri, 03 Dec 1999 15:29:05 +0000 Message-ID: <15975.944234945@cs.ucl.ac.uk> From: Jon Crowcroft you can't always substitute 1/2 RTT for one way delay, and there are applications that require knowledge of one way delays because of _third party_ effects (rather than interaction) - e.g. electronic trading there are large nets in use now that don't have symmetric paths,. let alone delays (e.g. UDLR on satellite hops with terrestrial) - some of these are used for distribution of trading data, and might (for even regualtory reasons) require some sort of 1 way delay info. cheers jon. From matt@advanced.org Fri Dec 3 11:10:41 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10835 for ; Fri, 3 Dec 1999 11:10:40 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id LAA11683 for ippm-l@advanced.org; Fri, 3 Dec 1999 11:05:35 -0500 (EST) Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id LAA03831 for ; Fri, 3 Dec 1999 11:05:34 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.software.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id LAA01886; Fri, 3 Dec 1999 11:04:08 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525683C.00584353 ; Fri, 3 Dec 1999 11:04:03 -0500 X-Lotus-FromDomain: MITEL To: Jon Crowcroft cc: "Glossbrenner, Kenneth C." , "'Chien-Lung Wu'" , ippm@advanced.org, "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" , J.Crowcroft@cs.ucl.ac.uk Message-ID: <8525683C.0058416D.00@kanmta01.software.mitel.com> Date: Fri, 3 Dec 1999 11:04:51 -0500 Subject: Re: One-way delay Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline From: Tom Gray@MITEL on 12/03/99 11:04 AM How is it measured? Jon Crowcroft on 12/03/99 10:29:05 AM To: "Glossbrenner, Kenneth C." cc: "'Chien-Lung Wu'" , ippm@advanced.org, "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" , J.Crowcroft@cs.ucl.ac.uk (bcc: Tom Gray/Kan/Mitel) Subject: Re: One-way delay you can't always substitute 1/2 RTT for one way delay, and there are applications that require knowledge of one way delays because of _third party_ effects (rather than interaction) - e.g. electronic trading there are large nets in use now that don't have symmetric paths,. let alone delays (e.g. UDLR on satellite hops with terrestrial) - some of these are used for distribution of trading data, and might (for even regualtory reasons) require some sort of 1 way delay info. cheers jon. From matt@advanced.org Fri Dec 3 11:11:09 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11092 for ; Fri, 3 Dec 1999 11:11:07 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id LAA05982 for ippm-l@advanced.org; Fri, 3 Dec 1999 11:06:23 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id LAA03566 for ; Fri, 3 Dec 1999 11:05:56 -0500 (EST) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id RAA06125 for ; Fri, 3 Dec 1999 17:05:24 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id RAA21151 for ; Fri, 3 Dec 1999 17:05:23 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 3 Dec 1999 17:05:23 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@advanced.org Subject: RE: One-way delay In-Reply-To: <75BEB9AD0860D311A57B009027551386081C18@lzexchcl.ipo.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 3 Dec 1999, Glossbrenner, Kenneth C. wrote: > IMHO there are no significant applications that care at all about one-way > delay, they only care about round-trip delay. The fact that the application cannot see the difference, does not mean that it isn't important. > If, for example, the round-trip delay is X, I know of no real > application that can even tell the difference between X=X/2+X/2, > X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot > distinguish between these three cases. If I finish my sentence and it > always takes at least X time before I get a reply, how can I tell > which of the aforementioned three cases was in effect? That is true, but now suppose that you want to improve X. If X=X/2+X/2, then the best strategy is to spend equal amounts of effort on both paths, if X=X+0, then you better spend most of your efforts on reducing the delay in the first path. > There was an undocumented agreement about this point in the ITU about > a year and a half ago. I don't think that there is agreement on this in IPPM (and I like to see the arguments that the ITU made to to come to this agreement sometime). > If you can't afford to measure one-way, then two-way measurements > divided by two are usually taken to be acceptable approximations of > the one-way performance. For most of the 1600 pairs of delays that we regularly measure, we see an asymmetric behaviour, so if if you can't afford to measure one-way, then I don't think that you should quote one-way values at all. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). From matt@advanced.org Fri Dec 3 11:53:54 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02387 for ; Fri, 3 Dec 1999 11:53:53 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id LAA11144 for ippm-l@advanced.org; Fri, 3 Dec 1999 11:45:29 -0500 (EST) Received: from sjgw.ipo.att.com (gate.ipo.att.com [135.197.57.2]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id LAA14272 for ; Fri, 3 Dec 1999 11:45:27 -0500 (EST) Received: from exchsj02.ipo.att.com (exchsj02.ipo.att.com [135.197.72.7]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id IAA29498; Fri, 3 Dec 1999 08:44:56 -0800 (PST) Received: by exchsj02.ipo.att.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Dec 1999 08:46:53 -0800 Message-ID: <75BEB9AD0860D311A57B009027551386081C28@lzexchcl.ipo.att.com> From: "Glossbrenner, Kenneth C." To: ippm@advanced.org Cc: "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Subject: RE: One-way delay Date: Fri, 3 Dec 1999 08:47:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" *** Please see below. -----Original Message----- From: Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] Sent: Friday, December 03, 1999 11:05 AM To: ippm@advanced.org Subject: RE: One-way delay On Fri, 3 Dec 1999, Glossbrenner, Kenneth C. wrote: > IMHO there are no significant applications that care at all about one-way > delay, they only care about round-trip delay. The fact that the application cannot see the difference, does not mean that it isn't important. *** It is not important to any applications that I understand. *** If it's not important to the users of service, then *** I don't care to spend a lot of extra money to measure it. *** Synchronizing clocks with precision at opposite ends *** of a network is complex and expensive. *** The exception, as you and I both note below, is not that an *** application finds one-way delay important, but it is the need *** to diagnose and fix a problem with excessive round-trip delay. *** I would like to know more about the *** "third_party_effects" mentioned by Jon Crowcroft. I can *** imagine the relevance if the only acknowledgement back to the *** first party must come via a third party. > If, for example, the round-trip delay is X, I know of no real > application that can even tell the difference between X=X/2+X/2, > X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot > distinguish between these three cases. If I finish my sentence and it > always takes at least X time before I get a reply, how can I tell > which of the aforementioned three cases was in effect? That is true, but now suppose that you want to improve X. If X=X/2+X/2, then the best strategy is to spend equal amounts of effort on both paths, if X=X+0, then you better spend most of your efforts on reducing the delay in the first path. *** I agree that one-way delay is important in diagnosing and fixing *** round-trip delay problems. Without more details from Jon, I don't *** agree that there are major communications applications that can *** see or care about one-way delay. > There was an undocumented agreement about this point in the ITU about > a year and a half ago. I don't think that there is agreement on this in IPPM (and I like to see the arguments that the ITU made to to come to this agreement sometime). > If you can't afford to measure one-way, then two-way measurements > divided by two are usually taken to be acceptable approximations of > the one-way performance. For most of the 1600 pairs of delays that we regularly measure, we see an asymmetric behaviour, so if if you can't afford to measure one-way, then I don't think that you should quote one-way values at all. *** I agree that estimating one-way delay with half of *** round-trip delay is probably too cavalier for IP network. *** If one needs to investigate one-way delay in IP, it will *** have to be done correctly. *** Please pardon my experience with measurement of *** conventional networks. *** Ken Henk ---------------------------------------------------------------------------- -- Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------- -- The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). From matt@advanced.org Fri Dec 3 13:09:16 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12036 for ; Fri, 3 Dec 1999 13:09:15 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA12124 for ippm-l@advanced.org; Fri, 3 Dec 1999 12:59:07 -0500 (EST) Received: from mail.computerm.com (mail.computerm.com [199.46.74.3]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id MAA12662 for ; Fri, 3 Dec 1999 12:59:05 -0500 (EST) Received: from domino_01.computerm.com by mail.computerm.com via smtpd (for backup1.advanced.org [199.222.103.10]) with SMTP; 3 Dec 1999 18:02:48 UT Received: by domino_01(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525683C.006283FB ; Fri, 3 Dec 1999 12:56:03 -0500 X-Lotus-FromDomain: COMPUTERM From: "David Smrdel" To: "Glossbrenner, Kenneth C." cc: "'Chien-Lung Wu'" , ippm@advanced.org, "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" Message-ID: <8525683C.006283CE.00@domino_01> Date: Fri, 3 Dec 1999 12:56:02 -0500 Subject: RE: One-way delay Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline There are many applications that do care about one-way delay times. For instance the transfer of large amounts of data for off-site disk mirroring is a good example. The data is simply being transferred from point A to point B and that delay time is critical in establishing the necessay transmit buffer sizes. If it can be accurately determined that the propagation delay for a given network in a given direction is relatively high, then one would avoid sending Tetrabytes of data on this line because it could mean that a significant amount of time may be spent in transferring this large amount of data. This excessive transfer time would be avoided in leu of a faster line due to the high costs of dedicated long distance communication lines. You may say that if the propagation time for round-trip is high, then it is safe to assume that both directions must be slow. This has not been our experience. We see that with routed and switched networks, you have no guarantee that packets heading from point A to B will take the same path as from B to A. While in most applications that exist on campus style networks this may be insignificant, the same is not true when transferring data from New York to Los Angeles and back. "Glossbrenner, Kenneth C." on 12/03/99 09:51:52 AM To: "'Chien-Lung Wu'" , ippm@advanced.org cc: "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" (bcc: David Smrdel/ENG/Computerm) Subject: RE: One-way delay IMHO there are no significant applications that care at all about one-way delay, they only care about round-trip delay. If, for example, the round-trip delay is X, I know of no real application that can even tell the difference between X=X/2+X/2, X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot distinguish between these three cases. If I finish my sentence and it always takes at least X time before I get a reply, how can I tell which of the aforementioned three cases was in effect? There was an undocumented agreement about this point in the ITU about a year and a half ago. One-way delay might be interesting for some telemetry applications. If an alarm goes off, the quicker it gets to the alarm monitoring station, the sooner mitigation can be initiated. Of course, one-way delay is only important to telemetry applications if the mitigation is effected out-of-band. If the mitigation is a command that returns across the same communication network that carried the alarm, then once again it doesn't matter whether the round-trip communications is X=X/2+X/2, X=X+0, or X=0+X, it still takes at least X time to effect the mitigation. (I also note that if the out-of-band mitigation is out-of-band, e.g. rolling a repair truck and if is X on the order of 100s or 1000s of milliseconds, then how much does it really help to roll trucks a few milliseconds earlier?) The reason the ITU has steadfastly defined one-way delay metrics instead of two-way delay metrics is that if you can afford to measure them (measurement requires synchronized measurement devices, see e.g. X.138 for measurement techniques), they provide additional diagnostic capabilities. If your RT-delay is high, you will want to know why, and for IP networks in particular, delay asymmetries are quite possible. If you can't afford to measure one-way, then two-way measurements divided by two are usually taken to be acceptable approximations of the one-way performance. Ken Glossbrenner -----Original Message----- From: Grotefeld Glenn-cecl03 [mailto:G.Grotefeld@motorola.com] Sent: Friday, December 03, 1999 8:54 AM To: 'Chien-Lung Wu'; ippm@advanced.org Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu Subject: RE: One-way delay The most prevalent reason is that certain applications, such as streaming video and/or audio, are most influenced by one-way delay. Glenn Grotefeld Corporate Standards Motorola, Inc. ~-----Original Message----- ~From: Chien-Lung Wu [mailto:cwu4@unity.ncsu.edu] ~Sent: Thursday, December 02, 1999 3:11 PM ~To: ippm@advanced.org ~Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu ~Subject: One-way delay ~ ~ ~Hi, all: ~There are a lot of discussions about one-way delay metrics on ~IPPM. Can ~anybody show me or point out how to measure one-way delay? I think many ~works have been done on round-trip delay. Why do we need ~"one-way delay"? ~Thanks in advance. ~ ~Regards, ~ ~Chien-Lung ~ ~ ~*************************************************************** ~************* ~Chien-Lung Wu ~cwu4@eos.ncsu.edu ~Graduate Student of ECE (O) 919-513-1894 ~at North Carolina State University (H) 919-233-6724 ~*************************************************************** ~************* ~ ~ From matt@advanced.org Fri Dec 3 13:52:37 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04193 for ; Fri, 3 Dec 1999 13:52:35 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id NAA17813 for ippm-l@advanced.org; Fri, 3 Dec 1999 13:34:11 -0500 (EST) Received: from sjgw.ipo.att.com (gate.ipo.att.com [135.197.57.2]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id NAA10852 for ; Fri, 3 Dec 1999 13:34:09 -0500 (EST) Received: from exchsj02.ipo.att.com (exchsj02.ipo.att.com [135.197.72.7]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id KAA04158; Fri, 3 Dec 1999 10:33:29 -0800 (PST) Received: by exchsj02.ipo.att.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Dec 1999 10:35:26 -0800 Message-ID: <75BEB9AD0860D311A57B009027551386081C3A@lzexchcl.ipo.att.com> From: "Glossbrenner, Kenneth C." To: ippm@advanced.org Cc: "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Subject: RE: One-way delay Date: Fri, 3 Dec 1999 10:35:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I am trying to understand. The speed from start to finish for a large file transfer is first limited by the bit rate of the intervening transport. In my mind that is not a measure of the network one-way delay, but instead a measure of the capacity of the network to support throughput. I know that the time from start to finish for a large file transfer is further limited because TCP waits for acknowledgements before sending more data. Is it your contention that the one-way delay of a single packet can be estimated by calculating how much the file transfer is constrained by this acknowledgement process during a file transfer? Those acknowledgements are delayed by the round-trip delay X, regardless of how X is apportioned between the two directions, so I still fail to see how the one-way delay of individual packets could be estimated from the speed of a file transfer. Perhaps we are talking about two different things: network delay and time to execute a file transfer. Ken -----Original Message----- From: David Smrdel [mailto:dsmrdel@computerm.com] Sent: Friday, December 03, 1999 12:56 PM To: Glossbrenner, Kenneth C. Cc: 'Chien-Lung Wu'; ippm@advanced.org; Annie Gravey (E-mail); Eileen Natale (E-mail); Neal B. Seitz (E-mail) Subject: RE: One-way delay There are many applications that do care about one-way delay times. For instance the transfer of large amounts of data for off-site disk mirroring is a good example. The data is simply being transferred from point A to point B and that delay time is critical in establishing the necessay transmit buffer sizes. If it can be accurately determined that the propagation delay for a given network in a given direction is relatively high, then one would avoid sending Tetrabytes of data on this line because it could mean that a significant amount of time may be spent in transferring this large amount of data. This excessive transfer time would be avoided in leu of a faster line due to the high costs of dedicated long distance communication lines. You may say that if the propagation time for round-trip is high, then it is safe to assume that both directions must be slow. This has not been our experience. We see that with routed and switched networks, you have no guarantee that packets heading from point A to B will take the same path as from B to A. While in most applications that exist on campus style networks this may be insignificant, the same is not true when transferring data from New York to Los Angeles and back. "Glossbrenner, Kenneth C." on 12/03/99 09:51:52 AM To: "'Chien-Lung Wu'" , ippm@advanced.org cc: "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" (bcc: David Smrdel/ENG/Computerm) Subject: RE: One-way delay IMHO there are no significant applications that care at all about one-way delay, they only care about round-trip delay. If, for example, the round-trip delay is X, I know of no real application that can even tell the difference between X=X/2+X/2, X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot distinguish between these three cases. If I finish my sentence and it always takes at least X time before I get a reply, how can I tell which of the aforementioned three cases was in effect? There was an undocumented agreement about this point in the ITU about a year and a half ago. One-way delay might be interesting for some telemetry applications. If an alarm goes off, the quicker it gets to the alarm monitoring station, the sooner mitigation can be initiated. Of course, one-way delay is only important to telemetry applications if the mitigation is effected out-of-band. If the mitigation is a command that returns across the same communication network that carried the alarm, then once again it doesn't matter whether the round-trip communications is X=X/2+X/2, X=X+0, or X=0+X, it still takes at least X time to effect the mitigation. (I also note that if the out-of-band mitigation is out-of-band, e.g. rolling a repair truck and if is X on the order of 100s or 1000s of milliseconds, then how much does it really help to roll trucks a few milliseconds earlier?) The reason the ITU has steadfastly defined one-way delay metrics instead of two-way delay metrics is that if you can afford to measure them (measurement requires synchronized measurement devices, see e.g. X.138 for measurement techniques), they provide additional diagnostic capabilities. If your RT-delay is high, you will want to know why, and for IP networks in particular, delay asymmetries are quite possible. If you can't afford to measure one-way, then two-way measurements divided by two are usually taken to be acceptable approximations of the one-way performance. Ken Glossbrenner -----Original Message----- From: Grotefeld Glenn-cecl03 [mailto:G.Grotefeld@motorola.com] Sent: Friday, December 03, 1999 8:54 AM To: 'Chien-Lung Wu'; ippm@advanced.org Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu Subject: RE: One-way delay The most prevalent reason is that certain applications, such as streaming video and/or audio, are most influenced by one-way delay. Glenn Grotefeld Corporate Standards Motorola, Inc. ~-----Original Message----- ~From: Chien-Lung Wu [mailto:cwu4@unity.ncsu.edu] ~Sent: Thursday, December 02, 1999 3:11 PM ~To: ippm@advanced.org ~Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu ~Subject: One-way delay ~ ~ ~Hi, all: ~There are a lot of discussions about one-way delay metrics on ~IPPM. Can ~anybody show me or point out how to measure one-way delay? I think many ~works have been done on round-trip delay. Why do we need ~"one-way delay"? ~Thanks in advance. ~ ~Regards, ~ ~Chien-Lung ~ ~ ~*************************************************************** ~************* ~Chien-Lung Wu ~cwu4@eos.ncsu.edu ~Graduate Student of ECE (O) 919-513-1894 ~at North Carolina State University (H) 919-233-6724 ~*************************************************************** ~************* ~ ~ From matt@advanced.org Fri Dec 3 14:50:57 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02021 for ; Fri, 3 Dec 1999 14:50:56 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id OAA17473 for ippm-l@advanced.org; Fri, 3 Dec 1999 14:41:02 -0500 (EST) Received: from exchsrv1.cs.washington.edu (exchsrv1.cs.washington.edu [128.95.3.128]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id OAA18493 for ; Fri, 3 Dec 1999 14:40:54 -0500 (EST) Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.2650.21) id <4NKXX709>; Fri, 3 Dec 1999 11:40:49 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5FF00B7A@exchsrv1.cs.washington.edu> From: Stefan Savage To: "'Glossbrenner, Kenneth C.'" , ippm@advanced.org Cc: "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Subject: RE: One-way delay Date: Fri, 3 Dec 1999 11:40:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" If the measured path is the only causal channel then there is clearly no way to disambiguate between one-way delay and round-trip delay. However, it is clearly possible for an application to have more than one causal channel. Trivially, if you and I are both watching CNN, see NASDAQ plummet, and then both try to unload all of our Web stocks ASAP, then I will have an advantage if I have a shorter one-way delay to the trading floor than you. Here's a more realistic example. In an interactive multi-user network game suppose that clients send location updates both to each other and to the server (to improve responsiveness). However "operations" (e.g. checking if you killed someone) must be serialized through the server to ensure consistent state changes. To be concrete, lets draw the following picture, with server S and clients A and B: S / \ / \ / \ A-------B Now suppose that RTT(AB), RTT(AS), and RTT(BS) are equal. In addition, AB and AS have symmetric one-way delays, but DELAY(B->S) < DELAY(S->B). Client B has an advantage because if A and B enter range of each other they will both learn this fact at the same time, but B's operations will reach the server first. I'm dubious that this is a common issue today because most applications are strictly peer-to-peer or single client, single server. However, as more complicated distributed applications emerge I think this difference may matter. - Stefan -----Original Message----- From: Glossbrenner, Kenneth C. [mailto:kcgloss@ipo.att.com] Sent: Friday, December 03, 1999 8:47 AM To: ippm@advanced.org Cc: Annie Gravey (E-mail); Neal B. Seitz (E-mail) Subject: RE: One-way delay *** Please see below. -----Original Message----- From: Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] Sent: Friday, December 03, 1999 11:05 AM To: ippm@advanced.org Subject: RE: One-way delay On Fri, 3 Dec 1999, Glossbrenner, Kenneth C. wrote: > IMHO there are no significant applications that care at all about one-way > delay, they only care about round-trip delay. The fact that the application cannot see the difference, does not mean that it isn't important. *** It is not important to any applications that I understand. *** If it's not important to the users of service, then *** I don't care to spend a lot of extra money to measure it. *** Synchronizing clocks with precision at opposite ends *** of a network is complex and expensive. *** The exception, as you and I both note below, is not that an *** application finds one-way delay important, but it is the need *** to diagnose and fix a problem with excessive round-trip delay. *** I would like to know more about the *** "third_party_effects" mentioned by Jon Crowcroft. I can *** imagine the relevance if the only acknowledgement back to the *** first party must come via a third party. > If, for example, the round-trip delay is X, I know of no real > application that can even tell the difference between X=X/2+X/2, > X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot > distinguish between these three cases. If I finish my sentence and it > always takes at least X time before I get a reply, how can I tell > which of the aforementioned three cases was in effect? That is true, but now suppose that you want to improve X. If X=X/2+X/2, then the best strategy is to spend equal amounts of effort on both paths, if X=X+0, then you better spend most of your efforts on reducing the delay in the first path. *** I agree that one-way delay is important in diagnosing and fixing *** round-trip delay problems. Without more details from Jon, I don't *** agree that there are major communications applications that can *** see or care about one-way delay. > There was an undocumented agreement about this point in the ITU about > a year and a half ago. I don't think that there is agreement on this in IPPM (and I like to see the arguments that the ITU made to to come to this agreement sometime). > If you can't afford to measure one-way, then two-way measurements > divided by two are usually taken to be acceptable approximations of > the one-way performance. For most of the 1600 pairs of delays that we regularly measure, we see an asymmetric behaviour, so if if you can't afford to measure one-way, then I don't think that you should quote one-way values at all. *** I agree that estimating one-way delay with half of *** round-trip delay is probably too cavalier for IP network. *** If one needs to investigate one-way delay in IP, it will *** have to be done correctly. *** Please pardon my experience with measurement of *** conventional networks. *** Ken Henk ---------------------------------------------------------------------------- -- Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------- -- The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). From matt@advanced.org Fri Dec 3 14:52:54 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03059 for ; Fri, 3 Dec 1999 14:52:54 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id OAA19842 for ippm-l@advanced.org; Fri, 3 Dec 1999 14:46:41 -0500 (EST) Received: from sjgw.ipo.att.com (gate.ipo.att.com [135.197.57.2]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id OAA18711 for ; Fri, 3 Dec 1999 14:46:40 -0500 (EST) Received: from exchsj02.ipo.att.com (exchsj02.ipo.att.com [135.197.72.7]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id LAA07226; Fri, 3 Dec 1999 11:46:09 -0800 (PST) Received: by exchsj02.ipo.att.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Dec 1999 11:48:06 -0800 Message-ID: <75BEB9AD0860D311A57B009027551386081C45@lzexchcl.ipo.att.com> From: "Glossbrenner, Kenneth C." To: ippm@advanced.org Cc: "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Subject: RE: One-way delay Date: Fri, 3 Dec 1999 11:48:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Cool. I understand and agree. -----Original Message----- From: Stefan Savage [mailto:savage@cs.washington.edu] Sent: Friday, December 03, 1999 2:41 PM To: 'Glossbrenner, Kenneth C.'; ippm@advanced.org Cc: Annie Gravey (E-mail); Neal B. Seitz (E-mail) Subject: RE: One-way delay If the measured path is the only causal channel then there is clearly no way to disambiguate between one-way delay and round-trip delay. However, it is clearly possible for an application to have more than one causal channel. Trivially, if you and I are both watching CNN, see NASDAQ plummet, and then both try to unload all of our Web stocks ASAP, then I will have an advantage if I have a shorter one-way delay to the trading floor than you. Here's a more realistic example. In an interactive multi-user network game suppose that clients send location updates both to each other and to the server (to improve responsiveness). However "operations" (e.g. checking if you killed someone) must be serialized through the server to ensure consistent state changes. To be concrete, lets draw the following picture, with server S and clients A and B: S / \ / \ / \ A-------B Now suppose that RTT(AB), RTT(AS), and RTT(BS) are equal. In addition, AB and AS have symmetric one-way delays, but DELAY(B->S) < DELAY(S->B). Client B has an advantage because if A and B enter range of each other they will both learn this fact at the same time, but B's operations will reach the server first. I'm dubious that this is a common issue today because most applications are strictly peer-to-peer or single client, single server. However, as more complicated distributed applications emerge I think this difference may matter. - Stefan -----Original Message----- From: Glossbrenner, Kenneth C. [mailto:kcgloss@ipo.att.com] Sent: Friday, December 03, 1999 8:47 AM To: ippm@advanced.org Cc: Annie Gravey (E-mail); Neal B. Seitz (E-mail) Subject: RE: One-way delay *** Please see below. -----Original Message----- From: Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] Sent: Friday, December 03, 1999 11:05 AM To: ippm@advanced.org Subject: RE: One-way delay On Fri, 3 Dec 1999, Glossbrenner, Kenneth C. wrote: > IMHO there are no significant applications that care at all about one-way > delay, they only care about round-trip delay. The fact that the application cannot see the difference, does not mean that it isn't important. *** It is not important to any applications that I understand. *** If it's not important to the users of service, then *** I don't care to spend a lot of extra money to measure it. *** Synchronizing clocks with precision at opposite ends *** of a network is complex and expensive. *** The exception, as you and I both note below, is not that an *** application finds one-way delay important, but it is the need *** to diagnose and fix a problem with excessive round-trip delay. *** I would like to know more about the *** "third_party_effects" mentioned by Jon Crowcroft. I can *** imagine the relevance if the only acknowledgement back to the *** first party must come via a third party. > If, for example, the round-trip delay is X, I know of no real > application that can even tell the difference between X=X/2+X/2, > X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot > distinguish between these three cases. If I finish my sentence and it > always takes at least X time before I get a reply, how can I tell > which of the aforementioned three cases was in effect? That is true, but now suppose that you want to improve X. If X=X/2+X/2, then the best strategy is to spend equal amounts of effort on both paths, if X=X+0, then you better spend most of your efforts on reducing the delay in the first path. *** I agree that one-way delay is important in diagnosing and fixing *** round-trip delay problems. Without more details from Jon, I don't *** agree that there are major communications applications that can *** see or care about one-way delay. > There was an undocumented agreement about this point in the ITU about > a year and a half ago. I don't think that there is agreement on this in IPPM (and I like to see the arguments that the ITU made to to come to this agreement sometime). > If you can't afford to measure one-way, then two-way measurements > divided by two are usually taken to be acceptable approximations of > the one-way performance. For most of the 1600 pairs of delays that we regularly measure, we see an asymmetric behaviour, so if if you can't afford to measure one-way, then I don't think that you should quote one-way values at all. *** I agree that estimating one-way delay with half of *** round-trip delay is probably too cavalier for IP network. *** If one needs to investigate one-way delay in IP, it will *** have to be done correctly. *** Please pardon my experience with measurement of *** conventional networks. *** Ken Henk ---------------------------------------------------------------------------- -- Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------- -- The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). From matt@advanced.org Fri Dec 3 15:12:00 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12771 for ; Fri, 3 Dec 1999 15:11:57 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id PAA18782 for ippm-l@advanced.org; Fri, 3 Dec 1999 15:04:51 -0500 (EST) Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id PAA20247 for ; Fri, 3 Dec 1999 15:04:50 -0500 (EST) Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id OAA12656; Fri, 3 Dec 1999 14:04:20 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8625683C.006F34AE ; Fri, 3 Dec 1999 14:14:39 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Sundar Raman" To: "Glossbrenner, Kenneth C." cc: ippm@advanced.org Message-ID: <8625683C.006F32EE.00@mwgate02.mw.3com.com> Date: Fri, 3 Dec 1999 14:11:44 -0600 Subject: RE: One-way delay Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline I guess in most applications it truly is irrelevant what the one-way delay is, since the originator needs to respond to the destination (ie, round trip time is what matters). But in apps such as IP telephony, IP video, and other multimedia situations, is there not a need to determine if the message is delayed getting to the destination? I would think that this is where one-way metrics are very important. Most multi-media apps use UDP, rather than TCP. Since there's no connection, I would think that there would be high need to be able to accurately determine which leg, if any, was problematic. Also, since there's no inherent error correction in UDP, it's possible that the return leg is so delayed that we constantly assume that we need to resend the first leg also, which would be hard to trouble shoot unless we could accurately state the delays for each leg. But is there any way to REALLY determine one way delay unless we can put a clock on the packet? We can't expect to be able to sync up clocks due to skew and drift on the host machines. Even connecting them to a GPS transponder provides inaccuracy in the time the API call takes to get the time from the external device and put it into the packet. Delta determination of packet delay from a known value is probably as close as we can get (at least as well as i can imagine). Deviation from a "standard" delay, and just profiling the change in delay as more packets are sent would give some kind of a metric. Problem with this strategy is how to account for clock drift and skew, which almost all hardware (hosts) seems to have to some degree. There are other options, but still none that I would think are really feasible or practical. But I'm not really all that familiar with this topic and would defer to the experts on what's more workable. Cheers. From matt@advanced.org Fri Dec 3 15:50:41 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01798 for ; Fri, 3 Dec 1999 15:50:41 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id PAA14150 for ippm-l@advanced.org; Fri, 3 Dec 1999 15:41:20 -0500 (EST) Received: from mail.computerm.com (mail.computerm.com [199.46.74.3]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id PAA22380 for ; Fri, 3 Dec 1999 15:41:18 -0500 (EST) Received: from domino_01.computerm.com by mail.computerm.com via smtpd (for betelgeuse.advanced.org [199.222.103.10]) with SMTP; 3 Dec 1999 20:45:02 UT Received: by domino_01(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525683C.007154C5 ; Fri, 3 Dec 1999 15:37:52 -0500 X-Lotus-FromDomain: COMPUTERM From: "David Smrdel" To: "Glossbrenner, Kenneth C." cc: ippm@advanced.org, "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Message-ID: <8525683C.0071547E.00@domino_01> Date: Fri, 3 Dec 1999 15:37:51 -0500 Subject: RE: One-way delay Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Ken, In large data transfers, three things are important in determining the success of the transfer: Data transfer rate, overhead added by intervening equipment, and propagation delay. I may not have been clear in my last email. I understand that the resultant throughput is affected by all three of these items and that one can conceivably be able to determine progation delay by constraining the other two parameters. The important point that I am trying to make is that there are those of us out there who do care about one-way delay time. Realizing that acks must traverse the opposite direction of data transfer, it is still important to know what each direction's times are for we can size our transmit buffers (not the socket buffers but our own proprietary buffers) to ensure that we minimize retransmits and data queuing. If we can determine the one-way delay, it would help us in determining other parameters. My little sockets program is used to identify the time it should take for a file transfer. I am surmizing that we can use this information to derive estimated propagation delay. Dave "Glossbrenner, Kenneth C." on 12/03/99 01:35:46 PM To: ippm@advanced.org cc: "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" (bcc: David Smrdel/ENG/Computerm) Subject: RE: One-way delay I am trying to understand. The speed from start to finish for a large file transfer is first limited by the bit rate of the intervening transport. In my mind that is not a measure of the network one-way delay, but instead a measure of the capacity of the network to support throughput. I know that the time from start to finish for a large file transfer is further limited because TCP waits for acknowledgements before sending more data. Is it your contention that the one-way delay of a single packet can be estimated by calculating how much the file transfer is constrained by this acknowledgement process during a file transfer? Those acknowledgements are delayed by the round-trip delay X, regardless of how X is apportioned between the two directions, so I still fail to see how the one-way delay of individual packets could be estimated from the speed of a file transfer. Perhaps we are talking about two different things: network delay and time to execute a file transfer. Ken -----Original Message----- From: David Smrdel [mailto:dsmrdel@computerm.com] Sent: Friday, December 03, 1999 12:56 PM To: Glossbrenner, Kenneth C. Cc: 'Chien-Lung Wu'; ippm@advanced.org; Annie Gravey (E-mail); Eileen Natale (E-mail); Neal B. Seitz (E-mail) Subject: RE: One-way delay There are many applications that do care about one-way delay times. For instance the transfer of large amounts of data for off-site disk mirroring is a good example. The data is simply being transferred from point A to point B and that delay time is critical in establishing the necessay transmit buffer sizes. If it can be accurately determined that the propagation delay for a given network in a given direction is relatively high, then one would avoid sending Tetrabytes of data on this line because it could mean that a significant amount of time may be spent in transferring this large amount of data. This excessive transfer time would be avoided in leu of a faster line due to the high costs of dedicated long distance communication lines. You may say that if the propagation time for round-trip is high, then it is safe to assume that both directions must be slow. This has not been our experience. We see that with routed and switched networks, you have no guarantee that packets heading from point A to B will take the same path as from B to A. While in most applications that exist on campus style networks this may be insignificant, the same is not true when transferring data from New York to Los Angeles and back. "Glossbrenner, Kenneth C." on 12/03/99 09:51:52 AM To: "'Chien-Lung Wu'" , ippm@advanced.org cc: "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" (bcc: David Smrdel/ENG/Computerm) Subject: RE: One-way delay IMHO there are no significant applications that care at all about one-way delay, they only care about round-trip delay. If, for example, the round-trip delay is X, I know of no real application that can even tell the difference between X=X/2+X/2, X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot distinguish between these three cases. If I finish my sentence and it always takes at least X time before I get a reply, how can I tell which of the aforementioned three cases was in effect? There was an undocumented agreement about this point in the ITU about a year and a half ago. One-way delay might be interesting for some telemetry applications. If an alarm goes off, the quicker it gets to the alarm monitoring station, the sooner mitigation can be initiated. Of course, one-way delay is only important to telemetry applications if the mitigation is effected out-of-band. If the mitigation is a command that returns across the same communication network that carried the alarm, then once again it doesn't matter whether the round-trip communications is X=X/2+X/2, X=X+0, or X=0+X, it still takes at least X time to effect the mitigation. (I also note that if the out-of-band mitigation is out-of-band, e.g. rolling a repair truck and if is X on the order of 100s or 1000s of milliseconds, then how much does it really help to roll trucks a few milliseconds earlier?) The reason the ITU has steadfastly defined one-way delay metrics instead of two-way delay metrics is that if you can afford to measure them (measurement requires synchronized measurement devices, see e.g. X.138 for measurement techniques), they provide additional diagnostic capabilities. If your RT-delay is high, you will want to know why, and for IP networks in particular, delay asymmetries are quite possible. If you can't afford to measure one-way, then two-way measurements divided by two are usually taken to be acceptable approximations of the one-way performance. Ken Glossbrenner -----Original Message----- From: Grotefeld Glenn-cecl03 [mailto:G.Grotefeld@motorola.com] Sent: Friday, December 03, 1999 8:54 AM To: 'Chien-Lung Wu'; ippm@advanced.org Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu Subject: RE: One-way delay The most prevalent reason is that certain applications, such as streaming video and/or audio, are most influenced by one-way delay. Glenn Grotefeld Corporate Standards Motorola, Inc. ~-----Original Message----- ~From: Chien-Lung Wu [mailto:cwu4@unity.ncsu.edu] ~Sent: Thursday, December 02, 1999 3:11 PM ~To: ippm@advanced.org ~Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu ~Subject: One-way delay ~ ~ ~Hi, all: ~There are a lot of discussions about one-way delay metrics on ~IPPM. Can ~anybody show me or point out how to measure one-way delay? I think many ~works have been done on round-trip delay. Why do we need ~"one-way delay"? ~Thanks in advance. ~ ~Regards, ~ ~Chien-Lung ~ ~ ~*************************************************************** ~************* ~Chien-Lung Wu ~cwu4@eos.ncsu.edu ~Graduate Student of ECE (O) 919-513-1894 ~at North Carolina State University (H) 919-233-6724 ~*************************************************************** ~************* ~ ~ From matt@advanced.org Fri Dec 3 15:59:25 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06103 for ; Fri, 3 Dec 1999 15:59:23 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id PAA23316 for ippm-l@advanced.org; Fri, 3 Dec 1999 15:51:08 -0500 (EST) Received: from sjgw.ipo.att.com (gate.ipo.att.com [135.197.57.2]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id PAA19807 for ; Fri, 3 Dec 1999 15:51:06 -0500 (EST) Received: from exchsj02.ipo.att.com (exchsj02.ipo.att.com [135.197.72.7]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id MAA09638; Fri, 3 Dec 1999 12:50:35 -0800 (PST) Received: by exchsj02.ipo.att.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Dec 1999 12:52:33 -0800 Message-ID: <75BEB9AD0860D311A57B009027551386081C4E@lzexchcl.ipo.att.com> From: "Glossbrenner, Kenneth C." To: "IETF IPPM (E-mail)" Cc: "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Subject: RE: One-way delay Date: Fri, 3 Dec 1999 12:52:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" a) I still don't understand how you can free up any retransmission or queuing buffers until the acknowledgement returns (in X time, regardless of whether X=X+0, X=0+X, or X=X/2+X/2.) b) I am not saying that no one cares about one-way delay, clearly network engineers and maintenance people have to care. But other than Stephan Savage's interesting gaming application, I do not see major applications that know or care how the total round-trip delay, X, partitions across the two directions. Ken -----Original Message----- From: David Smrdel [mailto:dsmrdel@computerm.com] Sent: Friday, December 03, 1999 3:38 PM To: Glossbrenner, Kenneth C. Cc: ippm@advanced.org; Annie Gravey (E-mail); Neal B. Seitz (E-mail) Subject: RE: One-way delay Ken, In large data transfers, three things are important in determining the success of the transfer: Data transfer rate, overhead added by intervening equipment, and propagation delay. I may not have been clear in my last email. I understand that the resultant throughput is affected by all three of these items and that one can conceivably be able to determine progation delay by constraining the other two parameters. The important point that I am trying to make is that there are those of us out there who do care about one-way delay time. Realizing that acks must traverse the opposite direction of data transfer, it is still important to know what each direction's times are for we can size our transmit buffers (not the socket buffers but our own proprietary buffers) to ensure that we minimize retransmits and data queuing. If we can determine the one-way delay, it would help us in determining other parameters. My little sockets program is used to identify the time it should take for a file transfer. I am surmizing that we can use this information to derive estimated propagation delay. Dave "Glossbrenner, Kenneth C." on 12/03/99 01:35:46 PM To: ippm@advanced.org cc: "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" (bcc: David Smrdel/ENG/Computerm) Subject: RE: One-way delay I am trying to understand. The speed from start to finish for a large file transfer is first limited by the bit rate of the intervening transport. In my mind that is not a measure of the network one-way delay, but instead a measure of the capacity of the network to support throughput. I know that the time from start to finish for a large file transfer is further limited because TCP waits for acknowledgements before sending more data. Is it your contention that the one-way delay of a single packet can be estimated by calculating how much the file transfer is constrained by this acknowledgement process during a file transfer? Those acknowledgements are delayed by the round-trip delay X, regardless of how X is apportioned between the two directions, so I still fail to see how the one-way delay of individual packets could be estimated from the speed of a file transfer. Perhaps we are talking about two different things: network delay and time to execute a file transfer. Ken -----Original Message----- From: David Smrdel [mailto:dsmrdel@computerm.com] Sent: Friday, December 03, 1999 12:56 PM To: Glossbrenner, Kenneth C. Cc: 'Chien-Lung Wu'; ippm@advanced.org; Annie Gravey (E-mail); Eileen Natale (E-mail); Neal B. Seitz (E-mail) Subject: RE: One-way delay There are many applications that do care about one-way delay times. For instance the transfer of large amounts of data for off-site disk mirroring is a good example. The data is simply being transferred from point A to point B and that delay time is critical in establishing the necessay transmit buffer sizes. If it can be accurately determined that the propagation delay for a given network in a given direction is relatively high, then one would avoid sending Tetrabytes of data on this line because it could mean that a significant amount of time may be spent in transferring this large amount of data. This excessive transfer time would be avoided in leu of a faster line due to the high costs of dedicated long distance communication lines. You may say that if the propagation time for round-trip is high, then it is safe to assume that both directions must be slow. This has not been our experience. We see that with routed and switched networks, you have no guarantee that packets heading from point A to B will take the same path as from B to A. While in most applications that exist on campus style networks this may be insignificant, the same is not true when transferring data from New York to Los Angeles and back. "Glossbrenner, Kenneth C." on 12/03/99 09:51:52 AM To: "'Chien-Lung Wu'" , ippm@advanced.org cc: "Annie Gravey (E-mail)" , "Eileen Natale (E-mail)" , "Neal B. Seitz (E-mail)" (bcc: David Smrdel/ENG/Computerm) Subject: RE: One-way delay IMHO there are no significant applications that care at all about one-way delay, they only care about round-trip delay. If, for example, the round-trip delay is X, I know of no real application that can even tell the difference between X=X/2+X/2, X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot distinguish between these three cases. If I finish my sentence and it always takes at least X time before I get a reply, how can I tell which of the aforementioned three cases was in effect? There was an undocumented agreement about this point in the ITU about a year and a half ago. One-way delay might be interesting for some telemetry applications. If an alarm goes off, the quicker it gets to the alarm monitoring station, the sooner mitigation can be initiated. Of course, one-way delay is only important to telemetry applications if the mitigation is effected out-of-band. If the mitigation is a command that returns across the same communication network that carried the alarm, then once again it doesn't matter whether the round-trip communications is X=X/2+X/2, X=X+0, or X=0+X, it still takes at least X time to effect the mitigation. (I also note that if the out-of-band mitigation is out-of-band, e.g. rolling a repair truck and if is X on the order of 100s or 1000s of milliseconds, then how much does it really help to roll trucks a few milliseconds earlier?) The reason the ITU has steadfastly defined one-way delay metrics instead of two-way delay metrics is that if you can afford to measure them (measurement requires synchronized measurement devices, see e.g. X.138 for measurement techniques), they provide additional diagnostic capabilities. If your RT-delay is high, you will want to know why, and for IP networks in particular, delay asymmetries are quite possible. If you can't afford to measure one-way, then two-way measurements divided by two are usually taken to be acceptable approximations of the one-way performance. Ken Glossbrenner -----Original Message----- From: Grotefeld Glenn-cecl03 [mailto:G.Grotefeld@motorola.com] Sent: Friday, December 03, 1999 8:54 AM To: 'Chien-Lung Wu'; ippm@advanced.org Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu Subject: RE: One-way delay The most prevalent reason is that certain applications, such as streaming video and/or audio, are most influenced by one-way delay. Glenn Grotefeld Corporate Standards Motorola, Inc. ~-----Original Message----- ~From: Chien-Lung Wu [mailto:cwu4@unity.ncsu.edu] ~Sent: Thursday, December 02, 1999 3:11 PM ~To: ippm@advanced.org ~Cc: cwu4@eos.ncsu.edu; wu@eos.ncsu.edu ~Subject: One-way delay ~ ~ ~Hi, all: ~There are a lot of discussions about one-way delay metrics on ~IPPM. Can ~anybody show me or point out how to measure one-way delay? I think many ~works have been done on round-trip delay. Why do we need ~"one-way delay"? ~Thanks in advance. ~ ~Regards, ~ ~Chien-Lung ~ ~ ~*************************************************************** ~************* ~Chien-Lung Wu ~cwu4@eos.ncsu.edu ~Graduate Student of ECE (O) 919-513-1894 ~at North Carolina State University (H) 919-233-6724 ~*************************************************************** ~************* ~ ~ From matt@advanced.org Sat Dec 4 02:03:07 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14365 for ; Sat, 4 Dec 1999 02:03:06 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id BAA14255 for ippm-l@advanced.org; Sat, 4 Dec 1999 01:53:34 -0500 (EST) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id BAA10786 for ; Sat, 4 Dec 1999 01:53:32 -0500 (EST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id WAA18498; Fri, 3 Dec 1999 22:53:22 -0800 (PST) Message-Id: <199912040653.WAA18498@daffy.ee.lbl.gov> To: "Glossbrenner, Kenneth C." Cc: "IETF IPPM (E-mail)" , "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Subject: Re: One-way delay In-reply-to: Your message of Fri, 03 Dec 1999 12:52:53 PST. Date: Fri, 03 Dec 1999 22:53:22 PST From: Vern Paxson There are different roles for IPPM metrics. One is to understand how well applications might perform along a particular network path; another is to help understand why you get the performance you get. I agree that for many apps, it's round-trip delay and not one-way delay that matters. But for diagnosing problems, one-way delay (and, more so, one-way delay variation and loss) is often a lot more valuable than round-trip delay - both because routing and network path properties are often asymmetric (so one-way measurement is better at pinning down the location of problems), and because often for transport protocols the behavior of the different directions (forward, data-carrying path vs. reverse acknowledgement path) is highly relelvant. Vern From matt@advanced.org Sat Dec 4 02:13:00 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23843 for ; Sat, 4 Dec 1999 02:12:59 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id CAA09980 for ippm-l@advanced.org; Sat, 4 Dec 1999 02:08:47 -0500 (EST) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id CAA12903 for ; Sat, 4 Dec 1999 02:08:46 -0500 (EST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id XAA18564; Fri, 3 Dec 1999 23:08:35 -0800 (PST) Message-Id: <199912040708.XAA18564@daffy.ee.lbl.gov> To: "Glossbrenner, Kenneth C." Cc: "IETF IPPM (E-mail)" , "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Subject: Re: One-way delay Date: Fri, 03 Dec 1999 23:08:35 PST From: Vern Paxson Also, one of the goals for IPPM metrics is that when possible they should be composable. As you can in principle derive round-trip delay from two one-way delay measurements, this in a sense makes a one-way delay metric more fundamental than a round-trip delay metric. The fact that the composition is not in practice trivial (i.e., just adding the two measurements gets you the wrong answer, since there's some additional delay at the far end turning around the packet) is a feature, because it highlights that a round-trip measurement is not simply a network measurement but also measures something about the end host. Vern From matt@advanced.org Sat Dec 4 12:21:30 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06138 for ; Sat, 4 Dec 1999 12:21:29 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAB01178 for ippm-l@advanced.org; Sat, 4 Dec 1999 12:11:15 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id MAA01456 for ; Sat, 4 Dec 1999 12:11:13 -0500 (EST) Received: from office.ripe.net (office.ripe.net [193.0.1.97]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id SAA27108 for ; Sat, 4 Dec 1999 18:10:41 +0100 (CET) Received: from localhost (henk@localhost) by office.ripe.net (8.8.8/8.8.5) with ESMTP id SAA20961 for ; Sat, 4 Dec 1999 18:10:41 +0100 (CET) X-Authentication-Warning: office.ripe.net: henk owned process doing -bs Date: Sat, 4 Dec 1999 18:10:41 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@advanced.org Subject: RE: One-way delay In-Reply-To: <8625683C.006F32EE.00@mwgate02.mw.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 3 Dec 1999, Sundar Raman wrote: > But is there any way to REALLY determine one way delay unless we can put a clock > on the packet? We can't expect to be able to sync up clocks due to skew and > drift on the host machines. Yes, you put a GPS receiver in every measurement station and use that to synchronize the internal clock to sub-ms second levels. > Even connecting them to a GPS transponder provides inaccuracy in the > time the API call takes to get the time from the external device and > put it into the packet. The solution is to follow a slightly different approach: you add the timekeeping stuff to the O/S kernel and make sure that the internal clock of the machine (that is, the value that you get back on a gettimeofday(); call) is synchronized to the external source. When a packet has to be time-stamped, all you have to do is read out a counter on your machine and this is a fast operation. The time needed to process packets, get timestamps etc, is of the order of 0.1 ms, this is small compared to the 10...1000 ms delays that one typically sees on the Internet. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). From matt@advanced.org Sun Dec 5 13:29:12 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18508 for ; Sun, 5 Dec 1999 13:29:11 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id NAA06724 for ippm-l@advanced.org; Sun, 5 Dec 1999 13:25:11 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id NAA03611 for ; Sun, 5 Dec 1999 13:24:06 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 5 Dec 1999 18:24:02 +0000 To: "Henk Uijterwaal (RIPE-NCC)" cc: ippm@advanced.org Subject: Re: One-way delay In-reply-to: Your message of "Sat, 04 Dec 1999 18:10:41 +0100." Date: Sun, 05 Dec 1999 18:23:59 +0000 Message-ID: <2680.944418239@cs.ucl.ac.uk> From: Jon Crowcroft the same reason GPS (or other external clock fro mseperate network) is useful is a clue as to when applications don't always do that 2 way (but do a 3rd party) handshake - other networks - the e-trading exacmple is when the users use a thurd party net to actually committ any spending seperate fro mthe network used for advertsiging the share price "now".. j. From matt@advanced.org Sun Dec 5 13:29:18 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18561 for ; Sun, 5 Dec 1999 13:29:18 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id NAA04099 for ippm-l@advanced.org; Sun, 5 Dec 1999 13:21:01 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id NAA03720 for ; Sun, 5 Dec 1999 13:20:57 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 5 Dec 1999 18:20:36 +0000 To: Stefan Savage cc: "'Glossbrenner, Kenneth C.'" , ippm@advanced.org, "Annie Gravey (E-mail)" , "Neal B. Seitz (E-mail)" Subject: Re: One-way delay In-reply-to: Your message of "Fri, 03 Dec 1999 11:40:48 PST." <055A195871E5D1119F8100A0C9499B5FF00B7A@exchsrv1.cs.washington.edu> Date: Sun, 05 Dec 1999 18:20:32 +0000 Message-ID: <2637.944418032@cs.ucl.ac.uk> From: Jon Crowcroft good points - and to make this more current consider this: actually, in the RMT wg we are trying to devise TCP friendly congestion control - one way to do this is to mimic a TCP "equibvalent"£ throughput by modeling the sender as a rate adjusting algorithm rying to track a TCP rate given by the various TCP throughput equaitions (e.g. padhye et al from sigcomm 98 or more recent ones for shorter lived connectins) in these, you need to know a value for RTT on an "edge" of the multicast tree - but yo uCANNOT measure it n a scaalble way with 2 way exchanges in the same timescale as TCP ...so we are trying to figure out 3rd party ways - roger kermode disd work on this in his thesis at MIT....more ideas always welcome the games you refer to may well inciroprate GPS or other soruces of clock synch to enable true 1-way delay meaasurement tho... In message <055A195871E5D1119F8100A0C9499B5FF00B7A@exchsrv1.cs.washington.edu>, Stefan Savage typed: >>If the measured path is the only causal channel then there is clearly no way >>to disambiguate between one-way delay and round-trip delay. >> >>However, it is clearly possible for an application to have more than one >>causal channel. Trivially, if you and I are both watching CNN, see NASDAQ >>plummet, and then both try to unload all of our Web stocks ASAP, then I will >>have an advantage if I have a shorter one-way delay to the trading floor >>than you. >> >>Here's a more realistic example. In an interactive multi-user network game >>suppose that clients send location updates both to each other and to the >>server (to improve responsiveness). However "operations" (e.g. checking if >>you killed someone) must be serialized through the server to ensure >>consistent state changes. To be concrete, lets draw the following picture, >>with server S and clients A and B: >> >> S >> / \ >> / \ >> / \ >> A-------B >> >>Now suppose that RTT(AB), RTT(AS), and RTT(BS) are equal. In addition, AB >>and AS have symmetric one-way delays, but DELAY(B->S) < DELAY(S->B). Client >>B has an advantage because if A and B enter range of each other they will >>both learn this fact at the same time, but B's operations will reach the >>server first. >> >>I'm dubious that this is a common issue today because most applications are >>strictly peer-to-peer or single client, single server. However, as more >>complicated distributed applications emerge I think this difference may >>matter. >> >>- Stefan >> >>-----Original Message----- >>From: Glossbrenner, Kenneth C. [mailto:kcgloss@ipo.att.com] >>Sent: Friday, December 03, 1999 8:47 AM >>To: ippm@advanced.org >>Cc: Annie Gravey (E-mail); Neal B. Seitz (E-mail) >>Subject: RE: One-way delay >> >> >>*** Please see below. >> >>-----Original Message----- >>From: Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] >>Sent: Friday, December 03, 1999 11:05 AM >>To: ippm@advanced.org >>Subject: RE: One-way delay >> >> >>On Fri, 3 Dec 1999, Glossbrenner, Kenneth C. wrote: >> >>> IMHO there are no significant applications that care at all about one-way >>> delay, they only care about round-trip delay. >> >>The fact that the application cannot see the difference, does not mean >>that it isn't important. >> >>*** It is not important to any applications that I understand. >>*** If it's not important to the users of service, then >>*** I don't care to spend a lot of extra money to measure it. >>*** Synchronizing clocks with precision at opposite ends >>*** of a network is complex and expensive. >>*** The exception, as you and I both note below, is not that an >>*** application finds one-way delay important, but it is the need >>*** to diagnose and fix a problem with excessive round-trip delay. >> >>*** I would like to know more about the >>*** "third_party_effects" mentioned by Jon Crowcroft. I can >>*** imagine the relevance if the only acknowledgement back to the >>*** first party must come via a third party. >> >>> If, for example, the round-trip delay is X, I know of no real >>> application that can even tell the difference between X=X/2+X/2, >>> X=X+0, and X=0+X. Certainly users of 2-way video and audio cannot >>> distinguish between these three cases. If I finish my sentence and it >>> always takes at least X time before I get a reply, how can I tell >>> which of the aforementioned three cases was in effect? >> >>That is true, but now suppose that you want to improve X. If X=X/2+X/2, >>then the best strategy is to spend equal amounts of effort on both paths, >>if X=X+0, then you better spend most of your efforts on reducing the delay >>in the first path. >> >>*** I agree that one-way delay is important in diagnosing and fixing >>*** round-trip delay problems. Without more details from Jon, I don't >>*** agree that there are major communications applications that can >>*** see or care about one-way delay. >> >>> There was an undocumented agreement about this point in the ITU about >>> a year and a half ago. >> >>I don't think that there is agreement on this in IPPM (and I like to see >>the arguments that the ITU made to to come to this agreement sometime). >> >> >>> If you can't afford to measure one-way, then two-way measurements >>> divided by two are usually taken to be acceptable approximations of >>> the one-way performance. >> >>For most of the 1600 pairs of delays that we regularly measure, we see an >>asymmetric behaviour, so if if you can't afford to measure one-way, then I >>don't think that you should quote one-way values at all. >> >>*** I agree that estimating one-way delay with half of >>*** round-trip delay is probably too cavalier for IP network. >>*** If one needs to investigate one-way delay in IP, it will >>*** have to be done correctly. >>*** Please pardon my experience with measurement of >>*** conventional networks. >> >>*** Ken >> >>Henk >> >>---------------------------------------------------------------------------- >>-- >>Henk Uijterwaal Email: henk.uijterwaal@ripe.net >>RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk >>Singel 258 Phone: +31.20.535-4414, Fax -4445 >>1016 AB Amsterdam Home: +31.20.4195305 >>The Netherlands Mobile: +31.6.55861746 >>---------------------------------------------------------------------------- >>-- >> >>The Committee (...) was unable to reach a consensus that substantial merit >>was >>lacking. Thus, the appeal was deemed meritorious. (Orlando NABC >>#19). >> cheers jon From matt@advanced.org Mon Dec 6 08:40:02 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05524 for ; Mon, 6 Dec 1999 08:40:02 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id IAA04675 for ippm-l@advanced.org; Mon, 6 Dec 1999 08:32:53 -0500 (EST) Received: from mail.computerm.com (mail.computerm.com [199.46.74.3]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id IAA28024 for ; Mon, 6 Dec 1999 08:32:52 -0500 (EST) Received: from domino_01.computerm.com by mail.computerm.com via smtpd (for betelgeuse.advanced.org [204.148.2.10]) with SMTP; 6 Dec 1999 13:37:16 UT Received: by domino_01(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525683F.004A2A9C ; Mon, 6 Dec 1999 08:30:05 -0500 X-Lotus-FromDomain: COMPUTERM From: "David Smrdel" To: "Henk Uijterwaal (RIPE-NCC)" cc: ippm@advanced.org Message-ID: <8525683F.004A2A75.00@domino_01> Date: Mon, 6 Dec 1999 08:30:04 -0500 Subject: RE: One-way delay Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Henk, That is exactly how I am determining latency in the simple socket program. With the OS/2 system, we can achieve ms accuracy. I am able to use this tool to identify problematic areas in customer networks with much success. From all of the emails that I have seen on this topic, I believe that the consensus is that there is a need and purpose for one-way delay measurement...now the original question still needs to be answered...what is the best way for someone to measure it? Although I feel comfortable that my homebrew solution supports my needs, I agree that there are more elegant solutions that would also provide a higher degree of granularity. I am interested in Chien-Lung Wu's question as to what is the best approach in measuring this delay... Dave "Henk Uijterwaal (RIPE-NCC)" on 12/04/99 12:10:41 PM To: ippm@advanced.org cc: (bcc: David Smrdel/ENG/Computerm) Subject: RE: One-way delay On Fri, 3 Dec 1999, Sundar Raman wrote: > But is there any way to REALLY determine one way delay unless we can put a clock > on the packet? We can't expect to be able to sync up clocks due to skew and > drift on the host machines. Yes, you put a GPS receiver in every measurement station and use that to synchronize the internal clock to sub-ms second levels. > Even connecting them to a GPS transponder provides inaccuracy in the > time the API call takes to get the time from the external device and > put it into the packet. The solution is to follow a slightly different approach: you add the timekeeping stuff to the O/S kernel and make sure that the internal clock of the machine (that is, the value that you get back on a gettimeofday(); call) is synchronized to the external source. When a packet has to be time-stamped, all you have to do is read out a counter on your machine and this is a fast operation. The time needed to process packets, get timestamps etc, is of the order of 0.1 ms, this is small compared to the 10...1000 ms delays that one typically sees on the Internet. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). From matt@advanced.org Mon Dec 6 09:50:33 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14113 for ; Mon, 6 Dec 1999 09:50:32 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id JAA04275 for ippm-l@advanced.org; Mon, 6 Dec 1999 09:44:54 -0500 (EST) Received: from vader.runit.sintef.no (vader.runit.sintef.no [129.241.100.134]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id JAA05345 for ; Mon, 6 Dec 1999 09:44:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by vader.runit.sintef.no (8.8.8/8.8.8) with ESMTP id PAA16990; Mon, 6 Dec 1999 15:44:14 +0100 (MET) To: dsmrdel@computerm.com Cc: henk@ripe.net, ippm@advanced.org Subject: RE: One-way delay From: Havard.Eidnes@runit.sintef.no In-Reply-To: Your message of "Mon, 6 Dec 1999 08:30:04 -0500" <8525683F.004A2A75.00@domino_01> References: <8525683F.004A2A75.00@domino_01> X-Mailer: Mew version 1.93 on Emacs 19.34 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-Id: <19991206154413T.he@runit.sintef.no> Date: Mon, 06 Dec 1999 15:44:13 +0100 Sender: Havard Eidnes X-Dispatcher: imput version 980905(IM100) Lines: 21 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id JAA28359 Content-Transfer-Encoding: 8bit > From all of the emails that I have seen on this topic, I > believe that the consensus is that there is a need and purpose > for one-way delay measurement...now the original question still > needs to be answered...what is the best way for someone to > measure it? The best way for someone to measure it is (briefly) to have a measurement machine at either end of the path under study, each of them synchronized to a known good time source. See the RFCs and the Internet-drafts (if there are still any for one-way delay; I somehow doubdt it) for the nitty-gritty details. In practice, this means that it will take quite some effort in order to accurately measure the one-way delay and loss characteristics of a given path, and the technique thus isn't all that amenable to measuring these metrics for "random" paths due to the need for good infrastructure to carry out the measurements. Regards, - Håvard From matt@advanced.org Mon Dec 6 10:27:48 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02930 for ; Mon, 6 Dec 1999 10:27:48 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA04998 for ippm-l@advanced.org; Mon, 6 Dec 1999 10:22:39 -0500 (EST) Received: from exchsrv1.cs.washington.edu (exchsrv1.cs.washington.edu [128.95.3.128]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA04926 for ; Mon, 6 Dec 1999 10:22:37 -0500 (EST) Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.2650.21) id <4NKXX0LH>; Mon, 6 Dec 1999 07:22:36 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5FF00B84@exchsrv1.cs.washington.edu> From: Stefan Savage To: "'Havard.Eidnes@runit.sintef.no'" , dsmrdel@computerm.com Cc: henk@ripe.net, ippm@advanced.org Subject: RE: One-way delay Date: Mon, 6 Dec 1999 07:22:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id KAA04056 Content-Transfer-Encoding: 8bit Minor correction and shameless plug: it IS possible to measure one-way loss along "random" paths by leveraging the widespread deployment of TCP. No other remote infrastructure required. See http://www.cs.washington.edu/homes/savage/sting/ In the future, we plan to announce similar tricks for other one-way metrics (delay variation, re-ordering, bottleneck capacity, etc...) I agree that you can't do one-way delay though... - Stefan -----Original Message----- From: Havard.Eidnes@runit.sintef.no [mailto:Havard.Eidnes@runit.sintef.no] Sent: Monday, December 06, 1999 6:44 AM To: dsmrdel@computerm.com Cc: henk@ripe.net; ippm@advanced.org Subject: RE: One-way delay > From all of the emails that I have seen on this topic, I > believe that the consensus is that there is a need and purpose > for one-way delay measurement...now the original question still > needs to be answered...what is the best way for someone to > measure it? The best way for someone to measure it is (briefly) to have a measurement machine at either end of the path under study, each of them synchronized to a known good time source. See the RFCs and the Internet-drafts (if there are still any for one-way delay; I somehow doubdt it) for the nitty-gritty details. In practice, this means that it will take quite some effort in order to accurately measure the one-way delay and loss characteristics of a given path, and the technique thus isn't all that amenable to measuring these metrics for "random" paths due to the need for good infrastructure to carry out the measurements. Regards, - Håvard From matt@advanced.org Mon Dec 6 10:29:45 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03957 for ; Mon, 6 Dec 1999 10:29:44 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA28295 for ippm-l@advanced.org; Mon, 6 Dec 1999 10:26:23 -0500 (EST) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id KAA06278 for ; Mon, 6 Dec 1999 10:26:20 -0500 (EST) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Dec 1999 16:26:12 +0100 Message-ID: <7D59335FDAE0D011A3350060974B1C7201CDECEB@L-MHS3> From: KERBERENES Jacques CNET/DAC/LAN To: "Glossbrenner, Kenneth C." , "'Vern Paxson'" Cc: "IETF IPPM (E-mail)" Subject: RE: One-way delay/vs round-trip delay Date: Mon, 6 Dec 1999 16:30:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain HI all, My understanding of the IPPM work is that the RFCs is Standards tracks. Thus, one (end user, ISP/NSP) can choose to implement them or not. Althought I don't participate to IPPM WG I have got all the mailing-list archives. I have often read funnies exchanges and in my mind I has been very confussed : who tell the true ? Now my opinion is the following and has become very simple. When I am in my garden I need different tools to do different things. Monitoring the Internet is certaintly a more difficult issue. But the problem is the same : what do you want to do ? One-way delay and packet loss is very useful in some situations, and round-trip measureaments is only what we need for other purposes. For example FT hosts a Surveyor's boxe to monitor the oversea links because the traffic is assymetric. I am also trying to host other Surveyor's boxes for some of our domestic links , because since the King LouisXIV France is a very centralized and the traffic is also assymetric between Paris an other towns in the country. But we also intend to use two-way probes for monitoring our backbone and customers backbones. So where is the problem : use the appropriate tools where there are needed, and use cheaper tools when this is only what we need. Jacques > ---------- > De : Vern Paxson[SMTP:vern@ee.lbl.gov] > Date : Saturday, December 04, 1999 8:08 AM > A : Glossbrenner, Kenneth C. > Cc : IETF IPPM (E-mail); Annie Gravey (E-mail); Neal B. Seitz (E-mail) > Objet : Re: One-way delay > > Also, one of the goals for IPPM metrics is that when possible they should > be composable. As you can in principle derive round-trip delay from two > one-way delay measurements, this in a sense makes a one-way delay metric > more fundamental than a round-trip delay metric. The fact that the > composition > is not in practice trivial (i.e., just adding the two measurements gets > you > the wrong answer, since there's some additional delay at the far end > turning > around the packet) is a feature, because it highlights that a round-trip > measurement is not simply a network measurement but also measures > something > about the end host. > > Vern > From matt@advanced.org Mon Dec 6 10:47:44 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13132 for ; Mon, 6 Dec 1999 10:47:41 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA08700 for ippm-l@advanced.org; Mon, 6 Dec 1999 10:43:19 -0500 (EST) Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA10396 for ; Mon, 6 Dec 1999 10:43:17 -0500 (EST) Received: (from dovrolis@localhost) by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) id JAA05959; Mon, 6 Dec 1999 09:43:02 -0600 (CST) From: Constantinos Message-Id: <199912061543.JAA05959@hertz.ece.wisc.edu> Subject: Re: One-way delay To: Havard.Eidnes@runit.sintef.no Date: Mon, 6 Dec 1999 09:43:01 -0600 (CST) Cc: dsmrdel@computerm.com, henk@ripe.net, ippm@advanced.org In-Reply-To: <19991206154413T.he@runit.sintef.no> from "Havard.Eidnes@runit.sintef.no" at Dec 6, 99 03:44:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text I was wondering, is the GPS type of solution the only way to measure accurately one-way delays? I mean, suppose that we have nothing more than two hosts at the ends of a path, with a certain clock skew between them (assume that the clock drift is zero as a first-order approximation). Is it "proven", either in a practical or theoretical sense, that we cannot measure the path one-way delay in a given accuracy, independent of the measuring technique used? Obviously, even if the clocks are perfectly synchronized, the maximum accuracy that we can get is determined by the clock resolution at the two hosts. What about, though, some lower accuracy level? Say in the order of 1ms or so (compared to the microsecond clock resolution of current machines)? Constantinos > > > From all of the emails that I have seen on this topic, I > > believe that the consensus is that there is a need and purpose > > for one-way delay measurement...now the original question still > > needs to be answered...what is the best way for someone to > > measure it? > > The best way for someone to measure it is (briefly) to have a > measurement machine at either end of the path under study, each of > them synchronized to a known good time source. See the RFCs and the > Internet-drafts (if there are still any for one-way delay; I somehow > doubdt it) for the nitty-gritty details. > > In practice, this means that it will take quite some effort in order > to accurately measure the one-way delay and loss characteristics of > a given path, and the technique thus isn't all that amenable to > measuring these metrics for "random" paths due to the need for good > infrastructure to carry out the measurements. > > Regards, > > - Håvard > > From matt@advanced.org Mon Dec 6 13:59:42 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03512 for ; Mon, 6 Dec 1999 13:59:41 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id NAA17064 for ippm-l@advanced.org; Mon, 6 Dec 1999 13:46:06 -0500 (EST) Received: from hawaii.rr.com (hnlmail3.hawaii.rr.com [24.25.227.37]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id NAA13760 for ; Mon, 6 Dec 1999 13:46:04 -0500 (EST) Received: from robinu.alii.com ([24.31.64.133]) by hawaii.rr.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 6 Dec 1999 08:45:39 -1000 Received: by localhost with Microsoft MAPI; Mon, 6 Dec 1999 08:46:47 -1000 Message-ID: <01BF3FC6.6E029240.robin_u@adtech-inc.com> From: Robin Uyeshiro Reply-To: "robin_u@adtech-inc.com" To: "'ippm@advanced.org'" Subject: FW: One-way delay Date: Mon, 6 Dec 1999 08:46:44 -1000 Organization: Adtech, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are a few commercial testers that are able to do one-way measurements very accurately. If you send me an email, I can provide a somewhat biased list. I believe most use GPS to obtain higher accuracy. Robin Uyeshiro Adtech, Inc. -----Original Message----- From: Havard.Eidnes@runit.sintef.no [SMTP:Havard.Eidnes@runit.sintef.no] Sent: Monday, December 06, 1999 4:44 AM To: dsmrdel@computerm.com Cc: henk@ripe.net; ippm@advanced.org Subject: RE: One-way delay > From all of the emails that I have seen on this topic, I > believe that the consensus is that there is a need and purpose > for one-way delay measurement...now the original question still > needs to be answered...what is the best way for someone to > measure it? The best way for someone to measure it is (briefly) to have a measurement machine at either end of the path under study, each of them synchronized to a known good time source. See the RFCs and the Internet-drafts (if there are still any for one-way delay; I somehow doubdt it) for the nitty-gritty details. In practice, this means that it will take quite some effort in order to accurately measure the one-way delay and loss characteristics of a given path, and the technique thus isn't all that amenable to measuring these metrics for "random" paths due to the need for good infrastructure to carry out the measurements. Regards, - Havard From matt@advanced.org Mon Dec 6 17:00:09 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26656 for ; Mon, 6 Dec 1999 17:00:08 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id QAA10456 for ippm-l@advanced.org; Mon, 6 Dec 1999 16:53:59 -0500 (EST) Received: from xena.cs.waikato.ac.nz (xena.cs.waikato.ac.nz [130.217.241.20]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id QAA19264 for ; Mon, 6 Dec 1999 16:53:56 -0500 (EST) Received: from lucy.cs.waikato.ac.nz (joerg@lucy.cs.waikato.ac.nz [130.217.241.12]) by xena.cs.waikato.ac.nz (8.9.3/8.9.3) with ESMTP id KAA06875; Tue, 7 Dec 1999 10:53:51 +1300 (NZDT) Received: (from joerg@localhost) by lucy.cs.waikato.ac.nz (8.9.3/8.9.0) id KAA03917; Tue, 7 Dec 1999 10:53:48 +1300 (NZDT) Date: Tue, 7 Dec 1999 10:53:47 +1300 From: Joerg Micheel To: Constantinos Cc: Havard.Eidnes@runit.sintef.no, dsmrdel@computerm.com, henk@ripe.net, ippm@advanced.org, joerg@cs.waikato.ac.nz Subject: Re: One-way delay Message-ID: <19991207105347.C26929@cs.waikato.ac.nz> References: <19991206154413T.he@runit.sintef.no> <199912061543.JAA05959@hertz.ece.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <199912061543.JAA05959@hertz.ece.wisc.edu>; from Constantinos on Mon, Dec 06, 1999 at 09:43:01AM -0600 Organization: SCMS, The University of Waikato, Hamilton, New Zealand Project: WAND - Waikato Applied Network Dynamics, DAG Operating-System: ... drained by Solaris 7 SPARC On Mon, Dec 06, 1999 at 09:43:01AM -0600, Constantinos wrote: > I was wondering, is the GPS type of solution the only way to > measure accurately one-way delays? > > I mean, suppose that we have nothing more than two hosts > at the ends of a path, with a certain clock skew between > them (assume that the clock drift is zero as a first-order > approximation). > > Is it "proven", either in a practical or theoretical sense, > that we cannot measure the path one-way delay in a given > accuracy, independent of the measuring technique used? It might be possible to get the drift under control by having a very accurate PPS source, such as derived from SONET/SDH, but still: how will you be able to tell the clock offset at both ends ? Joerg -- Joerg B. Micheel Email: Waikato Applied Network Dynamics Phone: +64 7 8384794 The University of Waikato, CompScience Fax: +64 7 8384155 Private Bag 3105 Pager: +64 868 38222 Hamilton, New Zealand Plan: TINE and the DAG's From matt@advanced.org Tue Dec 7 04:29:24 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18130 for ; Tue, 7 Dec 1999 04:29:23 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id EAA16693 for ippm-l@advanced.org; Tue, 7 Dec 1999 04:11:58 -0500 (EST) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id EAA17082 for ; Tue, 7 Dec 1999 04:11:56 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Dec 1999 10:12:04 +0100 Message-ID: <7D59335FDAE0D011A3350060974B1C7201CDECEE@L-MHS3> From: KERBERENES Jacques CNET/DAC/LAN To: "'ippm@advanced.org'" , "'robin_u@adtech-inc.com'" Cc: "'bruce@accumatics.com'" , "'Henk Uijterwaal (RIPE-NCC)'" Subject: RE: One-way delay Date: Tue, 7 Dec 1999 10:16:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id EAA25696 Content-Transfer-Encoding: 8bit Hi, You are right, but the problem is that such commercial products are very expansive. Since I have worked very closely with HP and Netcom Systems during several years, I have suggested them to design a low cost active probe. But the solution they have choosen are too expansive for a large deployement (IMHO). I am aware that and EC project intend to use the Netcom Product, but only with a few number of boxes because of their hight cost. So, I am waiting the new version of RIPE-NCC test project probe , or may be we will develop our own box in our lab. I have also suggested to Accumatics to integrate this kind of tool, since we are satisfied with his commercial version of OC3Mon. Jacques Jacques Kerberenes e-mail : jacques.kerberenes@cnet.francetelecom.fr Phone : +33 (0)2 96 05 29 13 Fax : +33 (0)2 96 05 18 52 CNET/DAC/NTR 2, av Pierre Marzin BP 40 22301 LANNION CEDEX FRANCE > ---------- > De : Robin Uyeshiro[SMTP:robin_u@adtech-inc.com] > Répondre à : robin_u@adtech-inc.com > Date : Monday, December 06, 1999 7:46 PM > A : 'ippm@advanced.org' > Objet : FW: One-way delay > > There are a few commercial testers that are able to do one-way > measurements > very accurately. If you send me an email, I can provide a somewhat biased > > list. I believe most use GPS to obtain higher accuracy. > > Robin Uyeshiro > Adtech, Inc. > > -----Original Message----- > From: Havard.Eidnes@runit.sintef.no [SMTP:Havard.Eidnes@runit.sintef.no] > Sent: Monday, December 06, 1999 4:44 AM > To: dsmrdel@computerm.com > Cc: henk@ripe.net; ippm@advanced.org > Subject: RE: One-way delay > > From all of the emails that I have seen on this topic, I > > believe that the consensus is that there is a need and purpose > > for one-way delay measurement...now the original question still > > needs to be answered...what is the best way for someone to > > measure it? > > The best way for someone to measure it is (briefly) to have a measurement > machine at either end of the path under study, each of them synchronized > to > a known good time source. See the RFCs and the Internet-drafts (if there > are still any for one-way delay; I somehow doubdt it) for the nitty-gritty > > details. > In practice, this means that it will take quite some effort in order to > accurately measure the one-way delay and loss characteristics of a given > path, and the technique thus isn't all that amenable to measuring these > metrics for "random" paths due to the need for good infrastructure to > carry > out the measurements. > Regards, > > - Havard > From matt@advanced.org Tue Dec 7 10:25:33 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08640 for ; Tue, 7 Dec 1999 10:25:31 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA25619 for ippm-l@advanced.org; Tue, 7 Dec 1999 10:11:10 -0500 (EST) Received: from routeflapper.internap.com (routeflapper.internap.com [206.253.215.47]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA21398 for ; Tue, 7 Dec 1999 10:11:07 -0500 (EST) Received: from localhost (dan@localhost) by routeflapper.internap.com (8.8.5/8.8.5) with ESMTP id HAA28597; Tue, 7 Dec 1999 07:08:17 -0800 X-Authentication-Warning: routeflapper.internap.com: dan owned process doing -bs Date: Tue, 7 Dec 1999 07:08:17 -0800 (PST) From: Dan Cohn To: KERBERENES Jacques CNET/DAC/LAN cc: "'ippm@advanced.org'" , "'robin_u@adtech-inc.com'" , "'bruce@accumatics.com'" , "'Henk Uijterwaal (RIPE-NCC)'" Subject: RE: One-way delay In-Reply-To: <7D59335FDAE0D011A3350060974B1C7201CDECEE@L-MHS3> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by betelgeuse.advanced.org id KAA26473 Content-Transfer-Encoding: 8bit FYI, Cisco is developing a special image with what they call 'RTR', a set of tools designed to do end to end performance measurement within IOS. Its coming out of their diffserv group, and I haven't had time to follow up on it, but I believe it also included a one-way delay test with GPS sync. I got the impression that it wasn't very far into development yet, but that most basic tests were working by now. I don't think its hit any documentation yet, either. dc On Tue, 7 Dec 1999, KERBERENES Jacques CNET/DAC/LAN wrote: > Hi, > > You are right, but the problem is that such commercial products are very > expansive. Since I have worked very closely with HP and Netcom Systems > during several years, I have suggested them to design a low cost active > probe. But the solution they have choosen are too expansive for a large > deployement (IMHO). I am aware that and EC project intend to use the Netcom > Product, but only with a few number of boxes because of their hight cost. > So, I am waiting the new version of RIPE-NCC test project probe , or may be > we will develop our own box in our lab. I have also suggested to Accumatics > to integrate this kind of tool, since we are satisfied with his commercial > version of OC3Mon. > > Jacques > > > Jacques Kerberenes > > e-mail : jacques.kerberenes@cnet.francetelecom.fr > > Phone : +33 (0)2 96 05 29 13 > Fax : +33 (0)2 96 05 18 52 > > CNET/DAC/NTR > 2, av Pierre Marzin > BP 40 22301 LANNION CEDEX > FRANCE > > > > ---------- > > De : Robin Uyeshiro[SMTP:robin_u@adtech-inc.com] > > Répondre à : robin_u@adtech-inc.com > > Date : Monday, December 06, 1999 7:46 PM > > A : 'ippm@advanced.org' > > Objet : FW: One-way delay > > > > There are a few commercial testers that are able to do one-way > > measurements > > very accurately. If you send me an email, I can provide a somewhat biased > > > > list. I believe most use GPS to obtain higher accuracy. > > > > Robin Uyeshiro > > Adtech, Inc. > > > > -----Original Message----- > > From: Havard.Eidnes@runit.sintef.no [SMTP:Havard.Eidnes@runit.sintef.no] > > Sent: Monday, December 06, 1999 4:44 AM > > To: dsmrdel@computerm.com > > Cc: henk@ripe.net; ippm@advanced.org > > Subject: RE: One-way delay > > > From all of the emails that I have seen on this topic, I > > > believe that the consensus is that there is a need and purpose > > > for one-way delay measurement...now the original question still > > > needs to be answered...what is the best way for someone to > > > measure it? > > > > The best way for someone to measure it is (briefly) to have a measurement > > machine at either end of the path under study, each of them synchronized > > to > > a known good time source. See the RFCs and the Internet-drafts (if there > > are still any for one-way delay; I somehow doubdt it) for the nitty-gritty > > > > details. > > In practice, this means that it will take quite some effort in order to > > accurately measure the one-way delay and loss characteristics of a given > > path, and the technique thus isn't all that amenable to measuring these > > metrics for "random" paths due to the need for good infrastructure to > > carry > > out the measurements. > > Regards, > > > > - Havard > > > > From matt@advanced.org Tue Dec 7 10:41:20 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16182 for ; Tue, 7 Dec 1999 10:41:17 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA26937 for ippm-l@advanced.org; Tue, 7 Dec 1999 10:33:36 -0500 (EST) Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA10915 for ; Tue, 7 Dec 1999 10:33:34 -0500 (EST) Received: (from dovrolis@localhost) by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) id JAA08059; Tue, 7 Dec 1999 09:33:13 -0600 (CST) From: Constantinos Message-Id: <199912071533.JAA08059@hertz.ece.wisc.edu> Subject: Re: One-way delay To: joerg@cs.waikato.ac.nz (Joerg Micheel) Date: Tue, 7 Dec 1999 09:33:13 -0600 (CST) Cc: Havard.Eidnes@runit.sintef.no, dsmrdel@computerm.com, henk@ripe.net, ippm@advanced.org, joerg@cs.waikato.ac.nz In-Reply-To: <19991207105347.C26929@cs.waikato.ac.nz> from "Joerg Micheel" at Dec 7, 99 10:53:47 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text > > It might be possible to get the drift under control by having a > very accurate PPS source, such as derived from SONET/SDH, but > still: how will you be able to tell the clock offset at both ends ? > > Joerg If you know the clock offset, you can easily measure the one-way delay. If you known the one-way delay, you can easily measure the offset. They are equivalent in this sense. If you know neither, though, I was wondering if it is impossible to measure the one-way delay (or the offset), independent of what measurement technique you use (without an external common clock source). Constantinos > -- > Joerg B. Micheel Email: > Waikato Applied Network Dynamics Phone: +64 7 8384794 > The University of Waikato, CompScience Fax: +64 7 8384155 > Private Bag 3105 Pager: +64 868 38222 > Hamilton, New Zealand Plan: TINE and the DAG's > From matt@advanced.org Tue Dec 7 13:05:07 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25634 for ; Tue, 7 Dec 1999 13:05:04 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA28518 for ippm-l@advanced.org; Tue, 7 Dec 1999 12:47:45 -0500 (EST) Received: from danube.cisco.com (danube.cisco.com [171.69.43.47]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id MAA05880 for ; Tue, 7 Dec 1999 12:47:44 -0500 (EST) Received: (from kzhang@localhost) by danube.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id JAA22600; Tue, 7 Dec 1999 09:46:33 -0800 (PST) From: Kui Zhang Message-Id: <199912071746.JAA22600@danube.cisco.com> Subject: Re: One-way delay To: dan@internap.com (Dan Cohn) Date: Tue, 7 Dec 1999 09:46:33 -0800 (PST) Cc: jacques.kerberenes@cnet.francetelecom.fr, ippm@advanced.org, robin_u@adtech-inc.com, bruce@accumatics.com, henk@ripe.net In-Reply-To: from "Dan Cohn" at Dec 7, 99 07:08:17 am Reply-To: kzhang@cisco.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > FYI, > > Cisco is developing a special image with what they call 'RTR', a > set of tools designed to do end to end performance measurement within IOS. > Its coming out of their diffserv group, and I haven't had time to follow > up on it, but I believe it also included a one-way delay test with GPS > sync. I got the impression that it wasn't very far into development yet, > but that most basic tests were working by now. I don't think its hit > any documentation yet, either. > > dc I happened to be involved in this project at Cisco. RTR (Response Time Reporter, now renamed to Service Assurance Agent) is a feature in regular IOS release. It does response time (RTT) measurement for a number of traffic types: ICMP, UDP, TCP, HTTP, DNS, DHCP. It also measures UDP jitter (one way delay variance). The ability to measure one-way latency will be released early next year. To measure one way latency, we require the clock on source and destination to be synchronized. In real life, this kind of measurement is often performed by an ISP from one POP to another POP. In this case, ISP would install an NTP server with GPS clock to each POP location, then all routers in that POP would sync up to that NTP server via NTP. This approach could get source and destination synced close to a couple of milliseconds. Also it is not too expensive -- this kind of NTP server costs about US$ 2000. If you need more info on RTR(SAA), please email to me. I don't want to bore this list with infomercials :-) Cheers, .kui > > On Tue, 7 Dec 1999, KERBERENES Jacques CNET/DAC/LAN wrote: > > > Hi, > > > > You are right, but the problem is that such commercial products are very > > expansive. Since I have worked very closely with HP and Netcom Systems > > during several years, I have suggested them to design a low cost active > > probe. But the solution they have choosen are too expansive for a large > > deployement (IMHO). I am aware that and EC project intend to use the Netcom > > Product, but only with a few number of boxes because of their hight cost. > > So, I am waiting the new version of RIPE-NCC test project probe , or may be > > we will develop our own box in our lab. I have also suggested to Accumatics > > to integrate this kind of tool, since we are satisfied with his commercial > > version of OC3Mon. > > > > Jacques > > > > > > Jacques Kerberenes > > > > e-mail : jacques.kerberenes@cnet.francetelecom.fr > > > > Phone : +33 (0)2 96 05 29 13 > > Fax : +33 (0)2 96 05 18 52 > > > > CNET/DAC/NTR > > 2, av Pierre Marzin > > BP 40 22301 LANNION CEDEX > > FRANCE > > > > > > > ---------- > > > De : Robin Uyeshiro[SMTP:robin_u@adtech-inc.com] > > > Répondre à : robin_u@adtech-inc.com > > > Date : Monday, December 06, 1999 7:46 PM > > > A : 'ippm@advanced.org' > > > Objet : FW: One-way delay > > > > > > There are a few commercial testers that are able to do one-way > > > measurements > > > very accurately. If you send me an email, I can provide a somewhat biased > > > > > > list. I believe most use GPS to obtain higher accuracy. > > > > > > Robin Uyeshiro > > > Adtech, Inc. > > > > > > -----Original Message----- > > > From: Havard.Eidnes@runit.sintef.no [SMTP:Havard.Eidnes@runit.sintef.no] > > > Sent: Monday, December 06, 1999 4:44 AM > > > To: dsmrdel@computerm.com > > > Cc: henk@ripe.net; ippm@advanced.org > > > Subject: RE: One-way delay > > > > From all of the emails that I have seen on this topic, I > > > > believe that the consensus is that there is a need and purpose > > > > for one-way delay measurement...now the original question still > > > > needs to be answered...what is the best way for someone to > > > > measure it? > > > > > > The best way for someone to measure it is (briefly) to have a measurement > > > machine at either end of the path under study, each of them synchronized > > > to > > > a known good time source. See the RFCs and the Internet-drafts (if there > > > are still any for one-way delay; I somehow doubdt it) for the nitty-gritty > > > > > > details. > > > In practice, this means that it will take quite some effort in order to > > > accurately measure the one-way delay and loss characteristics of a given > > > path, and the technique thus isn't all that amenable to measuring these > > > metrics for "random" paths due to the need for good infrastructure to > > > carry > > > out the measurements. > > > Regards, > > > > > > - Havard > > > > > > > > > > From matt@advanced.org Wed Dec 8 05:09:15 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01956 for ; Wed, 8 Dec 1999 05:09:14 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id EAA03963 for ippm-l@advanced.org; Wed, 8 Dec 1999 04:58:40 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id EAA08614 for ; Wed, 8 Dec 1999 04:58:38 -0500 (EST) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id KAA18194; Wed, 8 Dec 1999 10:56:40 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id KAA11892; Wed, 8 Dec 1999 10:56:40 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 8 Dec 1999 10:56:40 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Kui Zhang cc: Dan Cohn , jacques.kerberenes@cnet.francetelecom.fr, ippm@advanced.org, robin_u@adtech-inc.com, bruce@accumatics.com Subject: Re: One-way delay In-Reply-To: <199912071746.JAA22600@danube.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 7 Dec 1999, Kui Zhang wrote: > The ability to measure one-way latency will be released early next year. > To measure one way latency, we require the clock on source and destination to > be synchronized. In real life, this kind of measurement is often performed > by an ISP from one POP to another POP. In this case, ISP would install an > NTP server with GPS clock to each POP location, then all routers in that POP > would sync up to that NTP server via NTP. > This approach could get source and destination synced close to a couple of > milliseconds. Also it is not too expensive -- this kind of NTP server costs > about US$ 2000. If you have a uncertainties in the synchronization of the order of a few milliseconds, then the experimental uncertainty in your measurement will be huge compared to the effect you are trying to measure. A 2 ms error in the clock synchronization on each ends translates into an overall error of around 3 ms. This is a lot compared to the delays of 10...50 ms that one typically sees between ISP's, and makes measurements on internal networks (delays of the order of 1 ms) totally impossible. Also note that CHANGES in the network (for example, somebody replaces a router or cable, traffic starts to take a different path with one hop more/less) result in changes of the order of a few ms in the one-way delay. This is something you want to know but cannot detect with a device with an accuracy of the order of a few ms. In short, you have to do at least order of magnitude better in clock synchronization before this is useful. > > On Tue, 7 Dec 1999, KERBERENES Jacques CNET/DAC/LAN wrote: > > > So, I am waiting the new version of RIPE-NCC test project probe , Just for the record: We are not developing a new version of our "test-boxes", for the next series we plan to continue with essentially the same setup as we've done for the past two years. However, we do have to have a new batch of PCB's made from scratch, and we are using this opportunity to make a few minor changes to the hardware based on our experience with the previous version. Nothing major, no rocket science, it just takes time. These boxes will be made available to the RIPE membership early next year, as soon as we have worked out a number of practical details and received approval from the RIPE membership to proceed. For details, please contact me directly. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19). From matt@advanced.org Mon Dec 13 20:16:37 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21919 for ; Mon, 13 Dec 1999 20:16:35 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id TAA03959 for ippm-l@advanced.org; Mon, 13 Dec 1999 19:56:52 -0500 (EST) Received: from mail.rdc1.nj.home.com (imail@ha1.rdc1.nj.home.com [24.3.128.66]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id TAA04164 for ; Mon, 13 Dec 1999 19:56:43 -0500 (EST) Received: from home.com ([24.3.197.86]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991214005640.JBEN17353.mail.rdc1.nj.home.com@home.com> for ; Mon, 13 Dec 1999 16:56:40 -0800 Message-ID: <385594BE.7166923F@home.com> Date: Mon, 13 Dec 1999 19:52:14 -0500 From: buyukkoc X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Subject: what happened to engr.ans.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit looking for several ospf simulators that are supposed to be there... any help would be appreciated. cagatay buyukkoc From matt@advanced.org Tue Dec 14 11:31:49 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23079 for ; Tue, 14 Dec 1999 11:31:48 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id LAA28042 for ippm-l@advanced.org; Tue, 14 Dec 1999 11:23:42 -0500 (EST) Received: from uni03mr.unity.ncsu.edu (uni03mr.unity.ncsu.edu [152.1.1.166]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id LAA25989 for ; Tue, 14 Dec 1999 11:23:41 -0500 (EST) Received: from unity.ncsu.edu (earth.csc.ncsu.edu [152.1.75.171]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with ESMTP id LAA05964 for ; Tue, 14 Dec 1999 11:23:36 -0500 (EST) Sender: cwu4@unity.ncsu.edu Message-ID: <38566F09.F42B4986@unity.ncsu.edu> Date: Tue, 14 Dec 1999 11:23:37 -0500 From: Chien-Lung Wu Organization: NC State University X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ippm@advanced.org Subject: QoS and IPPM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Recently, there are a lot of studies focusing on QoS guarantee, for example, bounded delay guarantee. Do anyone have any idea to point out that QoS routing "should" not just focus on the bounce guarantee, it should more effecient to detect dynamic character of current networks? Thanks in advance. Chien-Lung -- **************************************************************************** Chien-Lung Wu cwu4@eos.ncsu.edu Graduate Student of ECE (O) 919-513-1894 at North Carolina State University (H) 919-233-6724 **************************************************************************** From matt@advanced.org Tue Dec 21 11:01:18 1999 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26491 for ; Tue, 21 Dec 1999 11:01:18 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA08673 for ippm-l@advanced.org; Tue, 21 Dec 1999 10:47:26 -0500 (EST) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id KAA08252 for ; Tue, 21 Dec 1999 10:47:23 -0500 (EST) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Dec 1999 16:47:50 +0100 Message-ID: <7D59335FDAE0D011A3350060974B1C7201CDED0E@L-MHS3> From: KERBERENES Jacques CNET/DAC/LAN To: ippm@advanced.org, "'Chien-Lung Wu'" Cc: cwu4@eos.ncsu.edu, wu@eos.ncsu.edu Subject: RE: One-way delay Date: Tue, 21 Dec 1999 16:52:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Hi every body, > ---------- > De : Chien-Lung Wu[SMTP:cwu4@unity.ncsu.edu] > Date : Thursday, December 02, 1999 10:10 PM > A : ippm@advanced.org > Cc : cwu4@eos.ncsu.edu; wu@eos.ncsu.edu > Objet : One-way delay > > Hi, all: > There are a lot of discussions about one-way delay metrics on IPPM. You are right, since the beginning of the IPPM work there has been a lot of discussions about this topic : one-way vs round-trip. And , as for other issues there are several schools, each of them having their own arguments for choosing one of these metrics. > Can > anybody show me or point out how to measure one-way delay? There are at least two current trials that are measuring one-way delay and packet loss : Surveyor (ANS) and RIPE-NCC Test Project in Europe. I am trying to convince France Telecom to participate to the two projects, I think we will sign an agreement with ANS in January and with RIPE when their new boxes will be available. We are also thinking to develop our own probes, and to timestamp the probe packets at the physical layer, (wire time vs host time, see the discussion in the framework document RFC 2330) > I think many > works have been done on round-trip delay. Why do we need "one-way delay"? > There are several motivations for the one-way measurements that are well explained is RFCs 2679 and 2680. In particular the assymetry of the two paths (routing and queuing) over a lot of links We know we have such traffic patterns on some of our links. But in an other other hand, I agree that round-trip measurements as performed, for instance by the Pinger and AMP projects, are in fact the quantity of interest. For me (IMHO) there is no contradiction between the two approaches. Do what we need where we need and to obtain the results we are looking for. A very interesting paper is the comparison of the results provided by differrent tools and methodologies : Les Cottrel : http://www.slac.standford.edu/comp/net/wan-mon/iepm-cf.html > Thanks in advance. > > Regards, > > Chien-Lung > > > ************************************************************************** > ** > Chien-Lung Wu cwu4@eos.ncsu.edu > Graduate Student of ECE (O) 919-513-1894 > at North Carolina State University (H) 919-233-6724 > ************************************************************************** > ** Best Regards Jacques > Jacques Kerberenes > > e-mail : jacques.kerberenes@cnet.francetelecom.fr > > Phone : +33 (0)2 96 05 29 13 > Fax : +33 (0)2 96 05 18 52 > > CNET/DAC/NTR > 2, av Pierre Marzin > BP 40 22301 LANNION CEDEX > FRANCE