From matt@advanced.org Mon Sep 4 05:17:22 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01329 for ; Mon, 4 Sep 2000 05:17:22 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id FAA20507 for ippm-l@advanced.org; Mon, 4 Sep 2000 05:05:11 -0400 (EDT) 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 FAA21615 for ; Mon, 4 Sep 2000 05:05:01 -0400 (EDT) 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 LAA04539; Mon, 4 Sep 2000 11:02:41 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id LAA07034; Mon, 4 Sep 2000 11:02:41 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 4 Sep 2000 11:02:41 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Lijun Qian cc: ippm@advanced.org, Anwar Elwalid , Indra Widjaja Subject: Re: Measurement protocol for one-way performance metrics In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 2000, Lijun Qian wrote: > > Hi, all, here are some explanations about our approach of measurement > protocol for one-way performance metrics presented at the IETF meeting. > A protocol which measures one-way performance metrics(loss, delay, etc.) > in REAL TIME is indispensible in many cases, for example, Traffic > Engineering. I'm not quite sure what to what protocol you are referring to here, since there are 2 protocols involved here: A) The protocol that specifies what measurement packets look like. This protocol is real-time by definition, since, as soon as one has measured a delay or loss, this result is available. How it should be made available is another question. B) The protocol that specifies how results should be presented to the application that uses the measurements (and perhaps, how to specify what you want the measurement device to measure in the near future). I think that for TE (and related) purposes, we should concentrate on B. The metrics (A) have been chewed on long enough, and the protocols used between the measurement devices are mainly an implementation detail. > Q: How to get one-way packet loss? > > A: The source encodes a Source Sequence Number to notify the > destination how many probe packets have been transmitted by the > source. The destination encodes a destination Sequence Number > to notify the source how many probe packets have been received > by the destination so far. Sending packets back is only necessary if the source has to know the packet loss seen by the destination. Otherwise it just complicates things. The other problem with this approach occurs when there is a complete outage. The source will continue to send, but never see anything back. This can be caused by 2 things: the connection is lost _or_ the process on the receiving box has died. In the former case, there is indeed 100% loss, in the latter it only _appears_ that there is 100% loss. (Yes, I realize that this won't happen in a lab setup, but try measuring losses on a large scale in real life). What IS full proof, is to record packets sent and packets received at sender and receiver, then collect these data through an independent path and combine the 2, but then there will be a delay between measurement and availability of the result. 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 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Mon Sep 4 06:12:24 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01754 for ; Mon, 4 Sep 2000 06:12:24 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id GAA21761 for ippm-l@advanced.org; Mon, 4 Sep 2000 06:06:52 -0400 (EDT) Received: from neo.it.comsat.com (neo.it.comsat.com [134.133.200.200]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id GAA20901 for ; Mon, 4 Sep 2000 06:06:51 -0400 (EDT) Received: (from smadmin@localhost) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) id e84A0Ob23493; Mon, 4 Sep 2000 06:00:24 -0400 (EDT) Received: from betelgeuse.advanced.org ([209.211.239.10]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e84A0Do23489; Mon, 4 Sep 2000 06:00:13 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id FAA20507 for ippm-l@advanced.org; Mon, 4 Sep 2000 05:05:11 -0400 (EDT) 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 FAA21615 for ; Mon, 4 Sep 2000 05:05:01 -0400 (EDT) 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 LAA04539; Mon, 4 Sep 2000 11:02:41 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id LAA07034; Mon, 4 Sep 2000 11:02:41 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 4 Sep 2000 11:02:41 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Lijun Qian cc: ippm@advanced.org, Anwar Elwalid , Indra Widjaja Subject: Re: Measurement protocol for one-way performance metrics In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Filter: omnivore ver 1.0.0 On Wed, 9 Aug 2000, Lijun Qian wrote: > > Hi, all, here are some explanations about our approach of measurement > protocol for one-way performance metrics presented at the IETF meeting. > A protocol which measures one-way performance metrics(loss, delay, etc.) > in REAL TIME is indispensible in many cases, for example, Traffic > Engineering. I'm not quite sure what to what protocol you are referring to here, since there are 2 protocols involved here: A) The protocol that specifies what measurement packets look like. This protocol is real-time by definition, since, as soon as one has measured a delay or loss, this result is available. How it should be made available is another question. B) The protocol that specifies how results should be presented to the application that uses the measurements (and perhaps, how to specify what you want the measurement device to measure in the near future). I think that for TE (and related) purposes, we should concentrate on B. The metrics (A) have been chewed on long enough, and the protocols used between the measurement devices are mainly an implementation detail. > Q: How to get one-way packet loss? > > A: The source encodes a Source Sequence Number to notify the > destination how many probe packets have been transmitted by the > source. The destination encodes a destination Sequence Number > to notify the source how many probe packets have been received > by the destination so far. Sending packets back is only necessary if the source has to know the packet loss seen by the destination. Otherwise it just complicates things. The other problem with this approach occurs when there is a complete outage. The source will continue to send, but never see anything back. This can be caused by 2 things: the connection is lost _or_ the process on the receiving box has died. In the former case, there is indeed 100% loss, in the latter it only _appears_ that there is 100% loss. (Yes, I realize that this won't happen in a lab setup, but try measuring losses on a large scale in real life). What IS full proof, is to record packets sent and packets received at sender and receiver, then collect these data through an independent path and combine the 2, but then there will be a delay between measurement and availability of the result. 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 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Mon Sep 4 11:51:15 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04732 for ; Mon, 4 Sep 2000 11:51:15 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id LAA25076 for ippm-l@advanced.org; Mon, 4 Sep 2000 11:44:08 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id LAA25494 for ; Mon, 4 Sep 2000 11:44:03 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13VyPZ-000OXq-00; Mon, 04 Sep 2000 08:43:53 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Henk Uijterwaal (RIPE-NCC)" Cc: Lijun Qian , ippm@advanced.org, Anwar Elwalid , Indra Widjaja Subject: Re: Measurement protocol for one-way performance metrics References: Message-Id: Date: Mon, 04 Sep 2000 08:43:53 -0700 Content-Transfer-Encoding: 7bit actually, i suspect there could be issues with what protocol the measurement packets use. e.g. icmp can be treated differently than udp. randy From matt@advanced.org Mon Sep 4 12:08:44 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04937 for ; Mon, 4 Sep 2000 12:08:44 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA26038 for ippm-l@advanced.org; Mon, 4 Sep 2000 12:04:12 -0400 (EDT) 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 MAA25681 for ; Mon, 4 Sep 2000 12:04:11 -0400 (EDT) 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 SAA28468; Mon, 4 Sep 2000 18:03:35 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id SAA10009; Mon, 4 Sep 2000 18:03:35 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 4 Sep 2000 18:03:35 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Randy Bush cc: Lijun Qian , ippm@advanced.org, Anwar Elwalid , Indra Widjaja Subject: Re: Measurement protocol for one-way performance metrics In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 4 Sep 2000, Randy Bush wrote: > actually, i suspect there could be issues with what protocol the measurement > packets use. e.g. icmp can be treated differently than udp. Yes, many sites do that. We've never measured this in a systematic way, but ping's rtt, is more often not equal to the sum of the 2 1-way-delays, than not. What one should do, is to make the measurement packets look as close as possible like the real data. This means UDP, not ICMP. One should also add random padding in order to avoid compression along the way by some smart device. 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 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Thu Sep 14 09:38:02 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11663 for ; Thu, 14 Sep 2000 09:38:01 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id JAA09697 for ippm-l@advanced.org; Thu, 14 Sep 2000 09:25:21 -0400 (EDT) Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id JAA10165 for ; Thu, 14 Sep 2000 09:25:20 -0400 (EDT) From: sksid@mail.comune.genova.it Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id NAA17795 for ; Thu, 14 Sep 2000 13:24:48 GMT env-from (sksid@mail.comune.genova.it) Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9eeh4ek.in; 14 Sep 2000 14:53:00 +0200 To: Date: Thu, 14 Sep 2000 05:19:02 Message-Id: <24.41568.421234@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 Webhosting International