From test-admin@advanced.org Fri Jun 1 06:52:19 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04138 for ; Fri, 1 Jun 2001 06:52:19 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f51AqfJ01420 for ; Fri, 1 Jun 2001 06:52:41 -0400 Date: Fri, 1 Jun 2001 06:52:41 -0400 Message-Id: <200106011052.f51AqfJ01420@mailhost.advanced.org> Subject: advanced.org mailing list memberships reminder From: mailman-owner@advanced.org To: ippm-archive@ietf.org X-No-Archive: yes Sender: test-admin@advanced.org Errors-To: test-admin@advanced.org X-BeenThere: test@mailhost.advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a reminder, sent out once a month, about your advanced.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@advanced.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@advanced.org. Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@advanced.org jTPE http://mailhost.advanced.org/mailman/options/ippm/ippm-archive@lists.ietf.org From ippm-admin@advanced.org Fri Jun 1 14:16:12 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15267 for ; Fri, 1 Jun 2001 14:16:11 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f51I32J09619; Fri, 1 Jun 2001 14:03:02 -0400 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f51I28J09493 for ; Fri, 1 Jun 2001 14:02:08 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 0EAA54D66B; Fri, 1 Jun 2001 14:02:01 -0400 (EDT) Received: from research.att.com (roughan@wombat.research.att.com [135.207.26.100]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id OAA09968; Fri, 1 Jun 2001 14:01:59 -0400 (EDT) Message-ID: <3B17D86A.91E161F@research.att.com> Date: Fri, 01 Jun 2001 14:01:14 -0400 From: Matthew Roughan Organization: AT&T Research Labs X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Attila Pasztor Cc: stanislav shalunov , Darryl Neil Veitch , ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...) References: <3B125C4C.AF0DA58E@ee.mu.oz.au> <87itiilqwb.fsf_-_@cain.internet2.edu> <3B16EF7E.572EA375@ee.mu.oz.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Attila Pasztor wrote: > > Hi Stanislav, > > Please excuse me if my question is not appropriate. In your mail to > Darryl you make the following statement: > > > We need to communicate the packet send schedule beforehand to be able > > to detect losses. > > Why? I am sorry, but I don't get it. > > I believe that the loss detection should be based on packet serial > numbers. If it is a problem to detect when a measurement starts or when > it has ended, it can be communicated with simple control messages between > the sender and the receiver. > > 1. Sender sends a "Measurement starts" message > 2. Receiver sends back an acknowledgement > > 3. If the ack is received Sender starts to send the measurement packets; > if the ack is not received within a finite time, then it resends message > #1 > 4. Sender continues to send packets according to his preferred timing > schedule > > 5. Sender sends an "End of measurement" message, including the serial > number of the last packet sent > 6. Receiver sends back an acknowledgement > 7. If the sender does not receive an ack within a finite time the sender > resends message #5 > > (Note: limit the number of resending the messages, if no ack is received > after n trials, then the measurement has failed) > > 8. If there are any packets missing, after a certain time receiver > assumes they are lost > > I think that the process described above detects the losses reliably > (except packet delays exceeding the time outs). > Including serial numbers in the packets is needed anyway, I don't think > that losses could be detected reliably only based on the sending > schedule. > > Please, explain to me, why do we need to communicate the packet send > schedule beforehand to be able to detect losses? > > By the way, in RFC 2680 'A One-way Packet Loss Metric for IPPM' there is > no mentioning of communicating the send schedule. > > Thanks, > Attila > I agree. The above makes sense to me. Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 1 17:06:31 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18107 for ; Fri, 1 Jun 2001 17:06:31 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f51L53J14804; Fri, 1 Jun 2001 17:05:03 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f51L4dJ14609 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Fri, 1 Jun 2001 17:04:43 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f51L4ak30752 for ; Fri, 1 Jun 2001 17:04:36 -0400 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id D8E5A5A6; Fri, 1 Jun 2001 17:04:34 -0400 (EDT) To: ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times References: <3B125C4C.AF0DA58E@ee.mu.oz.au> <87itiilqwb.fsf_-_@cain.internet2.edu> <3B16EF7E.572EA375@ee.mu.oz.au> From: stanislav shalunov Date: 01 Jun 2001 17:04:34 -0400 In-Reply-To: <3B16EF7E.572EA375@ee.mu.oz.au> Message-ID: <87r8x33o9p.fsf_-_@cain.internet2.edu> Lines: 48 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Attila Pasztor writes: > I believe that the loss detection should be based on packet serial numbers. Attila, The approach that you describe can work, however it doesn't appear to solve the whole problem. We believe communicating the send schedule is necessary for the following reasons: * If the receiver were to detect losses it needs to detect times when they occured, and not simply the fact that there were losses. If the sender doesn't tell the receiver somehow when the packets were sent, and packets are lost, information is lost for the receiver. * Without being able to specify what send schedule you want a client can't ask OWDP servers to perform measurements it wants. So, while half of the problem (measurements from me to machines administered by other people) is solved well, the other part (measurements of the path back to me) is not addressed. The server presumably could be configured to send me something reasonable, but what if I want something else? We started by wanting to give the parties more control over when packets are sent; in effect, the degree of control is lessened for paths to the client--earlier it could at least request Poisson rate, now not even that. * Having knowledge about send times allows to detect losses in a more timely manner. Imagine that a (very long) session starts, goes on for two hours, and then connectivity is lost completely. Neither the receiver nor the sender notice anything until the connectivity is restored and the receiver gets a packet with a sequence number that's much larger than what it expects. ("When no packets are coming, is it the network or is it just such a send schedule?") * Not sending the schedule in advance can require the receiver to keep more state. Under normal circumstances, just a little bit more state; but how do you deal with a situation when somebody starts sessions continuously and then just abandons them without notifying you in any way? Do you wait indefinitely for more packets? We believe one really needs to communicate the send schedule somehow. (And the manner of communication is an open question for now.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "I didn't attend the funeral, but I sent a nice letter saying that I approved of it." -- Mark Twain _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sun Jun 3 22:15:16 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13552 for ; Sun, 3 Jun 2001 22:15:16 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f54233J16954; Sun, 3 Jun 2001 22:03:03 -0400 Received: from emulab.ee.mu.oz.au (potoroo.ee.mu.OZ.AU [128.250.76.186]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5422kJ16942 for ; Sun, 3 Jun 2001 22:02:47 -0400 X-Authentication-Warning: mailhost.advanced.org: Host potoroo.ee.mu.OZ.AU [128.250.76.186] claimed to be emulab.ee.mu.oz.au Received: from ee.mu.oz.au (IDENT:attila@wallaby.emulab.ee.mu.oz.au [10.0.0.8]) by emulab.ee.mu.oz.au (8.9.3/8.9.3) with ESMTP id MAA26376; Mon, 4 Jun 2001 12:02:38 +1000 (EST) (envelope-from a.pasztor@ee.mu.oz.au) Message-ID: <3B1AEC08.C61DABA0@ee.mu.oz.au> Date: Mon, 04 Jun 2001 12:01:44 +1000 From: Attila Pasztor X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: stanislav shalunov CC: ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times References: <3B125C4C.AF0DA58E@ee.mu.oz.au> <87itiilqwb.fsf_-_@cain.internet2.edu> <3B16EF7E.572EA375@ee.mu.oz.au> <87r8x33o9p.fsf_-_@cain.internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi Stanislav, Thanks for your comments, I have some more questions. Just before replying to your comments, I would like to repeat the statement which you made earlier, and I had a problem with: > We need to communicate the packet send schedule beforehand to be able > to detect losses. And here follows you comments: > > * If the receiver were to detect losses it needs to detect times when > they occured, and not simply the fact that there were losses. If > the sender doesn't tell the receiver somehow when the packets were > sent, and packets are lost, information is lost for the receiver. If you want to detect times when losses occur, the only way to do it is to make the nodes report when they drop a packet ( I don't think that anyone would really want to do this). The next best estimate of the time of the packet loss is an interval given by the send time and the loss detection time-out. I agree that to get this information (by the way, what is it good for?), the send time has to be known. If one really wants to get this information it could easily be generated by the server (who is contacted anyway by the retrieve-client, to provide him with the results). So for this reason I don't think that it is necessary to send the sender schedule to the Session-receiver. > > * Without being able to specify what send schedule you want a client > can't ask OWDP servers to perform measurements it wants. So, while > half of the problem (measurements from me to machines administered > by other people) is solved well, the other part (measurements of the > path back to me) is not addressed. The server presumably could be > configured to send me something reasonable, but what if I want > something else? We started by wanting to give the parties more > control over when packets are sent; in effect, the degree of control > is lessened for paths to the client--earlier it could at least > request Poisson rate, now not even that. I fully agree that the schedule has to be sent to the Session-sender, but I don't think, as I have earlier mentioned, that there is a need to send the schedule to the receiver. There are several ways to do it, send a compressed table of the measurement start time, packet inter departure times and sizes,or just definitions of patterns which should be repeated with spacing according to some statistical distributions, or one could even imagine sending applets (or any similar kind of (more?) secure active agents) to generate the stream at the sender. > > * Having knowledge about send times allows to detect losses in a more > timely manner. Imagine that a (very long) session starts, goes on > for two hours, and then connectivity is lost completely. Neither > the receiver nor the sender notice anything until the connectivity > is restored and the receiver gets a packet with a sequence number > that's much larger than what it expects. ("When no packets are > coming, is it the network or is it just such a send schedule?") A very simple solution to this case is to send the sending time (or rather the expected duration of the the measurement session (it might by more useful with not too reliably synchronised hosts)) of the last packet to be sent to the receiver (include it in the session start message). > > * Not sending the schedule in advance can require the receiver to keep > more state. Under normal circumstances, just a little bit more > state; but how do you deal with a situation when somebody starts > sessions continuously and then just abandons them without notifying > you in any way? Do you wait indefinitely for more packets? The same solution applies as in the previous case. > > We believe one really needs to communicate the send schedule somehow. > (And the manner of communication is an open question for now.) As I mentioned above I agree, that it has to be communicated with the Session-Sender, but I don't think that it should be communicated to the receiver, and I definitely don't think that the receiver needs this information to be able to detect losses. By the way, why is this protocol called One-Way delay measurement protocol? Based on what is described in the draft and on the comments from the ongoing discussion I think it would be much more appropriate to call it Active measurement protocol (or something similar, but definitely more general than one-way delay) as using the time stamps and serial numbers recorded during these measurements much richer set of metrics can be obtained than just the one-way delay. Regards, Attila _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jun 4 11:55:10 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10940 for ; Mon, 4 Jun 2001 11:55:09 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f54Fs3J06899; Mon, 4 Jun 2001 11:54:03 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f54FrCJ06843 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Mon, 4 Jun 2001 11:53:16 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f54FrBS03598 for ; Mon, 4 Jun 2001 11:53:11 -0400 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id 7F7CB59D; Mon, 4 Jun 2001 11:53:09 -0400 (EDT) To: ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times References: <3B125C4C.AF0DA58E@ee.mu.oz.au> <87itiilqwb.fsf_-_@cain.internet2.edu> <3B16EF7E.572EA375@ee.mu.oz.au> <87r8x33o9p.fsf_-_@cain.internet2.edu> <3B1AEC08.C61DABA0@ee.mu.oz.au> From: stanislav shalunov Date: 04 Jun 2001 11:53:09 -0400 In-Reply-To: <3B1AEC08.C61DABA0@ee.mu.oz.au> Message-ID: <87ae3oqm1m.fsf@cain.internet2.edu> Lines: 105 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Attila Pasztor writes: > If you want to detect times when losses occur, the only way to do it > is to make the nodes report when they drop a packet ( I don't think > that anyone would really want to do this). The next best estimate > of the time of the packet loss is an interval given by the send time > and the loss detection time-out. It's my understanding of RFC2679 that the time that is reported with a loss is the time when the sender has transmitted the first bit of the packet in question (and certainly not the time when some router has decided to discard it from the queue or whatever). Quoting RFC2679 section 3.4: # >>The *Type-P-One-way-Delay* from Src to Dst at T is undefined # (informally, infinite)<< means that Src sent the first bit of a # Type-P packet to Dst at wire-time T and that Dst did not receive that # packet. > I agree that to get this information (by the way, what is it good > for?), the send time has to be known. Usefulness of loss timestamps (and precise timestamps) is really an RFC2679 question. A practical situation where you'd want this: You have a mesh of test streams between various sites; each stream is some random stream with an average of 1pps; you suspect that egress side of a certain site's connection experiences burst loss (high loss probability during a period of time of a few milliseconds every few seconds); you want to figure out the average duration of the loss; you get all three dozens of measurement sessions from that site to anywhere and correlate loss times. > If one really wants to get this information it could easily be > generated by the server (who is contacted anyway by the > retrieve-client, to provide him with the results). Retrieve-Client today only talks to the Server (which may represent Session-Receiver only). Informally, you don't need to ask the sender any questions to get the results. > I fully agree that the schedule has to be sent to the > Session-sender, but I don't think, as I have earlier mentioned, that > there is a need to send the schedule to the receiver. See previous sentence. > There are several ways to do it, send a compressed table of the > measurement start time, packet inter departure times and sizes,or > just definitions of patterns which should be repeated with spacing > according to some statistical distributions, or one could even > imagine sending applets (or any similar kind of (more?) secure > active agents) to generate the stream at the sender. These are all being considered. A way to compress the send schedule so that: 1. It's relatively simple 2. It compresses most common cases into O(1) bytes 3. It allows to send arbitrary schedule is required. Sending Turing-complete description (such as a Java applet or a vax binary) is provably the best way to do that (asymptotically best after an additive constant). Unfortunately, executing the instructions is cumbersome and there's no way to tell whether something is a valid time schedule specification. > > * Having knowledge about send times allows to detect losses in a more > > timely manner. Imagine that a (very long) session starts, goes on > > for two hours, and then connectivity is lost completely. Neither > > the receiver nor the sender notice anything until the connectivity > > is restored and the receiver gets a packet with a sequence number > > that's much larger than what it expects. ("When no packets are > > coming, is it the network or is it just such a send schedule?") > > A very simple solution to this case is to send the sending time (or > rather the expected duration of the the measurement session (it > might by more useful with not too reliably synchronised hosts)) of > the last packet to be sent to the receiver (include it in the > session start message). Doesn't appear to solve the problem. A session that's expected to last a week starts. Two hours into the session, 7000 packets are received. During the next day no packets are received (this is actually due to a network outage). Then packet trickle resumes. When does the receiver learn that there was packet loss? When connectivity is resumed and it sees the first packet with the wrong sequence number. Sender knows it sends one packet per second on average, but it never during the session learns what packets the receiver sees. If the function of the session were to alert somebody to connectivity loss, the function isn't fulfilled. If send schedule were known in advance to the receiver, then it would detect that losses are occuring after a timeout would expire after connectivity loss. > By the way, why is this protocol called One-Way delay measurement > protocol? Maybe a poor name choice indeed (essentially a codename; I don't know when it started). I'm not sure if we're stuck with the name now. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Beware of Programmers who carry screwdrivers. -- Leonard Brandwein _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 5 07:40:26 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15664 for ; Tue, 5 Jun 2001 07:40:25 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55Bd3J05561; Tue, 5 Jun 2001 07:39:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55BcRJ05459 for ; Tue, 5 Jun 2001 07:38:28 -0400 Received: from localhost (henk@localhost) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id NAA03449; Tue, 5 Jun 2001 13:38:13 +0200 (CEST) Date: Tue, 5 Jun 2001 13:38:13 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Attila Pasztor cc: stanislav shalunov , Darryl Neil Veitch , ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...) In-Reply-To: <3B16EF7E.572EA375@ee.mu.oz.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Attila, > Please, explain to me, why do we need to communicate the packet send > schedule beforehand to be able to detect losses? Suppose a destination has received packets 1 to N from a source and after that nothing. There are now 2 possibilities: packet N+1 was never scheduled to be sent _or_ N+1, N+2, ... have all been lost. With just sequence numbers, there is no way dest can know if N+1 was scheduled to be sent. With a schedule, the destination knows that N+1 was scheduled to be sent, so if it didn't arrive, it either must have been lost _or_ something is wrong with the source. How useful the second scenario is, depends on the reliability of the source and the packet-rate, but I don't think we should exlude this in the design. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 5 08:11:56 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16798 for ; Tue, 5 Jun 2001 08:11:56 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55CB2J10754; Tue, 5 Jun 2001 08:11:02 -0400 Received: from emulab.ee.mu.oz.au (potoroo.ee.mu.OZ.AU [128.250.76.186]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55CAFJ10739 for ; Tue, 5 Jun 2001 08:10:15 -0400 X-Authentication-Warning: mailhost.advanced.org: Host potoroo.ee.mu.OZ.AU [128.250.76.186] claimed to be emulab.ee.mu.oz.au Received: from ee.mu.oz.au (IDENT:attila@wallaby.emulab.ee.mu.oz.au [10.0.0.8]) by emulab.ee.mu.oz.au (8.9.3/8.9.3) with ESMTP id WAA33805; Tue, 5 Jun 2001 22:10:05 +1000 (EST) (envelope-from a.pasztor@ee.mu.oz.au) Message-ID: <3B1CCBE0.864A3C20@ee.mu.oz.au> Date: Tue, 05 Jun 2001 22:09:04 +1000 From: Attila Pasztor X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Henk Uijterwaal (RIPE-NCC)" CC: stanislav shalunov , Darryl Neil Veitch , ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Henk, > > With a schedule, the destination knows that N+1 was scheduled to be sent, > so if it didn't arrive, it either must have been lost _or_ something is > wrong with the source. To do this it is sufficient to know the number of packets to be sent (the highest serial number to expect), the schedule is not needed for this purpose. As I mentioned earlier, if the session start message would include the number of packets and the duration of the test, both losses could be detected reliably and receiver time-out could be handled properly. The case described by Stanislav is also interesting: > A session that's expected to > last a week starts. Two hours into the session, 7000 packets are > received. During the next day no packets are received (this is > actually due to a network outage). Then packet trickle resumes. When > does the receiver learn that there was packet loss? When connectivity > is resumed and it sees the first packet with the wrong sequence > number. > According to the draft the parameters of the retrieve-session command include the begin and end seq numbers of the requested packets. The draft says " If an incomplete session is requested, all packets received so far that fall into the requested range SHOULD be returned.". In the case described by Stanislav, the server can respond all the requests on the second day with the so far received 7000 packets and comply 100% with the draft without requiring the receiver having any information about the send schedule. In the case of a complete session, based on the highest serial number all the losses can be reported. Attila _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 5 11:17:15 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23219 for ; Tue, 5 Jun 2001 11:17:12 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55FG2J20587; Tue, 5 Jun 2001 11:16:02 -0400 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f55FFmJ20558; Tue, 5 Jun 2001 11:15:48 -0400 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: "Allison Mankin" Cc: "Scott Bradner" , , , "Merike Kaeo" , Date: Tue, 5 Jun 2001 11:22:47 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Request for the IESG to consider BTC Framework as an Informational RFC Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Allison & Scott, The IPPM WG would like to submit draft-ietf-ippm-btc-framework-06.txt for consideration as an Informational RFC. The bulk transport framework has gone through an extensive period of vetting and has also been through last-call by the WG, and this last revision addresses all the concerns. In addition, Mark Allman has produced a draft for a bulk transfer metric that fits within the framework, and he has already used the metric in experimentation. Thanks, --Matt and Merike _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 5 11:29:54 2001 Received: from mailhost.advanced.org (root@[209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23468 for ; Tue, 5 Jun 2001 11:29:53 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55FS2J25537; Tue, 5 Jun 2001 11:28:02 -0400 Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55FR9J24950; Tue, 5 Jun 2001 11:27:09 -0400 Received: from minotaur.east.isi.edu (minotaur.east.isi.edu [38.218.19.202]) by east.isi.edu (8.11.3/8.9.2) with ESMTP id f55FQpK07951; Tue, 5 Jun 2001 11:26:51 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.east.isi.edu (8.11.0/8.11.0) with ESMTP id f55FR6526818; Tue, 5 Jun 2001 11:27:06 -0400 Message-Id: <200106051527.f55FR6526818@minotaur.east.isi.edu> To: "Matthew J Zekauskas" cc: "Allison Mankin" , "Scott Bradner" , mallman@grc.nasa.gov, mathis@psc.edu, "Merike Kaeo" , ippm@advanced.org Reply-To: mankin@isi.edu Subject: Re: [ippm] Request for the IESG to consider BTC Framework as an Informational RFC In-reply-to: Your message of Tue, 05 Jun 2001 11:22:47 -0400. Date: Tue, 05 Jun 2001 11:27:06 -0400 From: Allison Mankin Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Matt, Merike, Thanks for letting us know. This progress is very welcome. We'll take a look very soon and then get moving on it for IESG. Please also let iesg-secretary@ietf.org know, as this logs the document, and makes it less likely to slip through any cracks :/ Allison _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 5 12:19:26 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25025 for ; Tue, 5 Jun 2001 12:19:25 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55GG2J07228; Tue, 5 Jun 2001 12:16:02 -0400 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f55GFcJ07027 for ; Tue, 5 Jun 2001 12:15:39 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 7D1024D42E; Tue, 5 Jun 2001 12:15:35 -0400 (EDT) Received: from research.att.com (roughan@wombat.research.att.com [135.207.26.100]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id MAA27270; Tue, 5 Jun 2001 12:15:33 -0400 (EDT) Message-ID: <3B1D059C.AD4B7F57@research.att.com> Date: Tue, 05 Jun 2001 12:15:24 -0400 From: Matthew Roughan Organization: AT&T Research Labs X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: "Henk Uijterwaal (RIPE-NCC)" Cc: Attila Pasztor , stanislav shalunov , Darryl Neil Veitch , ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit "Henk Uijterwaal (RIPE-NCC)" wrote: > > Attila, > > > Please, explain to me, why do we need to communicate the packet send > > schedule beforehand to be able to detect losses? > > Suppose a destination has received packets 1 to N from a source and after > that nothing. There are now 2 possibilities: packet N+1 was never > scheduled to be sent _or_ N+1, N+2, ... have all been lost. > > With just sequence numbers, there is no way dest can know if N+1 was > scheduled to be sent. > > With a schedule, the destination knows that N+1 was scheduled to be sent, > so if it didn't arrive, it either must have been lost _or_ something is > wrong with the source. > > How useful the second scenario is, depends on the reliability of the > source and the packet-rate, but I don't think we should exlude this > in the design. > > Henk > Hi What about including a max-interval time threshold, either statistical, or absolute. Rather than specify everything, specify the longest interval between packets. In many cases, this would not be too large. Certainly small enough to allow fast detection of the sort of event you describe. Sending one number is a lot easier than sending a schedule. Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 6 04:01:23 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23332 for ; Wed, 6 Jun 2001 04:01:22 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f56803J09898; Wed, 6 Jun 2001 04:00:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f567xBJ09736 for ; Wed, 6 Jun 2001 03:59:12 -0400 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 JAA00566; Wed, 6 Jun 2001 09:59:09 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id JAA21490; Wed, 6 Jun 2001 09:59:09 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 6 Jun 2001 09:59:09 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Matthew Roughan cc: ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...) In-Reply-To: <3B1D059C.AD4B7F57@research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Tue, 5 Jun 2001, Matthew Roughan wrote: > "Henk Uijterwaal (RIPE-NCC)" wrote: > > > > Attila, > > > > > Please, explain to me, why do we need to communicate the packet send > > > schedule beforehand to be able to detect losses? > > > > Suppose a destination has received packets 1 to N from a source and after > > that nothing. There are now 2 possibilities: packet N+1 was never > > scheduled to be sent _or_ N+1, N+2, ... have all been lost. > > > > With just sequence numbers, there is no way dest can know if N+1 was > > scheduled to be sent. > > > > With a schedule, the destination knows that N+1 was scheduled to be sent, > > so if it didn't arrive, it either must have been lost _or_ something is > > wrong with the source. > > > > How useful the second scenario is, depends on the reliability of the > > source and the packet-rate, but I don't think we should exlude this > > in the design. > > > > Henk > > > > Hi > > What about including a max-interval time threshold, either statistical, > or absolute. Rather than specify everything, specify the longest > interval between packets. In many cases, this would not be too large. > Certainly small enough to allow fast detection of the sort of event you > describe. Sending one number is a lot easier than sending a schedule. That requires a small modification in the scheduling but otherwise would work, I think. In the current Poisson process, one can theoretically get an interval between packets that is infinitely long. This has to be restricted, (for example) to 10 times the average interval between packets. This avoids that the maximum interval becomes infinitely long but won't distort the Poisson distribution. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 6 10:32:33 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02011 for ; Wed, 6 Jun 2001 10:32:32 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f56EV3J03077; Wed, 6 Jun 2001 10:31:03 -0400 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f56EUWJ02960 for ; Wed, 6 Jun 2001 10:30:33 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 782404DB82; Wed, 6 Jun 2001 10:30:30 -0400 (EDT) Received: from research.att.com (roughan@wombat.research.att.com [135.207.26.100]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id KAA16919; Wed, 6 Jun 2001 10:30:30 -0400 (EDT) Message-ID: <3B1E3E7D.56A4D829@research.att.com> Date: Wed, 06 Jun 2001 10:30:21 -0400 From: Matthew Roughan Organization: AT&T Research Labs X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: "Henk Uijterwaal (RIPE-NCC)" Cc: ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit > > > > Hi > > > > What about including a max-interval time threshold, either statistical, > > or absolute. Rather than specify everything, specify the longest > > interval between packets. In many cases, this would not be too large. > > Certainly small enough to allow fast detection of the sort of event you > > describe. Sending one number is a lot easier than sending a schedule. > > That requires a small modification in the scheduling but otherwise would > work, I think. > > In the current Poisson process, one can theoretically get an interval > between packets that is infinitely long. This has to be restricted, (for > example) to 10 times the average interval between packets. This avoids > that the maximum interval becomes infinitely long but won't distort the > Poisson distribution. > > Henk I was thinking that a statistical bound could be set. For instance, the probability that an interval in a Poisson process is greater than N times the mean interval is exp(-N), from memory. So set the bound such that this probability is small relative to the length of measurement to be performed. Obviously this would be more difficult to calculate, and might be much larger for some theoretical processes (multifractals?). However it might make sense when designing these processes to build in a maximum interval between packets. If you want to rapidly detect a loss event, this would be a requirement in any case. Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 6 10:44:50 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02354 for ; Wed, 6 Jun 2001 10:44:49 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f56Ei2J07063; Wed, 6 Jun 2001 10:44:02 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f56EhWJ06764 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Wed, 6 Jun 2001 10:43:36 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f56EhU128062 for ; Wed, 6 Jun 2001 10:43:30 -0400 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id 6EE73619; Wed, 6 Jun 2001 10:43:25 -0400 (EDT) To: ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...) References: <3B1D059C.AD4B7F57@research.att.com> From: stanislav shalunov Date: 06 Jun 2001 10:43:25 -0400 In-Reply-To: <3B1D059C.AD4B7F57@research.att.com> Message-ID: <87ae3lk6sy.fsf@cain.internet2.edu> Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Matthew Roughan writes: > What about including a max-interval time threshold, either > statistical, or absolute. This would address one of the problems with receiver not knowing the schedule I have listed (timely loss detection). Inability of the receiver to tie loss events to specific times, as required by the standard remains. So, you'd need to collect results both from the sender and from the receiver (which may be operationally inconvenient--data retention has to be synchronized, you need more connectivity to fetch results, you need to correlate). Inability to ask a sender to send you some specific test stream remains as well. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Democracy is a form of government that substitutes election by the incompetent many for appointment by the corrupt few. -- G. B. Shaw _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 6 11:06:11 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02712 for ; Wed, 6 Jun 2001 11:06:11 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f56F53J15963; Wed, 6 Jun 2001 11:05:03 -0400 Received: from tadarida.theasis.com (tadarida.theasis.com [206.9.240.247]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f56F4pJ15936 for ; Wed, 6 Jun 2001 11:04:52 -0400 Received: from localhost (andy@localhost) by tadarida.theasis.com (8.9.2/8.9.2) with SMTP id KAA19489 for ; Wed, 6 Jun 2001 10:03:08 -0500 (CDT) X-Authentication-Warning: tadarida.theasis.com: andy owned process doing -bs Date: Wed, 6 Jun 2001 10:03:08 -0500 (CDT) From: Andy Scherrer X-Sender: andy@tadarida.theasis.com To: ippm@advanced.org Subject: Re: [ippm] OWDP inter-packet times (Was: IP Delay variation...) In-Reply-To: <3B1E3E7D.56A4D829@research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Wed, 6 Jun 2001, Matthew Roughan wrote: > I was thinking that a statistical bound could be set. For instance, the > probability that an interval in a Poisson process is greater than N > times the mean interval is exp(-N), from memory. So set the bound such > that this probability is small relative to the length of measurement to > be performed. The Exponential interpacket times already set a (low) probability on these very long delays. To modify that, you can simply truncate the distribution by imposing a max value, or you can combine/condition it with yet another distribution, so that in effect you have 2 or more different distributions. E.g., if you generate a delay greater than X, then regenerate it according to some other dist. That simply makes the whole task that much more complicated, and remember that such complication shows up at the other end after it's been further perturbed by the network (which is what you're actually trying to measure). > make sense when designing these processes to build in a maximum interval > between packets. If you want to rapidly detect a loss event, this would > be a requirement in any case. That much sounds reasonable; but it is equivalent to truncation of the distribution. Andy > Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 7 22:47:03 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19804 for ; Thu, 7 Jun 2001 22:47:03 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f582j3J22819; Thu, 7 Jun 2001 22:45:03 -0400 Received: from young (d139-kauai-lih0.midpac.net [204.149.167.139] (may be forged)) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f582iBJ22782 for ; Thu, 7 Jun 2001 22:44:12 -0400 X-Authentication-Warning: mailhost.advanced.org: Host d139-kauai-lih0.midpac.net [204.149.167.139] (may be forged) claimed to be young Message-ID: <13146200165823647540@young> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: ippm@advanced.org Date: Thu, 7 Jun 2001 16:36:47 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f582iBJ22782 Subject: [ippm] Your Order (MLM Plan) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit Dear Friend, here is your Multi-Level Marketing Plan: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Mitchell P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: C. Shaw P.O. Box 468 Schomberg, Ontario Canada L0G IT0 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat Jun 9 11:08:20 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15106 for ; Sat, 9 Jun 2001 11:08:20 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f59F72J00399; Sat, 9 Jun 2001 11:07:02 -0400 Received: from mail.cad.zju.edu.cn ([210.32.131.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f59F65J32750 for ; Sat, 9 Jun 2001 11:06:05 -0400 X-Authentication-Warning: mailhost.advanced.org: Host [210.32.131.2] claimed to be mail.cad.zju.edu.cn Received: (qmail 32283 invoked from network); 9 Jun 2001 14:41:02 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 9 Jun 2001 14:41:02 -0000 Message-ID: <3B22353F.9F42E866@cad.zju.edu.cn> Date: Sat, 09 Jun 2001 22:39:59 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org CC: mpls-ops@mplsrc.com, mpls-linux-general@lists.sourceforge.net Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Subject: [ippm] Measure the delay jitter of video stream over MPLS network? Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi: Execuse me for my stupid question, but I really need help on this question. I've just setup a little test bed with MPLS & QoS enabled. I want to measure the effect of QoS enabled MPLS channel on video streams. I hope the test should be as simple as possible. I've download a little tool named mpeg_video which is a mpeg-1 decoder. I place the mpeg-1 files on one end of the testbed(linux) and mpeg-1 decoder on the other end ( Solaris box). The decoder use NFS to fetch the content to play. After reading the source code of the mpeg-1 decoder I find I can just record the start and stop time of each frame, while I want to measure the delay and delay jitter of each stream. And, I don't know if there is a free tool can be used to generate a graph of jitter-frame relationship from raw data. Is there any person would like to do me a favor on this question? Thanks a lot . Regards James Shen _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat Jun 9 21:33:25 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21353 for ; Sat, 9 Jun 2001 21:33:25 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5A1W3J15718; Sat, 9 Jun 2001 21:32:03 -0400 Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.29]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f5A1VYJ15696 for ; Sat, 9 Jun 2001 21:31:35 -0400 Received: From cse.unsw.edu.au ([129.94.210.112] == anya.orchestra.cse.unsw.EDU.AU) (for ) (for ) (for ) (for ) By note With Smtp ; Sun, 10 Jun 2001 11:31:21 +1000 From: "Jizhong (Jim) Wu" To: jshen@cad.zju.edu.cn Date: Sun, 10 Jun 2001 11:31:20 +1000 Message-ID: <3B22CDE8.349720DB@cse.unsw.edu.au> Organization: CSE, UNSW X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 CC: ippm@advanced.org, mpls-ops@mplsrc.com, mpls-linux-general@lists.sourceforge.net Subject: Re: [ippm] Measure the delay jitter of video stream over MPLS network? References: <3B22353F.9F42E866@cad.zju.edu.cn> Content-Type: multipart/alternative; boundary="------------3C7CB8EAB29D14F8B0102469" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --------------3C7CB8EAB29D14F8B0102469 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Hi James, What's the transport protocol you used? If you use RTP, the 'time stamp' may be helpful. Jim Jing Shen wrote: > Hi: > > Execuse me for my stupid question, but I really need help > on this question. > > I've just setup a little test bed with MPLS & QoS enabled. > I want to measure the effect of QoS enabled MPLS channel > on video streams. I hope the test should be as simple as possible. > > I've download a little tool named mpeg_video > which is a mpeg-1 decoder. I place the mpeg-1 files > on one end of the testbed(linux) and mpeg-1 decoder on the other > end ( Solaris box). The decoder use NFS to fetch the content to play. > After reading the source code of the mpeg-1 decoder I find I > can just record the start and stop time of each frame, while I want to > measure the delay and delay jitter of each stream. And, I don't know if > there > is a free tool can be used to generate a graph of jitter-frame > relationship > from raw data. > > Is there any person would like to do me a favor on this question? > > Thanks a lot . > > Regards > > James Shen > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm -- ================================================================= Jim Wu jimw@cse.unsw.edu.au School of Computer Sci. & Eng. FAX: +61 2 9385 5995 The University of New South Wales Tel: +61 2 9385 4358 UNSW SYDNEY, NSW 2052 http://www.cse.unsw.edu.au/~jimw Australia ================================================================= --------------3C7CB8EAB29D14F8B0102469 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 7bit Hi James,

What's the transport protocol you used? If you use RTP, the 'time stamp' may be helpful.

Jim

Jing Shen wrote:

Hi:

Execuse me for my stupid question, but I really need help
on this question.

I've just setup a little test bed with MPLS & QoS enabled.
I want to measure the effect of QoS enabled MPLS channel
on video streams. I hope the test should be as simple as possible.

I've download a little tool named mpeg_video
which is a mpeg-1 decoder. I place the mpeg-1 files
on one end of the testbed(linux)  and mpeg-1 decoder on the other
end ( Solaris box). The decoder use NFS to fetch the content to play.
After reading the source code of the mpeg-1 decoder I find I
can just record the start and stop time of each frame, while I want to
measure the delay and delay jitter of each stream. And, I don't know if
there
is a free tool  can be used to generate a  graph of jitter-frame
relationship
from raw data.

Is there any person would like to do me a favor on this question?

Thanks a lot .

Regards

James Shen

_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm

-- 
=================================================================
Jim Wu                                 jimw@cse.unsw.edu.au
School of Computer Sci. & Eng.         FAX:   +61 2 9385 5995
The University of New South Wales      Tel:   +61 2 9385 4358
UNSW SYDNEY, NSW 2052                  http://www.cse.unsw.edu.au/~jimw
Australia
=================================================================
  --------------3C7CB8EAB29D14F8B0102469-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 04:41:44 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10940 for ; Tue, 12 Jun 2001 04:41:43 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5C8c3J12082; Tue, 12 Jun 2001 04:38:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5C8bGJ11855 for ; Tue, 12 Jun 2001 04:37:18 -0400 Received: from laptop.6bone.nl (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with SMTP id KAA25533 for ; Tue, 12 Jun 2001 10:37:13 +0200 (CEST) Received: (nullmailer pid 31671 invoked by uid 1000); Tue, 12 Jun 2001 08:37:13 -0000 Date: Tue, 12 Jun 2001 10:37:13 +0200 From: Mark Santcroos To: ippm@advanced.org Message-ID: <20010612103713.F25918@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Subject: [ippm] bandwidth measuring/estimating Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi, I am looking into calculating/estimating bandwidth on the Internet. I know about the BTC framework and the corresponding metric, but that is not what we are looking for in our project (www.ripe.net/test-traffic/). The reason for that is that we don't want to regularly fill the line while doing our measurements. Better would be something like 'pathchar', described and implemented by Van Jacobson. (And since then some other implementations) I'm curious if any effort has been made into standardizing this work. Also I am wondering if the IPPM would be the right place to discuss this. Following to that, is the nature of the measurements, based on estimation, suited for being discussed here and possibly become a standard? Thanks in advance, Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 10:03:58 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15423 for ; Tue, 12 Jun 2001 10:03:57 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CE03J09702; Tue, 12 Jun 2001 10:00:03 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CDxjJ09673 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Tue, 12 Jun 2001 09:59:49 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CDxh109601; Tue, 12 Jun 2001 09:59:43 -0400 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id B74BD65F; Tue, 12 Jun 2001 09:59:42 -0400 (EDT) To: Mark Santcroos Cc: ippm@advanced.org Subject: Re: [ippm] bandwidth measuring/estimating References: <20010612103713.F25918@laptop.6bone.nl> From: stanislav shalunov Date: 12 Jun 2001 09:59:42 -0400 In-Reply-To: <20010612103713.F25918@laptop.6bone.nl> Message-ID: <87bsntol2p.fsf@cain.internet2.edu> Lines: 42 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Mark Santcroos writes: > I am looking into calculating/estimating bandwidth on the Internet. > > I know about the BTC framework and the corresponding metric, but > that is not what we are looking for in our project > (www.ripe.net/test-traffic/). The reason for that is that we don't > want to regularly fill the line while doing our measurements. Mark, As far as I understand, the only currently known way to measure link capacity without filling the link (or asking the router) is to measure the serialization delay. Several techniques and programs are available for this purpose. If you're only interested in bottleneck link capacity, you could simply pass back-to-back packet pairs (and look for spacing on the other end) or packets of different sizes (and look for difference in transmission time). If you want to measure capacities of intermediate links you necessarily have to make the routers generate some packets (which usually happens in the slow path). Any of the techniques works fairly well for low speeds. For a T1, you can get a very reliable and precise capacity estimate (even with a simple tool like bing) unless the link is very heavily overloaded. However, as the bottleneck link gets faster, it becomes harder to register tiny serialization delay at all. To tell an OC-3 from an OC-12 you need to be able to tell 74us from 18us. To tell an OC-12 from an OC-48, you'd have to be able to distinguish between 18us and 5us. Further, this is complicated by the fact that in order to get an OC-whatever bottleneck you'd have to have very well connected measurement nodes. You probably would have to think at least about timestamping in the driver and Gigabit Ethernet connections... Note that to measure these high speeds within BTC framework you still need to overcome significant difficulties (bus bandwidth, etc.). Good luck, -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at sea level. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 14:22:36 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21613 for ; Tue, 12 Jun 2001 14:22:35 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CIK3J24003; Tue, 12 Jun 2001 14:20:03 -0400 Received: from caida.org (ipn.caida.org [192.172.226.30]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CIJ3J23957 for ; Tue, 12 Jun 2001 14:19:03 -0400 X-Authentication-Warning: mailhost.advanced.org: Host ipn.caida.org [192.172.226.30] claimed to be caida.org Received: (from kc@localhost) by caida.org (8.9.3+Sun/8.9.1) id LAA12274; Tue, 12 Jun 2001 11:18:51 -0700 (PDT) Date: Tue, 12 Jun 2001 11:18:50 -0700 From: k claffy To: Mark Santcroos Cc: ippm@advanced.org, bwest@caida.org, marg@caida.org Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010612111850.C12234@caida.org> References: <20010612103713.F25918@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010612103713.F25918@laptop.6bone.nl>; from marks@ripe.net on Tue, Jun 12, 2001 at 10:37:13AM +0200 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List margaret did a survey page of these in preparation for a proposal we wrote to try to work on this topic (const, downey, mah) http://www.caida.org/analysis/performance/bandwidth/ bloody hard problem k On Tue, Jun 12, 2001 at 10:37:13AM +0200, Mark Santcroos wrote: Hi, I am looking into calculating/estimating bandwidth on the Internet. I know about the BTC framework and the corresponding metric, but that is not what we are looking for in our project (www.ripe.net/test-traffic/). The reason for that is that we don't want to regularly fill the line while doing our measurements. Better would be something like 'pathchar', described and implemented by Van Jacobson. (And since then some other implementations) I'm curious if any effort has been made into standardizing this work. Also I am wondering if the IPPM would be the right place to discuss this. Following to that, is the nature of the measurements, based on estimation, suited for being discussed here and possibly become a standard? Thanks in advance, Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 14:40:02 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22187 for ; Tue, 12 Jun 2001 14:40:02 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CIc2J29228; Tue, 12 Jun 2001 14:38:02 -0400 Received: from seraph3.lerc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f5CIbnJ29012 for ; Tue, 12 Jun 2001 14:37:50 -0400 Received: by seraph3.lerc.nasa.gov; id OAA00757; Tue, 12 Jun 2001 14:37:47 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000728; Tue, 12 Jun 01 14:37:30 -0400 Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA07418; Tue, 12 Jun 2001 14:37:29 -0400 (EDT) Received: from guns.lerc.nasa.gov (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA12907; Tue, 12 Jun 2001 14:37:37 -0400 Message-Id: <200106121837.OAA12907@guns.lerc.nasa.gov> To: Mark Santcroos From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: ippm@advanced.org Subject: Re: [ippm] bandwidth measuring/estimating Organization: BBN Technologies/NASA GRC Song-of-the-Day: Under the Bridge Date: Tue, 12 Jun 2001 14:37:37 -0400 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Mark- > Better would be something like 'pathchar', described and > implemented by Van Jacobson. (And since then some other > implementations) While pathchar may not fill the pipe it definatly sends quite a bit of traffic into the network over the course of quite a long time in some cases. This might not actually be what you're looking for either. allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 15:25:30 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22968 for ; Tue, 12 Jun 2001 15:25:30 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CJN2J11556; Tue, 12 Jun 2001 15:23:02 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CJMgJ11447 for ; Tue, 12 Jun 2001 15:22:42 -0400 Received: from laptop.6bone.nl (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with SMTP id VAA19301; Tue, 12 Jun 2001 21:22:37 +0200 (CEST) Received: (nullmailer pid 38434 invoked by uid 1000); Tue, 12 Jun 2001 19:22:36 -0000 Date: Tue, 12 Jun 2001 21:22:36 +0200 From: Mark Santcroos To: stanislav shalunov Cc: ippm@advanced.org Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010612212236.E36480@laptop.6bone.nl> References: <20010612103713.F25918@laptop.6bone.nl> <87bsntol2p.fsf@cain.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87bsntol2p.fsf@cain.internet2.edu>; from shalunov@internet2.edu on Tue, Jun 12, 2001 at 09:59:42AM -0400 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Stanislav, Accurate timekeeping is not a problem for us; Our boxes are equiped with GPS. While the quality of the method is of course important, an important drive for us is also that we want to follow standards. (Or develop one) That way we can make the testbox an implementation independent measurement device. (Just as with the OWDP) As for the bottleneck versus intermediate link capacity: Currently we are only measuring end-to-end on the Internet. Measuring bottlenecks is therefor not very useful now. However, we plan to install testboxes at reference points (IX's for example), which will make it far more interesting to know bottlenecks then. Also, you mention fitting it within the BTC framework, I don't think that is suited or wanted, do you? Mark On Tue, Jun 12, 2001 at 09:59:42AM -0400, stanislav shalunov wrote: > Mark Santcroos writes: > > > I am looking into calculating/estimating bandwidth on the Internet. > > > > I know about the BTC framework and the corresponding metric, but > > that is not what we are looking for in our project > > (www.ripe.net/test-traffic/). The reason for that is that we don't > > want to regularly fill the line while doing our measurements. > > Mark, > > As far as I understand, the only currently known way to measure link > capacity without filling the link (or asking the router) is to measure > the serialization delay. Several techniques and programs are > available for this purpose. If you're only interested in bottleneck > link capacity, you could simply pass back-to-back packet pairs (and > look for spacing on the other end) or packets of different sizes (and > look for difference in transmission time). If you want to measure > capacities of intermediate links you necessarily have to make the > routers generate some packets (which usually happens in the slow > path). > > Any of the techniques works fairly well for low speeds. For a T1, you > can get a very reliable and precise capacity estimate (even with a > simple tool like bing) unless the link is very heavily overloaded. > However, as the bottleneck link gets faster, it becomes harder to > register tiny serialization delay at all. To tell an OC-3 from an > OC-12 you need to be able to tell 74us from 18us. To tell an OC-12 > from an OC-48, you'd have to be able to distinguish between 18us and > 5us. Further, this is complicated by the fact that in order to get an > OC-whatever bottleneck you'd have to have very well connected > measurement nodes. You probably would have to think at least about > timestamping in the driver and Gigabit Ethernet connections... > > Note that to measure these high speeds within BTC framework you still > need to overcome significant difficulties (bus bandwidth, etc.). > > Good luck, > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > This message is designed to be viewed at sea level. -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 15:26:26 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22980 for ; Tue, 12 Jun 2001 15:26:26 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CJQ2J12669; Tue, 12 Jun 2001 15:26:02 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CJPlJ12458 for ; Tue, 12 Jun 2001 15:25:47 -0400 Received: from laptop.6bone.nl (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with SMTP id VAA19916; Tue, 12 Jun 2001 21:25:40 +0200 (CEST) Received: (nullmailer pid 38466 invoked by uid 1000); Tue, 12 Jun 2001 19:25:40 -0000 Date: Tue, 12 Jun 2001 21:25:40 +0200 From: Mark Santcroos To: k claffy Cc: ippm@advanced.org, bwest@caida.org, marg@caida.org Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010612212539.F36480@laptop.6bone.nl> References: <20010612103713.F25918@laptop.6bone.nl> <20010612111850.C12234@caida.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010612111850.C12234@caida.org>; from kc@ipn.caida.org on Tue, Jun 12, 2001 at 11:18:50AM -0700 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi, I'm familiar with that section of your website. What's the status of the proposal and is it public? Mark On Tue, Jun 12, 2001 at 11:18:50AM -0700, k claffy wrote: > > > margaret did a survey page of these in preparation > for a proposal we wrote to try to work on this topic > (const, downey, mah) > http://www.caida.org/analysis/performance/bandwidth/ > > bloody hard problem > k > > On Tue, Jun 12, 2001 at 10:37:13AM +0200, Mark Santcroos wrote: > Hi, > > I am looking into calculating/estimating bandwidth on the Internet. > > I know about the BTC framework and the corresponding metric, but that is > not what we are looking for in our project (www.ripe.net/test-traffic/). > The reason for that is that we don't want to regularly fill the line > while doing our measurements. > > Better would be something like 'pathchar', described and implemented by > Van Jacobson. (And since then some other implementations) > > I'm curious if any effort has been made into standardizing this work. > > Also I am wondering if the IPPM would be the right place to discuss this. > Following to that, is the nature of the measurements, based on estimation, > suited for being discussed here and possibly become a standard? > > Thanks in advance, > > Mark > > > -- > Mark Santcroos RIPE Network Coordination Centre > http://www.ripe.net/home/mark/ New Projects Group/TTM > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 15:28:29 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23014 for ; Tue, 12 Jun 2001 15:28:28 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CJS2J14331; Tue, 12 Jun 2001 15:28:02 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CJRmJ14114 for ; Tue, 12 Jun 2001 15:27:48 -0400 Received: from laptop.6bone.nl (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with SMTP id VAA20166; Tue, 12 Jun 2001 21:27:43 +0200 (CEST) Received: (nullmailer pid 38481 invoked by uid 1000); Tue, 12 Jun 2001 19:27:43 -0000 Date: Tue, 12 Jun 2001 21:27:43 +0200 From: Mark Santcroos To: Mark Allman Cc: ippm@advanced.org Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010612212743.G36480@laptop.6bone.nl> References: <200106121837.OAA12907@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106121837.OAA12907@guns.lerc.nasa.gov>; from mallman@grc.nasa.gov on Tue, Jun 12, 2001 at 02:37:37PM -0400 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Mark, It might not be exactly what we want, but I think it is more in the direction. I bet there is need for a metric that would come up with a good calculation of the capacity without using much of that capacity during the measurements. My goal is to get some people together for this. Mark On Tue, Jun 12, 2001 at 02:37:37PM -0400, Mark Allman wrote: > > Mark- > > > Better would be something like 'pathchar', described and > > implemented by Van Jacobson. (And since then some other > > implementations) > > While pathchar may not fill the pipe it definatly sends quite a bit > of traffic into the network over the course of quite a long time in > some cases. This might not actually be what you're looking for > either. > > allman > > > --- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 16:36:33 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24241 for ; Tue, 12 Jun 2001 16:36:33 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CKS3J01853; Tue, 12 Jun 2001 16:28:03 -0400 Received: from io.luxxon.com ([65.162.241.11]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CKRVJ01679 for ; Tue, 12 Jun 2001 16:27:35 -0400 X-Authentication-Warning: mailhost.advanced.org: Host [65.162.241.11] claimed to be io.luxxon.com Received: from gamze (dhcp-000-214.luxxon.com [192.168.0.214]) by io.luxxon.com (8.11.3/8.11.3) with SMTP id f5CKRQa28661; Tue, 12 Jun 2001 13:27:26 -0700 (PDT) Message-ID: <038a01c0f37e$373198c0$d600a8c0@luxxon.com> From: "Gamze Seckin" To: "Mark Santcroos" , "Mark Allman" Cc: References: <200106121837.OAA12907@guns.lerc.nasa.gov> <20010612212743.G36480@laptop.6bone.nl> Subject: Re: [ippm] bandwidth measuring/estimating Date: Tue, 12 Jun 2001 13:28:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f5CKRVJ01679 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit Our research team has worked on one-way, ip level, universal and quick methods to measure bottleneck available bw. We also have looked in methods to measure asymmetric links..this is a huge challenge if you want to do one-way measurements. Some standardization process on this would definetely be interesting. Gamze Seckin, Ph.D. Luxxon Corporation www.luxxon.com ----- Original Message ----- From: "Mark Santcroos" To: "Mark Allman" Cc: Sent: Tuesday, June 12, 2001 12:27 PM Subject: Re: [ippm] bandwidth measuring/estimating > Hi Mark, > > It might not be exactly what we want, but I think it is more in the > direction. > > I bet there is need for a metric that would come up with a good > calculation of the capacity without using much of that capacity during the > measurements. > > My goal is to get some people together for this. > > Mark > > > > > On Tue, Jun 12, 2001 at 02:37:37PM -0400, Mark Allman wrote: > > > > Mark- > > > > > Better would be something like 'pathchar', described and > > > implemented by Van Jacobson. (And since then some other > > > implementations) > > > > While pathchar may not fill the pipe it definatly sends quite a bit > > of traffic into the network over the course of quite a long time in > > some cases. This might not actually be what you're looking for > > either. > > > > allman > > > > > > --- > > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > > -- > Mark Santcroos RIPE Network Coordination Centre > http://www.ripe.net/home/mark/ New Projects Group/TTM > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 16:37:12 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24265 for ; Tue, 12 Jun 2001 16:37:12 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CKX2J02249; Tue, 12 Jun 2001 16:33:02 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CKWsJ02235 for ; Tue, 12 Jun 2001 16:32:55 -0400 Received: from laptop.6bone.nl (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with SMTP id WAA29358; Tue, 12 Jun 2001 22:32:26 +0200 (CEST) Received: (nullmailer pid 39076 invoked by uid 1000); Tue, 12 Jun 2001 20:32:25 -0000 Date: Tue, 12 Jun 2001 22:32:25 +0200 From: Mark Santcroos To: Gamze Seckin Cc: ippm@advanced.org Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010612223225.L36480@laptop.6bone.nl> References: <200106121837.OAA12907@guns.lerc.nasa.gov> <20010612212743.G36480@laptop.6bone.nl> <038a01c0f37e$373198c0$d600a8c0@luxxon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <038a01c0f37e$373198c0$d600a8c0@luxxon.com>; from Gamze.Seckin@luxxon.com on Tue, Jun 12, 2001 at 01:28:16PM -0700 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List We don't require one-way measurements as we operate a measurements network. To IPPM: what would be the process of trying to establish a standard? Would it be wise, as with BTC, to come up with a framework first? Please enlighten me on this. Thanks Mark On Tue, Jun 12, 2001 at 01:28:16PM -0700, Gamze Seckin wrote: > Our research team has worked on one-way, ip level, universal and quick methods to measure bottleneck available bw. > We also have looked in methods to measure asymmetric links..this is a huge challenge if you want to do one-way measurements. > Some standardization process on this would definetely be interesting. > > > Gamze Seckin, Ph.D. > Luxxon Corporation > www.luxxon.com > > > ----- Original Message ----- > From: "Mark Santcroos" > To: "Mark Allman" > Cc: > Sent: Tuesday, June 12, 2001 12:27 PM > Subject: Re: [ippm] bandwidth measuring/estimating > > > > Hi Mark, > > > > It might not be exactly what we want, but I think it is more in the > > direction. > > > > I bet there is need for a metric that would come up with a good > > calculation of the capacity without using much of that capacity during the > > measurements. > > > > My goal is to get some people together for this. > > > > Mark > > > > > > > > > > On Tue, Jun 12, 2001 at 02:37:37PM -0400, Mark Allman wrote: > > > > > > Mark- > > > > > > > Better would be something like 'pathchar', described and > > > > implemented by Van Jacobson. (And since then some other > > > > implementations) > > > > > > While pathchar may not fill the pipe it definatly sends quite a bit > > > of traffic into the network over the course of quite a long time in > > > some cases. This might not actually be what you're looking for > > > either. > > > > > > allman > > > > > > > > > --- > > > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > > > > -- > > Mark Santcroos RIPE Network Coordination Centre > > http://www.ripe.net/home/mark/ New Projects Group/TTM > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 16:55:05 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24469 for ; Tue, 12 Jun 2001 16:55:04 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CKr3J08673; Tue, 12 Jun 2001 16:53:03 -0400 Received: from portnoy.lbl.gov (portnoy.lbl.gov [131.243.2.11]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CKqTJ08653 for ; Tue, 12 Jun 2001 16:52:29 -0400 Received: from lbl.gov (wile.lbl.gov [131.243.2.62]) by portnoy.lbl.gov (8.11.1/8.11.1) with ESMTP id f5CKqAJ03655; Tue, 12 Jun 2001 13:52:10 -0700 (PDT) Message-ID: <3B268108.C77A1352@lbl.gov> Date: Tue, 12 Jun 2001 13:52:24 -0700 From: Deb Agarwal Reply-To: DAAgarwal@lbl.gov Organization: Lawrence Berkeley Laboratory X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: Mark Santcroos , ippm@advanced.org Subject: Re: [ippm] bandwidth measuring/estimating References: <200106121837.OAA12907@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Some of the people here at LBNL have also been working on the bandwidth measurement/estimation problem. The tool which they developed is called pipechar and it accomplishes similar goals to those of pathchar but using less bandwidth and with quicker results in our experience. Pipechar is available from http://www-didc.lbl.gov/NCS/ Deb -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Deb Agarwal e-mail:DAAgarwal@lbl.gov MS50B-2239 phone :(510)486-7078 Lawrence Berkeley National Lab URL: http://www-itg.lbl.gov/~deba Berkeley, CA 94720 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Allman wrote: > > Mark- > > > Better would be something like 'pathchar', described and > > implemented by Van Jacobson. (And since then some other > > implementations) > > While pathchar may not fill the pipe it definatly sends quite a bit > of traffic into the network over the course of quite a long time in > some cases. This might not actually be what you're looking for > either. > > allman > > --- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 18:24:28 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25951 for ; Tue, 12 Jun 2001 18:24:27 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5CMI2J06305; Tue, 12 Jun 2001 18:18:02 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f5CMHqJ06173 for ; Tue, 12 Jun 2001 18:17:52 -0400 X-Authentication-Warning: mailhost.advanced.org: Host louie.udel.edu [128.175.2.33] claimed to be mail.eecis.udel.edu Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa14379; 12 Jun 2001 18:17 EDT Date: Tue, 12 Jun 2001 18:17:16 -0400 (EDT) From: Constantinos Dovrolis To: Mark Santcroos cc: ippm@advanced.org, bwest@caida.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: <20010612103713.F25918@laptop.6bone.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List I would also be interested to see some IPPM work in the direction of bandwidth estimation. A critical point though is to precisely define what we mean by "bandwidth estimation". I can see at least 3 different metrics (or types of metrics): 1. Capacity C: the maximum throughput that a certain path can provide, in the absence of any competing traffic, and independent of the transport protocol or specific application that we use. People also refer to this as "raw bandwidth", or "bottleneck bandwidth" of the path. This is an important metric mainly for network management, debugging, and monitoring. While experimenting with pathrate, I found in interesting that network managers do not know often the capacity of their links. Just because you lease a 40Mbps share of a link, it does not mean that the provider will actually give you 40Mbps at all times.. 2. Available bandwidth A: this is certainly not a consistently defined metric in both the research literature and in practice. IMHO it should mean: the minimum throughput that is not used by existing traffic, across all links of the path. Intuitively, in the case of one link, this is just the "blank space" in an MRTG graph, between the bandwidth that is currently used and what is the capacity of the link. In a multi-hop path, we need to know the minimum such "blank space" across all links of the path. Again, A does not depend on a specific transport protocol. Also, it is not true that a single flow would be able to achieve A (at least without feedback from the network). Depending on how "congestion responsive" the flow is, it may get less than A, or more than A. From this point of view, A may be a more important metric for network monitoring and QoS provisioning, rather than for individual users and applications. 3. Bulk-Transfer Capacity BTC: this is the throughput that a long TCP connection connection would get from the path, if it was only limited by the network (i.e., not limited by the advertised window or the amount of data to be sent), and if TCP is implemented as in RFC2581. In some sense, this is a more pragmatic metric, as it is easier to measure, and it is directly related with what most users (at least, TCP users that create "elephant" flows) would care about. Note that each of these metrics is limited by a different part of the path. The capacity C would be limited by the link with the lowest capacity (what we call "narrow" link). The available bandwidth A would be limited by the link with the minimum unused throughput (what we call "tight" link). The BTC would probably depend on all the links of the path, since the throughput of a long TCP connection depends on the end-to-end loss rate and round-trip time (including queueing delays) that the connection encounters. I believe that there are important applications for all these three types of metrics. So far the focus of the IPPM group was on the BTC metric. Would there be any interest to consider the metrics C and A as well? Or any other metrics? Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ On Tue, 12 Jun 2001, Mark Santcroos wrote: > Hi, > > I am looking into calculating/estimating bandwidth on the Internet. > > I know about the BTC framework and the corresponding metric, but that is > not what we are looking for in our project (www.ripe.net/test-traffic/). > The reason for that is that we don't want to regularly fill the line > while doing our measurements. > > Better would be something like 'pathchar', described and implemented by > Van Jacobson. (And since then some other implementations) > > I'm curious if any effort has been made into standardizing this work. > > Also I am wondering if the IPPM would be the right place to discuss this. > Following to that, is the nature of the measurements, based on estimation, > suited for being discussed here and possibly become a standard? > > Thanks in advance, > > Mark > > > -- > Mark Santcroos RIPE Network Coordination Centre > http://www.ripe.net/home/mark/ New Projects Group/TTM > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Jun 12 20:41:28 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27490 for ; Tue, 12 Jun 2001 20:41:28 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5D0e4J03370; Tue, 12 Jun 2001 20:40:04 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5D0dtJ03346 for ; Tue, 12 Jun 2001 20:39:55 -0400 Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5CNp8F16058; Tue, 12 Jun 2001 17:36:11 -0700 (PDT) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.3/8.11.3) id f5CNqgr36044; Tue, 12 Jun 2001 16:52:42 -0700 (PDT) (envelope-from bmah) Message-Id: <200106122352.f5CNqgr36044@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.4+ 06/08/2001 with nmh-1.0.4 To: mallman@grc.nasa.gov Cc: Mark Santcroos , ippm@advanced.org Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: <200106121837.OAA12907@guns.lerc.nasa.gov> References: <200106121837.OAA12907@guns.lerc.nasa.gov> Comments: In-reply-to Mark Allman message dated "Tue, 12 Jun 2001 14:37:37 -0400." From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_2077360116P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 12 Jun 2001 16:52:42 -0700 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --==_Exmh_2077360116P Content-Type: text/plain; charset=us-ascii If memory serves me right, Mark Allman wrote: > > Better would be something like 'pathchar', described and > > implemented by Van Jacobson. (And since then some other > > implementations) > > While pathchar may not fill the pipe it definatly sends quite a bit > of traffic into the network over the course of quite a long time in > some cases. True. But all the pathchar-like programs give you the opportunity to change how many probe packets to send, or how fast they should be sent. I know I chose non-optimal defaults for pchar (pessimal?), but you can change them. :-p > This might not actually be what you're looking for > either. Also true. These programs (try to) measure raw link capacity as seen at the IP layer (with varying degrees of success depending on layer 2 characteristics). Bruce. --==_Exmh_2077360116P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE7JqtJ2MoxcVugUsMRAlNxAKDPyCfGs5RGXsg/tS/ADOB4CWvNfACeL6lU ON3HniigxEsKk6D9Ff8fadY= =+RL5 -----END PGP SIGNATURE----- --==_Exmh_2077360116P-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 13 03:12:22 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16940 for ; Wed, 13 Jun 2001 03:12:22 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5D7C3e13243; Wed, 13 Jun 2001 03:12:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5D7B5e12868 for ; Wed, 13 Jun 2001 03:11:06 -0400 Received: from laptop.6bone.nl (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with SMTP id JAA14182; Wed, 13 Jun 2001 09:10:44 +0200 (CEST) Received: (nullmailer pid 45628 invoked by uid 1000); Wed, 13 Jun 2001 06:26:17 -0000 Date: Wed, 13 Jun 2001 08:26:16 +0200 From: Mark Santcroos To: Constantinos Dovrolis Cc: ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010613082616.M36480@laptop.6bone.nl> References: <20010612103713.F25918@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dovrolis@mail.eecis.udel.edu on Tue, Jun 12, 2001 at 06:17:16PM -0400 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Constantinos, Actually how different in practice are metric A and C? I can see the difference in the definition, but in practice it would be very hard to make a difference between those two probably. (And it may be a requirement that these are handled the same way) Please explain me though if you think we should really separate those two. For now, my requirements for the metric would be: * transport protocol independent * path/link usage independent * minimal network traffic created by the measurements * link type independent (if at all possible) I think these match pretty well with your definitions. I'm looking forward to your reply. Mark On Tue, Jun 12, 2001 at 06:17:16PM -0400, Constantinos Dovrolis wrote: > > I would also be interested to see some IPPM work in the > direction of bandwidth estimation. A critical point though is > to precisely define what we mean by "bandwidth estimation". I can > see at least 3 different metrics (or types of metrics): > > 1. Capacity C: the maximum throughput that a certain path can provide, > in the absence of any competing traffic, and independent of the > transport protocol or specific application that we use. > People also refer to this as "raw bandwidth", or "bottleneck > bandwidth" of the path. This is an important metric mainly > for network management, debugging, and monitoring. While > experimenting with pathrate, I found in interesting that network > managers do not know often the capacity of their links. > Just because you lease a 40Mbps share of a link, it does > not mean that the provider will actually give you 40Mbps at all > times.. > > 2. Available bandwidth A: this is certainly not a consistently > defined metric in both the research literature and in practice. > IMHO it should mean: the minimum throughput that is not used > by existing traffic, across all links of the path. Intuitively, > in the case of one link, this is just the "blank space" in an MRTG > graph, between the bandwidth that is currently used and what > is the capacity of the link. In a multi-hop path, we need > to know the minimum such "blank space" across all links of > the path. > > Again, A does not depend on a specific transport protocol. > Also, it is not true that a single flow would be able to > achieve A (at least without feedback from the network). > Depending on how "congestion responsive" the flow is, it may > get less than A, or more than A. > From this point of view, A may be a more important metric for > network monitoring and QoS provisioning, rather than for individual > users and applications. > > 3. Bulk-Transfer Capacity BTC: this is the throughput that a > long TCP connection connection would get from the path, > if it was only limited by the network (i.e., not limited > by the advertised window or the amount of data to be sent), and > if TCP is implemented as in RFC2581. In some sense, this is > a more pragmatic metric, as it is easier to measure, and > it is directly related with what most users (at least, TCP > users that create "elephant" flows) would care about. > > Note that each of these metrics is limited by a different part > of the path. The capacity C would be limited by the link > with the lowest capacity (what we call "narrow" link). The > available bandwidth A would be limited by the link with the > minimum unused throughput (what we call "tight" link). The > BTC would probably depend on all the links of the path, since > the throughput of a long TCP connection depends on the end-to-end > loss rate and round-trip time (including queueing delays) that > the connection encounters. > > I believe that there are important applications for all these > three types of metrics. So far the focus of the IPPM group > was on the BTC metric. Would there be any interest to consider > the metrics C and A as well? Or any other metrics? > > > Constantinos > > Computer and Information Sciences - University of Delaware > > http://www.cis.udel.edu/~dovrolis/ > > On Tue, 12 Jun 2001, Mark Santcroos wrote: > > > Hi, > > > > I am looking into calculating/estimating bandwidth on the Internet. > > > > I know about the BTC framework and the corresponding metric, but that is > > not what we are looking for in our project (www.ripe.net/test-traffic/). > > The reason for that is that we don't want to regularly fill the line > > while doing our measurements. > > > > Better would be something like 'pathchar', described and implemented by > > Van Jacobson. (And since then some other implementations) > > > > I'm curious if any effort has been made into standardizing this work. > > > > Also I am wondering if the IPPM would be the right place to discuss this. > > Following to that, is the nature of the measurements, based on estimation, > > suited for being discussed here and possibly become a standard? > > > > Thanks in advance, > > > > Mark > > > > > > -- > > Mark Santcroos RIPE Network Coordination Centre > > http://www.ripe.net/home/mark/ New Projects Group/TTM > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > > > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 13 11:58:07 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25856 for ; Wed, 13 Jun 2001 11:58:06 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5DFp3e12410; Wed, 13 Jun 2001 11:51:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5DFoGe12294 for ; Wed, 13 Jun 2001 11:50:16 -0400 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 RAA03608; Wed, 13 Jun 2001 17:50:11 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id RAA01242; Wed, 13 Jun 2001 17:50:11 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 13 Jun 2001 17:50:11 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Mark Santcroos cc: Constantinos Dovrolis , ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: <20010613082616.M36480@laptop.6bone.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Wed, 13 Jun 2001, Mark Santcroos wrote: > Hi Constantinos, > > Actually how different in practice are metric A and C? Huge, I'd guess: C is a property of the path, independent of the usageof the path, while A is determined by the path and the usage. If C is 40 Mbps and there is no traffic along the path, then A will also be 40 Mbps. However, if some application starts to send 30 Mbps on this path, then C is still 40 Mbps but A is reduced to 40-30=10 Mbps. > I can see the difference in the definition, but in practice it would be > very hard to make a difference between those two probably. (And it may be > a requirement that these are handled the same way) > Please explain me though if you think we should really separate those two. > > For now, my requirements for the metric would be: > > * transport protocol independent > * path/link usage independent > * minimal network traffic created by the measurements > * link type independent (if at all possible) > > I think these match pretty well with your definitions. > > I'm looking forward to your reply. > > Mark > > > On Tue, Jun 12, 2001 at 06:17:16PM -0400, Constantinos Dovrolis wrote: > > > > I would also be interested to see some IPPM work in the > > direction of bandwidth estimation. A critical point though is > > to precisely define what we mean by "bandwidth estimation". I can > > see at least 3 different metrics (or types of metrics): > > > > 1. Capacity C: the maximum throughput that a certain path can provide, > > in the absence of any competing traffic, and independent of the > > transport protocol or specific application that we use. > > People also refer to this as "raw bandwidth", or "bottleneck > > bandwidth" of the path. This is an important metric mainly > > for network management, debugging, and monitoring. While > > experimenting with pathrate, I found in interesting that network > > managers do not know often the capacity of their links. > > Just because you lease a 40Mbps share of a link, it does > > not mean that the provider will actually give you 40Mbps at all > > times.. > > > > 2. Available bandwidth A: this is certainly not a consistently > > defined metric in both the research literature and in practice. > > IMHO it should mean: the minimum throughput that is not used > > by existing traffic, across all links of the path. Intuitively, > > in the case of one link, this is just the "blank space" in an MRTG > > graph, between the bandwidth that is currently used and what > > is the capacity of the link. In a multi-hop path, we need > > to know the minimum such "blank space" across all links of > > the path. > > > > Again, A does not depend on a specific transport protocol. > > Also, it is not true that a single flow would be able to > > achieve A (at least without feedback from the network). > > Depending on how "congestion responsive" the flow is, it may > > get less than A, or more than A. > > From this point of view, A may be a more important metric for > > network monitoring and QoS provisioning, rather than for individual > > users and applications. > > > > 3. Bulk-Transfer Capacity BTC: this is the throughput that a > > long TCP connection connection would get from the path, > > if it was only limited by the network (i.e., not limited > > by the advertised window or the amount of data to be sent), and > > if TCP is implemented as in RFC2581. In some sense, this is > > a more pragmatic metric, as it is easier to measure, and > > it is directly related with what most users (at least, TCP > > users that create "elephant" flows) would care about. > > > > Note that each of these metrics is limited by a different part > > of the path. The capacity C would be limited by the link > > with the lowest capacity (what we call "narrow" link). The > > available bandwidth A would be limited by the link with the > > minimum unused throughput (what we call "tight" link). The > > BTC would probably depend on all the links of the path, since > > the throughput of a long TCP connection depends on the end-to-end > > loss rate and round-trip time (including queueing delays) that > > the connection encounters. > > > > I believe that there are important applications for all these > > three types of metrics. So far the focus of the IPPM group > > was on the BTC metric. Would there be any interest to consider > > the metrics C and A as well? Or any other metrics? > > > > > > Constantinos > > > > Computer and Information Sciences - University of Delaware > > > > http://www.cis.udel.edu/~dovrolis/ > > > > On Tue, 12 Jun 2001, Mark Santcroos wrote: > > > > > Hi, > > > > > > I am looking into calculating/estimating bandwidth on the Internet. > > > > > > I know about the BTC framework and the corresponding metric, but that is > > > not what we are looking for in our project (www.ripe.net/test-traffic/). > > > The reason for that is that we don't want to regularly fill the line > > > while doing our measurements. > > > > > > Better would be something like 'pathchar', described and implemented by > > > Van Jacobson. (And since then some other implementations) > > > > > > I'm curious if any effort has been made into standardizing this work. > > > > > > Also I am wondering if the IPPM would be the right place to discuss this. > > > Following to that, is the nature of the measurements, based on estimation, > > > suited for being discussed here and possibly become a standard? > > > > > > Thanks in advance, > > > > > > Mark > > > > > > > > > -- > > > Mark Santcroos RIPE Network Coordination Centre > > > http://www.ripe.net/home/mark/ New Projects Group/TTM > > > _______________________________________________ > > > ippm mailing list > > > ippm@advanced.org > > > http://mailhost.advanced.org/mailman/listinfo/ippm > > > > > > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > > -- > Mark Santcroos RIPE Network Coordination Centre > http://www.ripe.net/home/mark/ New Projects Group/TTM > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 13 17:16:37 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01781 for ; Wed, 13 Jun 2001 17:16:36 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5DLE2e30546; Wed, 13 Jun 2001 17:14:02 -0400 Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5DLDae30439 for ; Wed, 13 Jun 2001 17:13:36 -0400 Received: from durian ([166.60.2.77]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with ESMTP id <01K4Q556G9Y29ZO5WX@shoe.reston.mci.net> for ippm@advanced.org; Wed, 13 Jun 2001 17:13:33 -0400 (EDT) Date: Wed, 13 Jun 2001 17:05:59 -0400 (EDT) From: Jambi Ganbar Subject: Re: [ippm] bandwidth measuring/estimating In-reply-to: X-Sender: bigj@durian Cc: ippm@advanced.org, bwest@caida.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7BIT Const and all, > 1. Capacity C: the maximum throughput that a certain path can provide, > in the absence of any competing traffic, and independent of the > transport protocol or specific application that we use. > People also refer to this as "raw bandwidth", or "bottleneck > bandwidth" of the path. This is an important metric mainly > for network management, debugging, and monitoring. While > experimenting with pathrate, I found in interesting that network > managers do not know often the capacity of their links. > Just because you lease a 40Mbps share of a link, it does > not mean that the provider will actually give you 40Mbps at all > times.. from past work with pathchar I seem to remember that the tool tends to generates quiet a bit of traffic. Are there tools that do not utilize the pipe (or keep utilization to minimal) in order to estimate path b/w? > 2. Available bandwidth A: this is certainly not a consistently > defined metric in both the research literature and in practice. > IMHO it should mean: the minimum throughput that is not used > by existing traffic, across all links of the path. Intuitively, > in the case of one link, this is just the "blank space" in an MRTG > graph, between the bandwidth that is currently used and what > is the capacity of the link. In a multi-hop path, we need > to know the minimum such "blank space" across all links of > the path. > > Again, A does not depend on a specific transport protocol. > Also, it is not true that a single flow would be able to > achieve A (at least without feedback from the network). > Depending on how "congestion responsive" the flow is, it may > get less than A, or more than A. > From this point of view, A may be a more important metric for > network monitoring and QoS provisioning, rather than for individual > users and applications. IMOHO this is an important parameter however it is very time dependent and a function of time should be represented in the definition. > 3. Bulk-Transfer Capacity BTC: this is the throughput that a > long TCP connection connection would get from the path, > if it was only limited by the network (i.e., not limited > by the advertised window or the amount of data to be sent), and > if TCP is implemented as in RFC2581. In some sense, this is > a more pragmatic metric, as it is easier to measure, and > it is directly related with what most users (at least, TCP > users that create "elephant" flows) would care about. I'd like to propose that the BTC parameter might be somewhat arcane enough at this point to elicit some thoughts about a new parameter that is somewhat reflective of today's traffic patterns. from recent discussions (e2e and ippm I believe) and papers on Internet traffic mix (kc and shawn mccreary) it seems that throughput behavior of short tcp connections (i.e. http traffic) is something that this group should be considering. IMOHO the above mentioned second point can address such interest as long as we keep in mind "Web time" (rtt/short attention span). Any ideas on this? > I believe that there are important applications for all these > three types of metrics. So far the focus of the IPPM group > was on the BTC metric. Would there be any interest to consider > the metrics C and A as well? Or any other metrics? i echo this sentiment and hope that the answer is yes. Jambi vBNS+ Engineering. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 14 06:00:42 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24179 for ; Thu, 14 Jun 2001 06:00:42 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5EA03e23514; Thu, 14 Jun 2001 06:00:03 -0400 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5E9x9e23367 for ; Thu, 14 Jun 2001 05:59:10 -0400 Received: from [193.203.132.2] (helo=surfnet.nl) by survis.surfnet.nl with ESMTP (exPP) id 15ATu5-0000Sv-00; Thu, 14 Jun 2001 11:59:06 +0200 Message-ID: <3B288AE7.FF0A1ADE@surfnet.nl> Date: Thu, 14 Jun 2001 10:59:03 +0100 From: Victor Reijs Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en-gb] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Constantinos Dovrolis CC: Mark Santcroos , ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating References: Content-Type: multipart/mixed; boundary="------------5DDC4A22372F41AB44B78BC3" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. --------------5DDC4A22372F41AB44B78BC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Constantinos, In my work to try define a end-user QOS metric, I find that the parameter A is an important one. See also: http://www.heanet.ie/Heanet/projects/nat_infrastruct/nettools.html There are a lot of tools for the C measurement, but they are not very interesting for an end users (it is only a theoretical capacity, which is never gainable for one user). This tool is of course interesting for network engineers. And BTC is of course handy for the TCP users. But how will that change in the future, with all these UDP based applications? But anyhow BTC is defined and tools exists, so that is great. We are trying to stimulate the making a tool A. In that way an end-user is perhaps able to determine before hand if his/her application can run over the network. I would wish that tool A is independent of protocol, but I wonder if that is possible? UDP can 'make' bandwidth, while FTP has the feedback (but there the tool for determine available ftp bandwidth is available: BTC). Perhaps we should redefine tool A to something like: 'A tool that measures the bandwidth available to an UDP stream without this stream influencing the existing traffic. The tool must be able to measure also short term changes' The term 'without' is of course something statistically! 'Short term' is another difficult temr: A tool like pathchar can take up to 15 minutes and 15 minutes is a very long time in IP world;-) So to end this e-mail, I am very interested in such a tool and its standard! All the best, Victor Constantinos Dovrolis wrote: > > I would also be interested to see some IPPM work in the > direction of bandwidth estimation. A critical point though is > to precisely define what we mean by "bandwidth estimation". I can > see at least 3 different metrics (or types of metrics): > .... > 2. Available bandwidth A: this is certainly not a consistently > defined metric in both the research literature and in practice. > IMHO it should mean: the minimum throughput that is not used > by existing traffic, across all links of the path. Intuitively, > in the case of one link, this is just the "blank space" in an MRTG > graph, between the bandwidth that is currently used and what > is the capacity of the link. In a multi-hop path, we need > to know the minimum such "blank space" across all links of > the path. > > Again, A does not depend on a specific transport protocol. > Also, it is not true that a single flow would be able to > achieve A (at least without feedback from the network). > Depending on how "congestion responsive" the flow is, it may > get less than A, or more than A. > From this point of view, A may be a more important metric for > network monitoring and QoS provisioning, rather than for individual > users and applications. > --------------5DDC4A22372F41AB44B78BC3 Content-Type: text/x-vcard; charset=us-ascii; name="victor.reijs.vcf" Content-Description: Card for Victor Reijs Content-Disposition: attachment; filename="victor.reijs.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Reijs;Victor tel;fax:+ 353 1 8105121 tel;work:+ 31 30 2305305 x-mozilla-html:FALSE url:http://www.surfnet.nl/ org:SURFnet bv;Networkmanagement adr:;;;Utrecht;;;The Netherlands version:2.1 email;internet:Victor.Reijs@SURFnet.nl title:Network Engineer fn:Victor Reijs end:vcard --------------5DDC4A22372F41AB44B78BC3-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 14 09:38:42 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28873 for ; Thu, 14 Jun 2001 09:38:41 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5EDc2e13973; Thu, 14 Jun 2001 09:38:02 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f5EDbCe13854 for ; Thu, 14 Jun 2001 09:37:15 -0400 X-Authentication-Warning: mailhost.advanced.org: Host louie.udel.edu [128.175.2.33] claimed to be mail.eecis.udel.edu Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa15241; 14 Jun 2001 09:36 EDT Date: Thu, 14 Jun 2001 09:36:09 -0400 (EDT) From: Constantinos Dovrolis To: Jambi Ganbar cc: ippm@advanced.org, bwest@caida.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hey Jambi! > > from past work with pathchar I seem to remember that the tool tends to > generates quiet a bit of traffic. Are there tools that do not utilize the > pipe (or keep utilization to minimal) in order to estimate path b/w? The capacity estimation tools that I know of are the following. Plz let me know if there are more out there. 1. pathchar (Van Jacobson, ftp://ftp.ee.lbl.gov/pathchar/) 2. clink (Allen Downey, http://rocky.wellesley.edu/downey/clink/) 3. pchar (Bruce Mah, version 1.4 was just released yesterday, see http://www.employees.org/~bmah/Software/pchar/) 4. pipechar (Jin Guojun, http://www-didc.lbl.gov/pipechar/) 5. nettimer (Kevin Lai, http://mosquitonet.stanford.edu/~laik/projects/nettimer/) 6. bprobe (Bob Carter, http://cs-people.bu.edu/carter/tools/Tools.html) 7. pathrate (myself, version 2.0 will be available by the end of June at http://www.cis.udel.edu/~dovrolis/bwmeter.html) Even though there are several tools available, they are all different in several aspects. I usually think of bandwidth estimation tools based on the following questions (in random order): a) Does this tool attempt to measure capacity, available bandwidth, BTC, something else? b) Does it use information from the routers (i.e., SNMP-based tools like MRTG), or is it based on end-point measurements? c) Does it measure a bandwidth estimate (capacity or available bandwidth) for *each link* in the path, or at an *end-to-end* basis? d) Does it require access at both ends of the path? If not, does it run from the sender or the receiver? Can the reverse path affect the measurements? e) Is it based on the dispersion of packet pairs/trains (e.g., bprobe, pathrate), on the one-way delay variations of variable-sized probing packets (e.g., pathchar, clink, pchar, nettimer, pipechar), on actual TCP transfers (e.g., BTC measurements with cap, ttcp, iperf), or on emulated TCP flows (TReno)? f) Does it require ICMP replies from the path routers? g) Does it attempt to saturate the path over the duration of the measurements? h) Is it portable to different platforms? i) Does it take user-level or kernel-level timestamps? Timestamping accuracy and resolution are MAJOR issues in measuring high-bw paths. Resolution is not a problem these days (1-2usec is typical). Accuracy, though, can be a major problem in both kernel and user-level timestamps (more in the later), and especially when the measuring host is not totally idle. j) In the case of a capacity-measuring tools, is it robust to cross traffic? In other words, can it make accurate measurements even when the path is heavily loaded? k) Are the measurements affected by "hidden" L2 switches and other store-and-forward devices? l) Can it measure the aggregate capacity of parallel-links? m) Does it require access at the raw-IP socket (i.e., need special user privileges)? n) Probably the most important issue: Is it accurate? Obviously, all these tools are based on statistical methodologies. This means that there is no guarantee that they will give you the right value everytime you run them. The possibility of error is always there in every area of measurements and experimentation. However, do they give the right estimate "most of the time"? Ok, I almost run out of letters here.. Any other important issues that we should consider in such a classification? Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 14 10:02:20 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29720 for ; Thu, 14 Jun 2001 10:02:19 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5EE23e25235; Thu, 14 Jun 2001 10:02:03 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f5EE1je25128 for ; Thu, 14 Jun 2001 10:01:46 -0400 X-Authentication-Warning: mailhost.advanced.org: Host louie.udel.edu [128.175.2.33] claimed to be mail.eecis.udel.edu Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa17718; 14 Jun 2001 10:01 EDT Date: Thu, 14 Jun 2001 10:01:20 -0400 (EDT) From: Constantinos Dovrolis To: Mark Santcroos cc: ippm@advanced.org, bwest@caida.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: <20010613082616.M36480@laptop.6bone.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Mark, as Henk pointed out A and C are generally very different. If you are interested in something that is "usage independent", you probably refer to a capacity metric. What do you mean "link type independent"? Cheers Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ On Wed, 13 Jun 2001, Mark Santcroos wrote: > Hi Constantinos, > > Actually how different in practice are metric A and C? > I can see the difference in the definition, but in practice it would be > very hard to make a difference between those two probably. (And it may be > a requirement that these are handled the same way) > Please explain me though if you think we should really separate those two. > > For now, my requirements for the metric would be: > > * transport protocol independent > * path/link usage independent > * minimal network traffic created by the measurements > * link type independent (if at all possible) > > I think these match pretty well with your definitions. > > I'm looking forward to your reply. > > Mark > > > On Tue, Jun 12, 2001 at 06:17:16PM -0400, Constantinos Dovrolis wrote: > > > > I would also be interested to see some IPPM work in the > > direction of bandwidth estimation. A critical point though is > > to precisely define what we mean by "bandwidth estimation". I can > > see at least 3 different metrics (or types of metrics): > > > > 1. Capacity C: the maximum throughput that a certain path can provide, > > in the absence of any competing traffic, and independent of the > > transport protocol or specific application that we use. > > People also refer to this as "raw bandwidth", or "bottleneck > > bandwidth" of the path. This is an important metric mainly > > for network management, debugging, and monitoring. While > > experimenting with pathrate, I found in interesting that network > > managers do not know often the capacity of their links. > > Just because you lease a 40Mbps share of a link, it does > > not mean that the provider will actually give you 40Mbps at all > > times.. > > > > 2. Available bandwidth A: this is certainly not a consistently > > defined metric in both the research literature and in practice. > > IMHO it should mean: the minimum throughput that is not used > > by existing traffic, across all links of the path. Intuitively, > > in the case of one link, this is just the "blank space" in an MRTG > > graph, between the bandwidth that is currently used and what > > is the capacity of the link. In a multi-hop path, we need > > to know the minimum such "blank space" across all links of > > the path. > > > > Again, A does not depend on a specific transport protocol. > > Also, it is not true that a single flow would be able to > > achieve A (at least without feedback from the network). > > Depending on how "congestion responsive" the flow is, it may > > get less than A, or more than A. > > From this point of view, A may be a more important metric for > > network monitoring and QoS provisioning, rather than for individual > > users and applications. > > > > 3. Bulk-Transfer Capacity BTC: this is the throughput that a > > long TCP connection connection would get from the path, > > if it was only limited by the network (i.e., not limited > > by the advertised window or the amount of data to be sent), and > > if TCP is implemented as in RFC2581. In some sense, this is > > a more pragmatic metric, as it is easier to measure, and > > it is directly related with what most users (at least, TCP > > users that create "elephant" flows) would care about. > > > > Note that each of these metrics is limited by a different part > > of the path. The capacity C would be limited by the link > > with the lowest capacity (what we call "narrow" link). The > > available bandwidth A would be limited by the link with the > > minimum unused throughput (what we call "tight" link). The > > BTC would probably depend on all the links of the path, since > > the throughput of a long TCP connection depends on the end-to-end > > loss rate and round-trip time (including queueing delays) that > > the connection encounters. > > > > I believe that there are important applications for all these > > three types of metrics. So far the focus of the IPPM group > > was on the BTC metric. Would there be any interest to consider > > the metrics C and A as well? Or any other metrics? > > > > > > Constantinos > > > > Computer and Information Sciences - University of Delaware > > > > http://www.cis.udel.edu/~dovrolis/ > > > > On Tue, 12 Jun 2001, Mark Santcroos wrote: > > > > > Hi, > > > > > > I am looking into calculating/estimating bandwidth on the Internet. > > > > > > I know about the BTC framework and the corresponding metric, but that is > > > not what we are looking for in our project (www.ripe.net/test-traffic/). > > > The reason for that is that we don't want to regularly fill the line > > > while doing our measurements. > > > > > > Better would be something like 'pathchar', described and implemented by > > > Van Jacobson. (And since then some other implementations) > > > > > > I'm curious if any effort has been made into standardizing this work. > > > > > > Also I am wondering if the IPPM would be the right place to discuss this. > > > Following to that, is the nature of the measurements, based on estimation, > > > suited for being discussed here and possibly become a standard? > > > > > > Thanks in advance, > > > > > > Mark > > > > > > > > > -- > > > Mark Santcroos RIPE Network Coordination Centre > > > http://www.ripe.net/home/mark/ New Projects Group/TTM > > > _______________________________________________ > > > ippm mailing list > > > ippm@advanced.org > > > http://mailhost.advanced.org/mailman/listinfo/ippm > > > > > > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > > -- > Mark Santcroos RIPE Network Coordination Centre > http://www.ripe.net/home/mark/ New Projects Group/TTM > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 14 10:14:17 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00169 for ; Thu, 14 Jun 2001 10:14:16 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5EEE3e31213; Thu, 14 Jun 2001 10:14:03 -0400 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5EEDMe31182 for ; Thu, 14 Jun 2001 10:13:23 -0400 Received: from [193.203.132.2] (helo=surfnet.nl) by survis.surfnet.nl with ESMTP (exPP) id 15AXs7-0006UT-00; Thu, 14 Jun 2001 16:13:19 +0200 Message-ID: <3B28C67E.72530B4A@surfnet.nl> Date: Thu, 14 Jun 2001 15:13:18 +0100 From: Victor Reijs Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en-gb] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Constantinos Dovrolis CC: Jambi Ganbar , ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating References: Content-Type: multipart/mixed; boundary="------------C03E7D88EC9FA7CF32E83169" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. --------------C03E7D88EC9FA7CF32E83169 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all of you, Constantinos Dovrolis wrote: > > Hey Jambi! > > > > > from past work with pathchar I seem to remember that the tool tends to > > generates quiet a bit of traffic. Are there tools that do not utilize the > > pipe (or keep utilization to minimal) in order to estimate path b/w? > > The capacity estimation tools that I know of are the following. Plz > let me know if there are more out there. > 6. bprobe (Bob Carter, > http://cs-people.bu.edu/carter/tools/Tools.html) cprobe (I think of the same author). Could measure bandwidth A. http://cs-people.bu.edu/carter/Papers.html > 7. pathrate (myself, version 2.0 will be available by the end of June > at http://www.cis.udel.edu/~dovrolis/bwmeter.html) 8. Reading MIB's (as you point out later in b). > d) Does it require access at both ends of the path? If not, does it run > from the sender or the receiver? Can the reverse path affect the > measurements? > Related to this one, but could open the idea of a 'testing protocol': Can it handle downloads of script to perform different test dynamically? Anoteh related one: Can one start up the test remotely on one of the end-points (and not being logon in an endpoint)? Pehaps using SSL? > > n) Probably the most important issue: Is it accurate? Obviously, all > these tools are based on statistical methodologies. This means that > there is no guarantee that they will give you the right value everytime > you run them. The possibility of error is always there in every > area of measurements and experimentation. However, do they give the > right estimate "most of the time"? Perhaps I would rephrase it a little bit: Is it accurate enough? Every application of such a tool could need a different level of accuracy and perhaps a simpler tool coudl be used for certain tasks. > > Ok, I almost run out of letters here.. Any other important issues that > we should consider in such a classification? VERY GOOD Overview!!!! All the best, Victor --------------C03E7D88EC9FA7CF32E83169 Content-Type: text/x-vcard; charset=us-ascii; name="victor.reijs.vcf" Content-Description: Card for Victor Reijs Content-Disposition: attachment; filename="victor.reijs.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Reijs;Victor tel;fax:+ 353 1 8105121 tel;work:+ 31 30 2305305 x-mozilla-html:FALSE url:http://www.surfnet.nl/ org:SURFnet bv;Networkmanagement adr:;;;Utrecht;;;The Netherlands version:2.1 email;internet:Victor.Reijs@SURFnet.nl title:Network Engineer fn:Victor Reijs end:vcard --------------C03E7D88EC9FA7CF32E83169-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 14 10:15:58 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00222 for ; Thu, 14 Jun 2001 10:15:58 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5EEG3e31981; Thu, 14 Jun 2001 10:16:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5EEFre31956 for ; Thu, 14 Jun 2001 10:15:53 -0400 Received: from laptop.6bone.nl (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with SMTP id QAA01731; Thu, 14 Jun 2001 16:15:30 +0200 (CEST) Received: (nullmailer pid 71369 invoked by uid 1000); Thu, 14 Jun 2001 14:15:30 -0000 Date: Thu, 14 Jun 2001 16:15:30 +0200 From: Mark Santcroos To: Constantinos Dovrolis Cc: ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010614161530.H36480@laptop.6bone.nl> References: <20010613082616.M36480@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dovrolis@mail.eecis.udel.edu on Thu, Jun 14, 2001 at 10:01:20AM -0400 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Constantinos, On Thu, Jun 14, 2001 at 10:01:20AM -0400, Constantinos Dovrolis wrote: > Mark, as Henk pointed out A and C are generally very different. > If you are interested in something that is "usage independent", > you probably refer to a capacity metric. What do you mean > "link type independent"? I agree that they are not the same ;) I was unclear/incorrect in my explanation. I think I was indeed referring to something you call a 'capacity metric'. However, it is not yet clear to me what I want to establish exactly; Probably we just want to find out both. I first saw them as one, but it is clear to me know that they are two totally different things. To answer your last question: it would be nice to come up with a method that is independent of underlying layers on the network. So try to stay free of L2 tricks as much as possible. I have no idea how realistic this wish is though. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 14 19:41:50 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11471 for ; Thu, 14 Jun 2001 19:41:50 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5ENe4e15004; Thu, 14 Jun 2001 19:40:04 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f5ENdAe14398 for ; Thu, 14 Jun 2001 19:39:11 -0400 X-Authentication-Warning: mailhost.advanced.org: Host louie.udel.edu [128.175.2.33] claimed to be mail.eecis.udel.edu Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa16295; 14 Jun 2001 19:38 EDT Date: Thu, 14 Jun 2001 19:38:13 -0400 (EDT) From: Constantinos Dovrolis To: Victor Reijs cc: Jambi Ganbar , ippm@advanced.org, bwest@caida.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: <3B28C67E.72530B4A@surfnet.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List > > > 6. bprobe (Bob Carter, > > http://cs-people.bu.edu/carter/tools/Tools.html) > > cprobe (I think of the same author). Could measure bandwidth A. > http://cs-people.bu.edu/carter/Papers.html > Victor, What cprobe measures is an interesting issue. cprobe sends several, say N, back-to-back packets (a "packet train") from the source of the path to the sink. Based on the overall "dispersion" of the train at the receiver, say Delta, it computes a bandwidth estimate: b = (N-1) L / Delta where L is the size of each packet in the train. In the case of cprobe, N is 8 packets I think. In a recent work that we did with the Caida folks, (published at last Infocom, see http://www.cis.udel.edu/~dovrolis/Papers/infocom01.ps) we showed that the dispersion of long packet trains is *not* related with the available bandwidth in the path. The bandwidth estimates, instead, become centered around a certain value that we call "Asymptotic Dispersion Rate" (ADR). The ADR is a function of the capacities and loads of all the links in the path (in the general case). In the case of a single-link path, we can compute the available bandwidth A from the measured ADR, but that is a very limited case of course. To make the long story short, I don't know of any end-to-end tool at this point that can measure the available bandwidth in a path. Cheers Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 15 01:26:58 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17861 for ; Fri, 15 Jun 2001 01:26:58 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5F5Q3e20389; Fri, 15 Jun 2001 01:26:03 -0400 Received: from mainserver.surfnetusa.com (mail.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5F5Pwe20292; Fri, 15 Jun 2001 01:25:59 -0400 X-Authentication-Warning: mailhost.advanced.org: Host mail.surfnetusa.com [208.201.152.2] claimed to be mainserver.surfnetusa.com Received: from MKAEO (MKAEO [63.67.14.34]) by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id ptgelbaa for ippm@advanced.org; Thu, 14 Jun 2001 22:34:10 -0700 Message-Id: <5.1.0.14.2.20010614222154.00a93d20@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Jun 2001 22:25:39 -0700 To: Mark Santcroos , Gamze Seckin From: Merike Kaeo Subject: Re: [ippm] bandwidth measuring/estimating Cc: ippm@advanced.org, matt@advanced.org In-Reply-To: <20010612223225.L36480@laptop.6bone.nl> References: <038a01c0f37e$373198c0$d600a8c0@luxxon.com> <200106121837.OAA12907@guns.lerc.nasa.gov> <20010612212743.G36480@laptop.6bone.nl> <038a01c0f37e$373198c0$d600a8c0@luxxon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List >To IPPM: > >what would be the process of trying to establish a standard? >Would it be wise, as with BTC, to come up with a framework first? >Please enlighten me on this. As long as there is a sufficient explanation as to why the work is useful it is not necessarily required to come up with a framework first. An individual submission of a draft would be a good start and if there is a working group consensus that the work is useful and fits into the IPPM charter, it can progress from there. - merike _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 15 18:38:12 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01026 for ; Fri, 15 Jun 2001 18:38:12 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5FMa2e22211; Fri, 15 Jun 2001 18:36:02 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5FMZTe22104; Fri, 15 Jun 2001 18:35:30 -0400 Received: from laptop.6bone.nl (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with SMTP id AAA16163; Sat, 16 Jun 2001 00:35:23 +0200 (CEST) Received: (nullmailer pid 83074 invoked by uid 1000); Fri, 15 Jun 2001 22:35:23 -0000 Date: Sat, 16 Jun 2001 00:35:23 +0200 From: Mark Santcroos To: Merike Kaeo Cc: ippm@advanced.org, matt@advanced.org Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010616003522.T36480@laptop.6bone.nl> References: <038a01c0f37e$373198c0$d600a8c0@luxxon.com> <200106121837.OAA12907@guns.lerc.nasa.gov> <20010612212743.G36480@laptop.6bone.nl> <038a01c0f37e$373198c0$d600a8c0@luxxon.com> <20010612223225.L36480@laptop.6bone.nl> <5.1.0.14.2.20010614222154.00a93d20@mail.merike.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20010614222154.00a93d20@mail.merike.com>; from kaeo@merike.com on Thu, Jun 14, 2001 at 10:25:39PM -0700 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Merike, Just want to let you know that I started writing a proposal. I think it will be good to just start with it and receive input (and go further) from there. I will collect all the info send about this subject on the list from last days and will try to define a scope with that. Cheers, Mark On Thu, Jun 14, 2001 at 10:25:39PM -0700, Merike Kaeo wrote: > > >To IPPM: > > > >what would be the process of trying to establish a standard? > >Would it be wise, as with BTC, to come up with a framework first? > >Please enlighten me on this. > > As long as there is a sufficient explanation as to why the work is useful > it is not necessarily required to come up with a framework first. An > individual submission of a draft would be a good start and if there is a > working group consensus that the work is useful and fits into the IPPM > charter, it can progress from there. > > - merike > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat Jun 16 03:39:09 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22126 for ; Sat, 16 Jun 2001 03:39:09 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5G7a2e12002; Sat, 16 Jun 2001 03:36:02 -0400 Received: from caida.org (ipn.caida.org [192.172.226.30]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5G7Zce11987 for ; Sat, 16 Jun 2001 03:35:38 -0400 X-Authentication-Warning: mailhost.advanced.org: Host ipn.caida.org [192.172.226.30] claimed to be caida.org Received: (from kc@localhost) by caida.org (8.9.3+Sun/8.9.1) id AAA27908; Sat, 16 Jun 2001 00:35:29 -0700 (PDT) Date: Sat, 16 Jun 2001 00:35:29 -0700 From: k claffy To: Constantinos Dovrolis Cc: Jambi Ganbar , ippm@advanced.org, bwest@caida.org, kevin Subject: Re: [ippm] bandwidth measuring/estimating Message-ID: <20010616003529.A27694@caida.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from dovrolis@mail.eecis.udel.edu on Thu, Jun 14, 2001 at 09:36:09AM -0400 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Thu, Jun 14, 2001 at 09:36:09AM -0400, Constantinos Dovrolis wrote: Hey Jambi! > > from past work with pathchar I seem to remember that the tool tends to > generates quiet a bit of traffic. Are there tools that do not utilize the > pipe (or keep utilization to minimal) in order to estimate path b/w? The capacity estimation tools that I know of are the following. Plz let me know if there are more out there. not only that, but which ones actual ISPs want us to pursue use of; the more ISPs on board w us (in terms of providing calibrating link.bandwidths) k 1. pathchar (Van Jacobson, ftp://ftp.ee.lbl.gov/pathchar/) 2. clink (Allen Downey, http://rocky.wellesley.edu/downey/clink/) 3. pchar (Bruce Mah, version 1.4 was just released yesterday, see http://www.employees.org/~bmah/Software/pchar/) 4. pipechar (Jin Guojun, http://www-didc.lbl.gov/pipechar/) 5. nettimer (Kevin Lai, http://mosquitonet.stanford.edu/~laik/projects/nettimer/) 6. bprobe (Bob Carter, http://cs-people.bu.edu/carter/tools/Tools.html) 7. pathrate (myself, version 2.0 will be available by the end of June at http://www.cis.udel.edu/~dovrolis/bwmeter.html) Even though there are several tools available, they are all different in several aspects. I usually think of bandwidth estimation tools based on the following questions (in random order): a) Does this tool attempt to measure capacity, available bandwidth, BTC, something else? b) Does it use information from the routers (i.e., SNMP-based tools like MRTG), or is it based on end-point measurements? c) Does it measure a bandwidth estimate (capacity or available bandwidth) for *each link* in the path, or at an *end-to-end* basis? d) Does it require access at both ends of the path? If not, does it run from the sender or the receiver? Can the reverse path affect the measurements? e) Is it based on the dispersion of packet pairs/trains (e.g., bprobe, pathrate), on the one-way delay variations of variable-sized probing packets (e.g., pathchar, clink, pchar, nettimer, pipechar), on actual TCP transfers (e.g., BTC measurements with cap, ttcp, iperf), or on emulated TCP flows (TReno)? f) Does it require ICMP replies from the path routers? g) Does it attempt to saturate the path over the duration of the measurements? h) Is it portable to different platforms? i) Does it take user-level or kernel-level timestamps? Timestamping accuracy and resolution are MAJOR issues in measuring high-bw paths. Resolution is not a problem these days (1-2usec is typical). Accuracy, though, can be a major problem in both kernel and user-level timestamps (more in the later), and especially when the measuring host is not totally idle. j) In the case of a capacity-measuring tools, is it robust to cross traffic? In other words, can it make accurate measurements even when the path is heavily loaded? k) Are the measurements affected by "hidden" L2 switches and other store-and-forward devices? l) Can it measure the aggregate capacity of parallel-links? m) Does it require access at the raw-IP socket (i.e., need special user privileges)? n) Probably the most important issue: Is it accurate? Obviously, all these tools are based on statistical methodologies. This means that there is no guarantee that they will give you the right value everytime you run them. The possibility of error is always there in every area of measurements and experimentation. However, do they give the right estimate "most of the time"? Ok, I almost run out of letters here.. Any other important issues that we should consider in such a classification? Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jun 18 10:28:21 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08768 for ; Mon, 18 Jun 2001 10:28:20 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5IER3e24913; Mon, 18 Jun 2001 10:27:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5IEQNe24888 for ; Mon, 18 Jun 2001 10:26:23 -0400 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 QAA21712; Mon, 18 Jun 2001 16:26:17 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id QAA09360; Mon, 18 Jun 2001 16:26:17 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 18 Jun 2001 16:26:17 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Constantinos Dovrolis cc: Jambi Ganbar , ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Constantinos, Great list, I think that trying to answer them for all tools is going to be very helpful. A few small additions. > g) Does it attempt to saturate the path over the duration of the > measurements? I think we have to quantify this, for operational use, a tool that saturates a link for a short time, is fine, a tool that saturates it for hours isn't. And for the tools that don't saturate, it could still be useful to have an idea about the data volume to be sent out. > h) Is it portable to different platforms? I guess you mean: "on which platforms does it run?" > n) Probably the most important issue: Is it accurate? Obviously, all > these tools are based on statistical methodologies. This means that > there is no guarantee that they will give you the right value everytime > you run them. The possibility of error is always there in every > area of measurements and experimentation. However, do they give the > right estimate "most of the time"? n1) Does it calculate (correct) experimental errors? o) Is the tool actively maintained/developped? ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jun 18 10:33:58 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08893 for ; Mon, 18 Jun 2001 10:33:57 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5IEY3e27608; Mon, 18 Jun 2001 10:34:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5IEXde27488; Mon, 18 Jun 2001 10:33:42 -0400 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 QAA23401; Mon, 18 Jun 2001 16:33:37 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id QAA09402; Mon, 18 Jun 2001 16:33:37 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 18 Jun 2001 16:33:37 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Matthew J Zekauskas cc: ippm@advanced.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] IPPM Archive Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Matt, It appears that the IPPM archive (http://www.advanced.org/IPPM/archive/date.html) ends on April 5. Would it be possible to include later postings to the list? Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jun 18 12:27:14 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11952 for ; Mon, 18 Jun 2001 12:27:13 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5IGR3e01457; Mon, 18 Jun 2001 12:27:03 -0400 Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5IGQPe01213 for ; Mon, 18 Jun 2001 12:26:30 -0400 X-Authentication-Warning: mailhost.advanced.org: Host mx.sprintlabs.com [208.30.174.2] claimed to be mailman.sprintlabs.com Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id ; Mon, 18 Jun 2001 09:26:19 -0700 Received: from sprintlabs.com (ip199-2-53-101.sprintlabs.com [199.2.53.101]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id KT1D9WCD; Mon, 18 Jun 2001 09:26:16 -0700 From: Christophe Diot Reply-To: Christophe Diot To: ippm@advanced.org, end2end-interest@postel.org, rtfm@auckland.ac.nz Cc: tccc@ieee.org Message-ID: <3B2E2B98.C04BA69D@sprintlabs.com> Date: Mon, 18 Jun 2001 09:26:00 -0700 Organization: Sprint ATL X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] Sigcomm Measurement workshop - dealine reminder Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The call for paper and the submission instructions for the first ACM Sigcomm Internet Measurement Workshop are available at: http://www.aciri.org/vern/sigcomm-imeas-2001.cfp.html The DEADLINE is scheduled on Friday June 29 @ 11pm EDT (US Eastern time = GMT - 5) There will be NO EXTENSION granted. PS: we tried to minimize duplicates ! _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Jun 18 18:51:33 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23087 for ; Mon, 18 Jun 2001 18:51:33 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5IMp2e08227; Mon, 18 Jun 2001 18:51:02 -0400 Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5IMoTe08206 for ; Mon, 18 Jun 2001 18:50:34 -0400 Received: from tot-wa.proxy.aol.com (tot-wa.proxy.aol.com [205.188.192.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id SAA07768; Mon, 18 Jun 2001 18:46:13 -0400 (EDT) Received: from icwlhn.org (AC8F0782.ipt.aol.com [172.143.7.130]) by tot-wa.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f5IMkAi00496; Mon, 18 Jun 2001 18:46:11 -0400 (EDT) Message-ID: <3B2EAE5D.1A21F2F9@icwlhn.org> Date: Mon, 18 Jun 2001 18:43:57 -0700 From: Benny Bing X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {MCIWORLDV2} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org, rtfm@auckland.ac.nz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: BBing10199@aol.com Subject: [ippm] Final CFP: International Conference on Wireless LANs and Home Networks Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit FINAL CALL FOR PAPERS International Conference on Wireless LANs, PANs and Home Networks 5 - 7 December 2001, Singapore Conference Web Site: www.icwlhn.org Conference Outline The IEEE ICWLHN 2001 is the first conference to integrate technical presentations with live demos, allowing participants to see technologies in action. It is this uniqueness that separates ICWLHN from the rest of other conferences rather than compares ICWLHN to them. The conference will focus on practical application of current technologies with an eye towards the immediate future as well as innovative research. The purpose is to bring together engineers, practitioners, scientists, as well as industry professionals from manufacturers to service providers whose technical interests are wireless LANs (e.g., IEEE 802.11, HiperLAN, Wi-Fi) and personal area/home wireless networks (IEEE 802.15, Bluetooth, HomeRF, WAP). In doing so, technical ideas can be exchanged, potentially leading to the development of new innovations. Conference Highlights Keynote Speech: "Nomadic Computing - The Next Wave of the Internet", Dr. Leonard Kleinrock, UCLA and Nomadix Inc Technology Presentors and Sponsors: Ericsson, Agilent, Mobilian, 3Com, Wi-LAN, EDS, Sharewave, Dell, Metricom, Cisco, Agere, Intermec. Paper Topics Suggestions for paper topics include the following: - Channel Modeling - Modulation - Signal Propagation - Channel Measurements - Multicarrier (OFDM) Systems - Smart Antennas - Emerging Technologies - Network Performance Analysis - Smart Spaces - Error Control Coding - Optical Wireless Networks - Standards Coexistence - Interference Control - Power Control and Management - Synchronization - Internetworking - QoS Provisioning - System Integration - Media Access - Receiver Implementation - Wireless Ethernet - Mobility Management - RF/IC Technology - Wireless Internet - Mobile Computing - Security - Wireless Local Loop Best Papers Authors of best papers will invited to submit full-length papers for possible publication in a special issue of the IEEE Personal Communications, a premier magazine of the IEEE Communications Society. The issue is scheduled to appear in June 2002. Submission Instructions Authors should submit an electronic version of a 2000-word abstract to bennybing@icwlhn.org. Preferred file formats include Microsoft Word and Acrobat PDF. The submission should include the name, affiliation, mailing address, email address, telephone and fax numbers of the corresponding author. The submission should be compressed if the file size is larger than 1 Mbyte. In view of an anticipated large number of submissions, it is important that authors keep to the 2000-word limit and discuss key points of their abstracts as concisely as possible. Important Deadlines 2000-Word Abstract Due: 22 June 2001. Notification of Acceptance: 15 August 2001. Camera-Ready Paper Due: 1 September 2001. Author Registration Due: 1 September 2001. International Advisory Committee: Lek Ariyavisitakul, Home Wireless Networks, USA. Ben Arzine, British Telecom, UK. Ender Ayanoglu, Cisco Systems, USA. Victor Bahl, Microsoft Research, USA. Yeheskel Bar-Ness, New Jersey Institute of Technology, USA. John Barr, Motorola, USA. Steve Bell, Agilent Interoperability Certification Labs, USA. Kwang-Cheng Chen, National Taiwan University, Taiwan. Justin Chuang, AT&T Research, USA. David Cohen, 3Com, USA. Greg Ennis, Symbol Technologies, USA. David Everitt, Swinburne University of Technology, Australia. Laurent Frelechoux, IBM Research, Switzerland. Alex Gelman, Panasonic Research, USA. Nada Golmie, National Institute of Standards and Technology, USA Lon Gowen, Mitre Corporation, USA. Bob Heile, Consultant, USA. Chih-Lin I, AT&T Research, USA. Konosuke Kawashima, NTT Advanced Technology, Japan. Leonard Kleinrock, University of California at Los Angeles, USA. Victor Li, University of Hong Kong, China. Pascal Lorenz, University of Haute Alsace, France. Teresa Meng, Stanford University, USA. Jouni Mikkonen, Nokia, Finland. Hiroyuki Morikawa, University of Tokyo, Japan. Guy Pujolle, University of Paris, France. Mike Sheppard, Ericsson, USA. Matthew Shoemake, Texas Instruments, USA. Tom Siep, Texas Instruments, USA. Roj Snellman, Intersil, USA. Peter Steenkiste, Carnegie Mellon University, USA. Richard van Nee, Lucent Technologies, The Netherlands. Sergio Verdu, Princeton University, USA. Naoaki Yamanaka, NTT Network Service Systems, Japan. Hatim Zaghoul, Wi-LAN, Canada. Rodger Ziemer, National Science Foundation, USA. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 20 08:40:53 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04824 for ; Wed, 20 Jun 2001 08:40:53 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5KCe3e28904; Wed, 20 Jun 2001 08:40:03 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f5KCdee28880 for ; Wed, 20 Jun 2001 08:39:40 -0400 X-Authentication-Warning: mailhost.advanced.org: Host louie.udel.edu [128.175.2.33] claimed to be mail.eecis.udel.edu Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa20213; 20 Jun 2001 08:39 EDT Date: Wed, 20 Jun 2001 08:39:31 -0400 (EDT) From: Constantinos Dovrolis To: "Henk Uijterwaal (RIPE-NCC)" cc: Jambi Ganbar , ippm@advanced.org, bwest@caida.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Henk, > > > g) Does it attempt to saturate the path over the duration of the > > measurements? > > I think we have to quantify this, for operational use, a tool that > saturates a link for a short time, is fine, a tool that saturates it for > hours isn't. > It would be useful to hear more from operations people about what timescales are acceptable for saturating a path. A train of 20 back-to-back 1500-byte packets saturates a fast ethernet for about 2.5msec. Obviously not many people would care. On the other hand, a tool that attempts to saturate the path for several minutes with TCP traffic, or even worse with a UDP flow, would cause noticeable effects on the rest of the traffic. What about the large grey zone between a few msec and several minutes? > > I guess you mean: "on which platforms does it run?" Correct. > > > n) Probably the most important issue: Is it accurate? Obviously, all > > these tools are based on statistical methodologies. This means that > > there is no guarantee that they will give you the right value everytime > > you run them. The possibility of error is always there in every > > area of measurements and experimentation. However, do they give the > > right estimate "most of the time"? > > n1) Does it calculate (correct) experimental errors? > Well, none of the tools that I know of provide some degree of confidence on the final capacity estimates. It is an interesting next-step to look at. > > o) Is the tool actively maintained/developped? > Very important. AFAIK, the capacity estimation tools that are actively maintained at this point are pchar, clink, pipechar, nettimer, and pathrate. Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 21 12:12:32 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04470 for ; Thu, 21 Jun 2001 12:12:32 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5LGC3e25864; Thu, 21 Jun 2001 12:12:03 -0400 Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5LGBbe25220 for ; Thu, 21 Jun 2001 12:11:37 -0400 Received: from durian ([166.60.2.77]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with ESMTP id <01K510XG20X2AAU0NS@shoe.reston.mci.net> for ippm@advanced.org; Thu, 21 Jun 2001 12:11:30 -0500 (EST) Date: Thu, 21 Jun 2001 12:03:49 -0400 (EDT) From: Jambi Ganbar Subject: Re: [ippm] bandwidth measuring/estimating In-reply-to: X-Sender: bigj@durian Cc: ippm@advanced.org, bwest@caida.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7BIT Sorry for taking a while to answer. If I man be the voice of this operational network (i.e. vbns) > > > > I think we have to quantify this, for operational use, a tool that > > saturates a link for a short time, is fine, a tool that saturates it for > > hours isn't. > > > > It would be useful to hear more from operations people about what > timescales are acceptable for saturating a path. A train of 20 > back-to-back 1500-byte packets saturates a fast ethernet for about > 2.5msec. Obviously not many people would care. On the other hand, a tool > that attempts to saturate the path for several minutes with TCP traffic, > or even worse with a UDP flow, would cause noticeable effects on the rest > of the traffic. What about the large grey zone between a few > msec and several minutes? > The answer really depends on the network and on what you are trying to test. 1. The premise of this thread if I remember correctly was a statement made wrt "I'm surprised more people are not interested in validating what their b/w is from their provider." In that case where Joe pays for a 40Mb/s pipe to his provider and Joe wants to check that her provider really gives her the b/w she cares to pay for the test is really only hurting Joe if Joe decides to saturate a link for a long period of time. If Joe targets the provider's router though Joe is likely to have some very upset provider at the other end of the phone. Routers are not good targets for such tools as they should be routing not measuring. 2. end to end path. In this scenario we are trying to test a path that goes from one end on the network (you) to another end (them). It could potentially traverse several networks with varying degrees of congestion. This is something that I think about two ways: high packet rate/large packets traffic could look very similar to bulk transfer rate. So if Joe wants to grab that 10MB mp3 file from a host across the network joe will be generating high packet rate traffic. BUT If my tool is trying to estimate path b/w my tool will be taking away from legitimate users b/w by generating traffic to measure the link. Short bursts (ms time frame) are in the noise most of the time unless your links are really THAT congested and your buffers and stressed as it is. I'd love to know what other ippmers think jambi _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 21 20:20:53 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21359 for ; Thu, 21 Jun 2001 20:20:53 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5M0K4e23824; Thu, 21 Jun 2001 20:20:04 -0400 Received: from yourwebsite.com ([24.100.115.107]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f5M0JEe23707 for ; Thu, 21 Jun 2001 20:19:14 -0400 Message-Id: <200106220019.f5M0JEe23707@mailhost.advanced.org> X-Authentication-Warning: mailhost.advanced.org: Host [24.100.115.107] claimed to be yourwebsite.com Reply-To: kchmystery@yahoo.com From: TimeForAChange@real.com To: ippm@advanced.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 21 Jun 2001 20:17:12 -0400 Subject: [ippm] Don't take my word for it Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Earn up to $500K in 120 Days Sending Email!! > ________________________________________________________________________________ Note Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. Please Note-This is a one time mailing.Thank you. ________________________________________________________________________________ > >Excuse us for bothering you but we would like to share our >good luck with everybody. > >My wife received this e-mail and forwarded it to me to review. >We've both read completely through it and have been in contact >with some of the individuals listed below. > >We think it's an excellent opportunity that is well worth the small >investment of time and money, and believe that you will, too! > > >===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====== >If you would like to make at least $500,000 every 4 to 5 months easily and >comfortably, please read the following... > >THEN READ IT AGAIN and AGAIN!!! > > >FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR FINANCIAL >DREAMS WILL COME TRUE, GUARANTEED! > >INSTRUCTIONS: >Order all 5 reports shown on the list below > >For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT >YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose >name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN >ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail >problems. > >When you place your order, make sure you order each of the 5 reports. > > >You will need all 5 reports so that you can save them on your computer >and resell them. YOUR TOTAL COST $5 X 5=$25.00. > >Within a few days you will receive, vie e-mail, each of the 5 re ports from >these 5 different individuals. Save them on your computer so they will be >accessible for you to send to the 1,000's of people who will order them >from you. Also make a floppy of these reports and keep it on your desk in >case something happens to your computer. > > >IMPORTANT - DO NOT alter the names of the people who are listed next >to each report, or their sequence on the list, in any way other than what is >instructed below in step '' 1 through 6 '' or you will loose out on a >majority of your profits. Once you understand the way this works, >you will also see how it does not work if you change it. Remember, >this method has been tested, and if altered, it will NOT work !!! >People have tried to put their friends/relatives names on all five thinking >they could get all the money. But it does not work this way. Believe us, >and Do Not try to change anything other than what is instructed. If you do, >it will not work for you. >Remember, honesty reaps the reward!!! > > > > > >1.... After you have ordered all 5 reports, take this advertisement and >REMOVE the name & address of the person in REPORT # 5. This person >has made it through the cycle and is no doubt counting their fortune > > >2....Move the name & address in REPORT # 4 down toREPORT # 5. > > >3....Move the name & address in REPORT # 3 down TO REPORT # 4. > > >4....Move the name & address in REPORT # 2 downTO REPORT # 3. > > >5.... Move the name & address in REPORT # 1 down TO REPORT # 2 > > >6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE >SURE you copy every name & address ACCURATELY! >****Take this entire letter, with the modified list of names, and save it on >your computer. DO NOT MAKE ANY OTHER CHANGES. > > >Save this on a disk as well, just in case you loose any data. To assist you >with marketing your business on the internet, the 5 reports you purchase >will provide you with invaluable marketing information which includes how >to send bulk e-mails legally, where to find thousands of free classified ads >and much more. > > >There are 2 Primary methods to get this venture going: > > >METHOD # 1:BY SENDING BULK E-MAIL LEGALLY > >Let's say that you decide to start small, just to see how it goes, and we >Will assume you and those involved send out only 5,000 e-mails each. Let's >also assume that the mailing receive only a 0.2% response (the response >could be much better but lets just say it is only 0.2%. Also many people >will send out hundreds of thousands e-mails instead of only 5,000 each). >Continuing with this example, you send out only 5,000 e-mails. With a 0.2% >response, that is only 10 orders for report # 1. Those 10 people responded >by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 >e-mails only 0.2% responded with orders. That's=100 people responded and >ordered Report # 2. > > >Those 100 people mail out 5,000 e-mails each for a total of 500,000 >e-mails. The 0.2% response to that is 1000 orders for Report # 3. > > >Those 1000 people send out 5,000 e-mails each for a total of 5 million >e-mails sent out. The 0.2% response to that is 10,000 orders for Report # >4. > > >Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 >(50 million) e-mails. > > > >The 0.2% response to that is 100,000 orders for Report # 5 > > THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). >Your total income in this example is: 1..... $50 + 2..... $500 + 3..... >$5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 > > >NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT >THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU >CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! > > > >REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE >ORDERING OUT OF 5,000 YOU MAILED TO. > >Dare to think for a moment what would happen if everyone or half or even >one 4th of those people mailed 100,000 e-mails each or more? There are >over 150 million people on the Internet worldwide and counting. Believe me, >many people will do just that, and more! > > > >METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET >Advertising on the net is very very inexpensive and there are hundreds >of FREE places to advertise. Placing a lot of free ads on the Internet will >easily get a larger response. We strongly suggest you start with Method # 1 >and add METHOD # 2 as you go along. For every $5 you receive, all you >must do is e-mail them the Report they ordered. That's it. Always provide >same day service on all orders. > >This will guarantee that the e-mail they send out, with your name and >address on it, will be prompt because they can not advertise until they >receive the report. > > >========= AVAILABLE REPORTS ============= >ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: > >============================================== >Always send $5 cash (U.S. CURRENCY only) for each Report. > >Checks NOT accepted. >Make sure the cash is concealed by wrapping it in at least 2 sheets >of paper. > > On one of those sheets of paper, Write > > a.The NUMBER & the NAME of the Report > > you are ordering, > > b. YOUR E-MAIL ADDRESS and > > c. your name and postal address. > > (In case of mail difficulties.) > > >PLACE YOUR ORDER FOR THESE REPORTS NOW : > >REPORT # 1: "The Insider's Guide to Advertising for Free on the Net" >Order Report #1 from: >Kerry G. >PO Box 210132 >San Francisco, CA 94121 >USA >_________________________________________________________ >REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the Net" >Order Report # 2 from: >P.Harry >P.O. Box 470015 >Brooklyn, NY 11247 > USA >__________________________________________________________ >REPORT # 3: "Secret to Multi-Level Marketing on the Net" >Order Report # 3 from: >Mary Morgan >12 Condotti Drive >Woodbridge, Ontario, L4H 2C8 >Canada >__________________________________________________________ >REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" >Order Report # 4 from: >D. Harris >6717 Main Street >Stouffville, ON L4A 6B3 >Canada >__________________________________________________________ >REPORT #5: "How to Send Out One Million e-mails for Free" >Order Report # 5 from: >Christa H >6021 Yonge Street, Ste. 1021 >Toronto, ON M2M 3W2 >Canada > >_________________________________________________________ >You can KEEP TRACK of your PROGRESS by watching which report >people are ordering from you. IF YOU WANT TO GENERATE MORE >INCOME SEND ANOTHER BATCH OF E-MAILS AND START >THE WHOLE PROCESS AGAIN. >_________________________________________________________ >$$$$$$$$$YOUR SUCCESS GUIDELINES $$$$$$$$$$$ > > >Follow these guidelines to guarantee your success: > > >=== If you do not receive at least 10 orders for Report #1 within 2 >weeks, continue sending e-mails until you do. > > >=== After you have received 10 orders, 2 to 3 weeks after that you >should receive 100 orders or more for REPORT # 2. If you did not, >continue advertising or sending e-mails until you do. > > >=== Once you have received 100 or more orders for Report # 2, YOU >CAN RELAX, because the system is already working for you, and the >cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: >Every time your name is moved down on the list, you are placed in front >of a Different report. > > >There is NO LIMIT to the income you can generate from this business !!! > > >=============================================== > > >FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS >PROGRAM: > >You have just received information that can give you >financial freedom for the rest of your life, with NO RISK and JUST >A LITTLE BIT OF EFFORT. You can make more money in the next >few weeks and months than you have ever imagined. Follow the program >EXACTLY AS INSTRUCTED. Do Not change it in any way. It works >exceedingly well as it is now. > > >Remember to e-mail a copy of this exciting report after you have put >your name and address in Report #1 and moved others to #2 ..........# 5 >as instructed above. One of the people you send this to may send out >100,000 or more e-mails and your name will be on every one of them. >Remember though, the more you send out the more potential customers >you will reach. > > >So my friend, I have given you the ideas, information, materials and >opportunity to become financially independent. IT IS UP TO YOU NOW ! > > >============ TESTIMONIALS ================ > >This is what one had to say: ''Thanks to this profitable opportunity. I >was approached many times before but each time I passed on it. I am >so glad I finally joined just to see what one could expect in return for the >minimal effort and money required. > >To my astonishment, I received total $610,470.00 in 21 weeks, >with money still coming in." >Pam Hedland, Fort Lee, New Jersey > > >Here is another testimonial: > >"This program has been around for a long time but I never believed >in it. But one day when I received this again in the mail I decided to >gamble my $25 on it. I followed the simple instructions and walaa >..... 3 weeks later the money started to come in. > >First month I only made $240.00 but the next 2 months after that I made >a total of $290,000.00. So far, in the past 8 months by re-entering the >program, I have made over $710,000.00 and I am playing it again. The >key to success in this program is to follow the simple steps and NOT change >anything.'' > > >"My name is Mitchell. My wife, Jody and I live in Chicago. I am an >accountant with a major U.S. Corporation and I make pretty good money. >When I received this program I grumbled to Jody about receiving ''junk >mail''. I made fun of the whole thing, spouting my knowledge of the >population and percentages involved. I ''knew'' it wouldn't work. >Jody totally ignored my supposed intelligence and a few days later >she jumped in with both feet. > >I made merciless fun of her, and was ready to lay the old ''I told you so'' on >her when the thing didn't work. Well, the laugh was on me! Within 3 weeks >she had received 50 responses. Within the next 45 days she had received >total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody >in her ''hobby''. > >Mitchell Wolf M.D., Chicago, Illinois > >================================================ > > >''Not being the gambling type, it took me several weeks to make up my >mind to participate in this plan. But conservative that I am, I decided that >the initial investment was so little that there was just no way that I >wouldn't get enough orders to at least get my money back''. '' I was >surprised when I found my medium size post office box crammed with >orders. I made $319,210.00 in the first 12 weeks. The nice thing about >this deal is that it does not matter where people live. There simply isn't a >better investment with a faster return and so big." >Dan Sondstrom, Alberta, Canada > > >================================================ >''I had received this program before. I deleted it, but later I wondered >if I should have given it a try. Of course, I had no idea who to contact to >get another copy, so I had to wait until I was e-mailed agai n by someone >else.........11 months passed then it luckily came again...... I did not >delete this one! I made more than $490,000 on my first try and all the >money came within 22 weeks." >Susan De Suza, New York, N.Y. > > >================================================= > > >''It really is a great opportunity to make relatively easy money with >little cost to you. I followed the simple instructions carefully and >within 10 days the money started to come in. My first month I made >$20,560.00 and by the end of third month my total cash count was >$362,840.00. Life is beautiful, Thanks to internet.". >Fred Dellaca, Westport, New Zealand > > >================================================= >ORDER YOUR REPORTS TODAY AND GET STARTED ON >'YOUR' ROAD TO FINANCIAL FREEDOM ! >================================================= > > >About 50,000 new people get online every month! >_______________________________________________________ > > > > >FOR YOUR INFORMATION.... >If you need help with starting a business, registering a business name, >learning how income tax is handled, etc., contact your local office of the >Small Business Administration (a Federal agency) 1-(800)827-5722 for free >help and answers to questions. Also, the Internal Revenue Service offers >free help via telephone and free seminars about business tax requirements. > >Under Bill S1618 Title III passed by the 105th US Congress this letter >cannot be considered spam as long as the sender includes contact >information >and a method of removal. This is a one-time e-mail transmission. No request >for removal is necessary. > >If you have any questions of the legality of this program, contact the >Office of Associate Director for Marketing Practices, Federal Trade >Commission, Bureau of Consumer Protection, Washington, D.C. > > Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. Please Note-This is a one time mailing.Thank you. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 22 10:37:19 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23267 for ; Fri, 22 Jun 2001 10:37:18 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MEb3e22384; Fri, 22 Jun 2001 10:37:03 -0400 Received: from rocky.wellesley.edu (rocky.wellesley.edu [149.130.13.78]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MEaUe21577 for ; Fri, 22 Jun 2001 10:36:31 -0400 Received: from localhost (downey@localhost) by rocky.wellesley.edu (8.11.0/8.11.0) with ESMTP id f5MEUlW09985; Fri, 22 Jun 2001 10:30:48 -0400 X-Authentication-Warning: rocky.wellesley.edu: downey owned process doing -bs Date: Fri, 22 Jun 2001 10:30:46 -0400 (EDT) From: "Allen B. Downey" To: "bigj@mci.net" cc: ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Thu, 21 Jun 2001, bigj@mci.net wrote: > 1. The premise of this thread if I remember correctly was a statement made > wrt "I'm surprised more people are not interested in validating what their > b/w is from their provider." In that case where Joe pays for a 40Mb/s > pipe to his provider and Joe wants to check that her provider really gives > her the b/w she cares to pay for the test is really only hurting Joe if > Joe decides to saturate a link for a long period of time. > If Joe targets the provider's router though Joe is likely to have some > very upset provider at the other end of the phone. Routers are not good > targets for such tools as they should be routing not measuring. This scenario is something pathchar/pchar/clink are useful for. Since the link in question is likely to be close to the sender, and not as fast as backbone links, you are likely to get an accurate answer. Also, the route to that link is unlikely to change, so you could spread the measurement over an arbitrarily long period of time, and thereby make the measurement load insignificant. The only caveat is that the number you get would be the hardware bandwidth of the link -- it would not tell you what fraction of that bandwidth a given customer could get. In general, pathchar/pchar/clink are configured to introduce an insignificant amount of traffic. Cheers, Allen _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 22 10:46:54 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23784 for ; Fri, 22 Jun 2001 10:46:54 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MEl3e25970; Fri, 22 Jun 2001 10:47:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MEkVe25316 for ; Fri, 22 Jun 2001 10:46:31 -0400 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 QAA06318; Fri, 22 Jun 2001 16:46:27 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id QAA11053; Fri, 22 Jun 2001 16:46:27 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 22 Jun 2001 16:46:27 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Constantinos Dovrolis cc: Jambi Ganbar , ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Wed, 20 Jun 2001, Constantinos Dovrolis wrote: > > > n) Probably the most important issue: Is it accurate? Obviously, all > > > these tools are based on statistical methodologies. This means that > > > there is no guarantee that they will give you the right value everytime > > > you run them. The possibility of error is always there in every > > > area of measurements and experimentation. However, do they give the > > > right estimate "most of the time"? > > > > n1) Does it calculate (correct) experimental errors? > > > > Well, none of the tools that I know of provide some degree of confidence > on the final capacity estimates. It is an interesting next-step to look at. In first order, I'd think that this is very simple to calculate: all programs measure RTT as a function of number of bytes sent, then determine the slope of this line by fitting it to a straight line, the bandwidth is then 1/slope (Byte/sec). All fitting methods can also give error estimates on the slope and this can be easily turned into an experimental error on the bandwidth. Since this is all very simple, I'm surprised that none of the tools do this, can anybody explain why or did I overlook something? Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 22 10:56:04 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24015 for ; Fri, 22 Jun 2001 10:56:03 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MEu3e30493; Fri, 22 Jun 2001 10:56:03 -0400 Received: from femail2.sdc1.sfba.home.com ([24.0.95.82]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MEtWe30226 for ; Fri, 22 Jun 2001 10:55:32 -0400 X-Authentication-Warning: mailhost.advanced.org: Host [24.0.95.82] claimed to be femail2.sdc1.sfba.home.com Received: from intruder.bmah.org ([24.176.204.87]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010622145529.GZKO20390.femail2.sdc1.sfba.home.com@intruder.bmah.org>; Fri, 22 Jun 2001 07:55:29 -0700 Received: (from bmah@localhost) by intruder.bmah.org (8.11.3/8.11.3) id f5MEtSf71289; Fri, 22 Jun 2001 07:55:28 -0700 (PDT) (envelope-from bmah) Message-Id: <200106221455.f5MEtSf71289@intruder.bmah.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Henk Uijterwaal (RIPE-NCC)" Cc: Constantinos Dovrolis , Jambi Ganbar , ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: References: Comments: In-reply-to "Henk Uijterwaal (RIPE-NCC)" message dated "Fri, 22 Jun 2001 16:46:27 +0200." From: bmah@acm.org (Bruce A. Mah) Reply-To: bmah@acm.org X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_2005314864P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 22 Jun 2001 07:55:28 -0700 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --==_Exmh_2005314864P Content-Type: text/plain; charset=us-ascii If memory serves me right, "Henk Uijterwaal (RIPE-NCC)" wrote: > In first order, I'd think that this is very simple to calculate: all > programs measure RTT as a function of number of bytes sent, then determine > the slope of this line by fitting it to a straight line, the bandwidth is > then 1/slope (Byte/sec). All fitting methods can also give error > estimates on the slope and this can be easily turned into an experimental > error on the bandwidth. Followed you all the way up until the last sentence. Is there an easy way to do this part? > Since this is all very simple, I'm surprised that none of the tools do > this, can anybody explain why or did I overlook something? Errr...pchar does, depending on which linear fit you tell it to use. For the least sum of squares and least median of squares fits, it gives the coeffecient of determination. For the non-parametric, rank-based fit, it gives a confidence interval for the slope. Also, the pathchar/clink/pchar family of programs relies on differencing between adjacent partial paths to compute per-link estimates; it wasn't clear to me how to do a confidence interval or other goodness-of-fit parameter for the per-link parameters (after the differencing). So it's not quite as easy as you made it sound..... Bruce. --==_Exmh_2005314864P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE7M1xg2MoxcVugUsMRAhTyAJ4oey6sbJybd4AyU+b25D1aRz+ucACgr/f8 YNrNkgBh4blEJ6LARIs2tSs= =bTIT -----END PGP SIGNATURE----- --==_Exmh_2005314864P-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 22 11:05:08 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24584 for ; Fri, 22 Jun 2001 11:05:07 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MF53e02571; Fri, 22 Jun 2001 11:05:03 -0400 Received: from rocky.wellesley.edu (rocky.wellesley.edu [149.130.13.78]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MF4Se02451 for ; Fri, 22 Jun 2001 11:04:28 -0400 Received: from localhost (downey@localhost) by rocky.wellesley.edu (8.11.0/8.11.0) with ESMTP id f5MEwd210015; Fri, 22 Jun 2001 10:58:40 -0400 X-Authentication-Warning: rocky.wellesley.edu: downey owned process doing -bs Date: Fri, 22 Jun 2001 10:58:38 -0400 (EDT) From: "Allen B. Downey" To: "henk@ripe.net" cc: ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List > In first order, I'd think that this is very simple to calculate: all > programs measure RTT as a function of number of bytes sent, then determine > the slope of this line by fitting it to a straight line, the bandwidth is > then 1/slope (Byte/sec). All fitting methods can also give error > estimates on the slope and this can be easily turned into an experimental > error on the bandwidth. > > Since this is all very simple, I'm surprised that none of the tools do > this, can anybody explain why or did I overlook something? > All fitting methods give error estimates that are based on assumptions about the errors that are, in this case, not true. clink uses a nonparametric technique to estimate error bounds, and it does report them. But getting better error estimates is definitely high on the list of prorities for current work. Cheers, Allen _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 22 11:08:57 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24865 for ; Fri, 22 Jun 2001 11:08:56 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MF93e04915; Fri, 22 Jun 2001 11:09:03 -0400 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MF8ue04903 for ; Fri, 22 Jun 2001 11:08:56 -0400 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 RAA11763; Fri, 22 Jun 2001 17:08:52 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id RAA11419; Fri, 22 Jun 2001 17:08:52 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 22 Jun 2001 17:08:52 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: "Allen B. Downey" cc: ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Fri, 22 Jun 2001, Allen B. Downey wrote: > > > In first order, I'd think that this is very simple to calculate: all > > programs measure RTT as a function of number of bytes sent, then determine > > the slope of this line by fitting it to a straight line, the bandwidth is > > then 1/slope (Byte/sec). All fitting methods can also give error > > estimates on the slope and this can be easily turned into an experimental > > error on the bandwidth. > > > > Since this is all very simple, I'm surprised that none of the tools do > > this, can anybody explain why or did I overlook something? > > > All fitting methods give error estimates that are based > on assumptions about the errors that are, in this case, > not true. Allan, What assumptions and why? Henk > > clink uses a nonparametric technique to estimate error > bounds, and it does report them. > > But getting better error estimates is definitely high > on the list of prorities for current work. > > Cheers, > Allen > > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Jun 22 11:17:41 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25394 for ; Fri, 22 Jun 2001 11:17:40 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MFH3e08384; Fri, 22 Jun 2001 11:17:03 -0400 Received: from www.shoutloud.com (www.shoutloud.com [212.78.71.109] (may be forged)) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5MFGge08360 for ; Fri, 22 Jun 2001 11:16:43 -0400 Received: from www.shoutloud.com (localhost [127.0.0.1]) by localhost (8.10.2/8.10.2) with ESMTP id f5MFHWW02739; Fri, 22 Jun 2001 15:17:32 GMT Date: Fri, 22 Jun 2001 15:17:32 GMT Message-Id: <200106221517.f5MFHWW02739@www.shoutloud.com> To: ippm@advanced.org From: sales@shoutloud.com Subject: [ippm] SSPM.COM Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Dear Sir/Madam, Re: SSPM.COM The above internet domain name has been placed on sale at http://www.shoutloud.com, Europe's leading domain name exchange. I can see from visiting your website, that there are clearly synergies between this name and your own business. I therefore felt it appropriate to contact you directly. If you would like an opportunity to acquire this name please either visit our web site or simply reply to this e-mail. Remember, it might never come up for sale again! To go directly to the details for this name, follow the link below: http://www.shoutloud.com/cgi-bin/qauction.cgi?417879 If you would like further information or advice, or have any domain related questions that we can assist you with, please do not hesitate to contact me. Thank you. Sean Romain Sales & Marketing Executive http://www.shoutloud.com Europe's Largest Domain Name Exchange ------------------------------------------ Earn as a ShoutLoud.com affiliate: http://www.shoutloud.com/AFF.shtml ------------------------------------------ Visit our live domain name news-feed: http://www.shoutloud.com/cgi-bin/qnews.cgi ------------------------------------------ #*%*# _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Jun 27 18:42:49 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09275 for ; Wed, 27 Jun 2001 18:42:48 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5RMf2e05527; Wed, 27 Jun 2001 18:41:02 -0400 Received: from orc.cs.waikato.ac.nz (orc.cs.waikato.ac.nz [130.217.241.22]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5RMe5e05390 for ; Wed, 27 Jun 2001 18:40:06 -0400 Received: from orca.cs.waikato.ac.nz ([130.217.244.4] helo=cs.waikato.ac.nz ident=sfd) by orc.cs.waikato.ac.nz with esmtp (Exim 3.16 #6) id 15FNyZ-00052K-00; Thu, 28 Jun 2001 10:39:59 +1200 Message-ID: <3B3A60BF.8050701@cs.waikato.ac.nz> Date: Thu, 28 Jun 2001 10:39:59 +1200 From: Stephen Donnelly Organization: The University of Waikato User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4 i686; en-US; rv:0.9.1) Gecko/20010620 X-Accept-Language: en-us MIME-Version: 1.0 To: Vern Paxson CC: IPPM WG References: <200105230744.f4N7iA123147@daffy.ee.lbl.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [ippm] Re: wire-arrival-time definition (2330 etc) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Vern Paxson wrote: >> Should the wire arival time erfer to the time of the first link layer bit, or the first IP bit? > Good question. My inclination would be to consider the wire arrival time > as reflecting first-link-layer-bit-seen-on-the-wire. But I don't think > that's particularly fundamental, given things like preambles. It would > be good to nail down, and perhaps worth a thread on the IPPM list. > > Vern Well, my attempt to get a discussion startde on IPPM a month or so back came to naught, I tend to agree though. Although IPPM is an IP metric, it makes most sense to be define OWD as being from the first physical layer bit to last physical layer bit. This means that the wire-arrival-time at the OWD source network is the same as the time at which the host starts to transmit the packet, rather than being some link-type dependent delay after that time. That ought to make the timeing measurements simpler. Likewise for the wire exit time at the OWD receiver, you want to define it to be the time at which the physical layer packet has ceased arriving, not at the earlier time at which the IP part of the packet has finished arriving. Since a 'typical' host based packet time-stamping system will *at best* generate a time-stamp some tme after the entire physical frame has arrived, this time-stamp bes approximates the end of the physical packet, not the end of the IP packet. (Even then it's a poor time-stamp, but with hardware based systems we can easily distinguish between the two, and it's important that it be well defined which to use). Joerg Micheel mentioned that since OWD is specified from first bit sent to last bit received, the OWD will also depend on the length of the packet, however I assume this is implicitly assumed in the definition of the 'Type-P' packet used. Stephen. -- ----------------------------------------------------------------------- Stephen Donnelly (BCMS) email: sfd@cs.waikato.ac.nz WAND Group Room GG.15 phone +64 7 838 4086 Computer Science Department, University of Waikato, New Zealand ----------------------------------------------------------------------- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Jun 28 05:30:51 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09843 for ; Thu, 28 Jun 2001 05:30:51 -0400 (EDT) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5S9T3e20824; Thu, 28 Jun 2001 05:29:03 -0400 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f5S9SPe20450 for ; Thu, 28 Jun 2001 05:28:26 -0400 Received: from joshua-vreijs.dublin.access.hea.net ([193.1.218.227] helo=surfnet.nl) by survis.surfnet.nl with ESMTP (exPP) id 15FY5y-0006V6-00; Thu, 28 Jun 2001 11:28:18 +0200 Message-ID: <3B3AF8B1.93FCB23C@surfnet.nl> Date: Thu, 28 Jun 2001 10:28:17 +0100 From: Victor Reijs Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en-gb] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Allen B. Downey" CC: "bigj@mci.net" , ippm@advanced.org, bwest@caida.org Subject: Re: [ippm] bandwidth measuring/estimating References: Content-Type: multipart/mixed; boundary="------------9328D216F2AB8CAADB723D48" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. --------------9328D216F2AB8CAADB723D48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all of you, "Allen B. Downey" wrote: > > On Thu, 21 Jun 2001, bigj@mci.net wrote: > > > 1. The premise of this thread if I remember correctly was a statement made > > wrt "I'm surprised more people are not interested in validating what their > > b/w is from their provider." In that case where Joe pays for a 40Mb/s > > pipe to his provider and Joe wants to check that her provider really gives > > her the b/w she cares to pay for the test is really only hurting Joe if > > Joe decides to saturate a link for a long period of time. Can the pchar/pathrate/clink family determine the physical capacity or can they also determine the logical capacity (like determined the bandwidth determined by shaping/CAR etc. IP features in a router)? I really wonder of they are able to do this? (they even can't determine if a link is OC-3c, because it only measures an OC-1). If these tools can't see these 'IP features', they are perhaps not really usefull. Hope someone can help me with this 'IP feature' issue and the tools. All the best, Victor --------------9328D216F2AB8CAADB723D48 Content-Type: text/x-vcard; charset=us-ascii; name="victor.reijs.vcf" Content-Description: Card for Victor Reijs Content-Disposition: attachment; filename="victor.reijs.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Reijs;Victor tel;fax:+ 353 1 8105121 tel;work:+ 31 30 2305305 x-mozilla-html:FALSE url:http://www.surfnet.nl/ org:SURFnet bv;Networkmanagement adr:;;;Utrecht;;;The Netherlands version:2.1 email;internet:Victor.Reijs@SURFnet.nl title:Network Engineer fn:Victor Reijs end:vcard --------------9328D216F2AB8CAADB723D48-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm