From exim@www1.ietf.org Tue Aug 12 16:42:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28732 for ; Tue, 12 Aug 2003 16:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfy4-0002bS-56 for imrg-archive@odin.ietf.org; Tue, 12 Aug 2003 16:42:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CKg8bx010002 for imrg-archive@odin.ietf.org; Tue, 12 Aug 2003 16:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfy4-0002bF-1K for imrg-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 16:42:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28689 for ; Tue, 12 Aug 2003 16:42:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mfy2-0003u9-00 for imrg-web-archive@ietf.org; Tue, 12 Aug 2003 16:42:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mfy1-0003u6-00 for imrg-web-archive@ietf.org; Tue, 12 Aug 2003 16:42:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfxx-0002aA-Gv; Tue, 12 Aug 2003 16:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfxh-0002Zn-T6 for imrg@optimus.ietf.org; Tue, 12 Aug 2003 16:41:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28684 for ; Tue, 12 Aug 2003 16:41:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mfxf-0003u3-00 for imrg@ietf.org; Tue, 12 Aug 2003 16:41:43 -0400 Received: from web11409.mail.yahoo.com ([216.136.131.220]) by ietf-mx with smtp (Exim 4.12) id 19mfxf-0003u0-00 for imrg@ietf.org; Tue, 12 Aug 2003 16:41:43 -0400 Message-ID: <20030812204143.36700.qmail@web11409.mail.yahoo.com> Received: from [67.8.72.44] by web11409.mail.yahoo.com via HTTP; Tue, 12 Aug 2003 13:41:43 PDT Date: Tue, 12 Aug 2003 13:41:43 -0700 (PDT) From: Yeggy Easwaran To: imrg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1980066972-1060720903=:36563" Subject: [IMRG] New "Available Bandwidth" Measurement tool Sender: imrg-admin@ietf.org Errors-To: imrg-admin@ietf.org X-BeenThere: imrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Measurement Research Group List-Post: List-Help: List-Subscribe: , --0-1980066972-1060720903=:36563 Content-Type: text/plain; charset=us-ascii Ningning Hu, Peter Steenkiste. Evaluation and Characterization of Available Bandwidth Probing Techniques. In the IEEE JSAC Special Issue in Internet and WWW Measurement, Mapping, and Modeling, Vol. 21(6), Aug. 2003 talks about a technique called IGI/PTR for measuring available bandwidth. This technique is supposed to measure available bandwidth in a network path faster than Pathload (``End-to-End Available Bandwidth: Measurement methodology, Dynamics, and Relation with TCP Throughput'', in Proceedings of ACM SIGCOMM, August 2002 (also look at an extended version, to appear in the ACM/IEEE Transactions on Networking, 2003). Does anybody have more information/insights on this? --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. --0-1980066972-1060720903=:36563 Content-Type: text/html; charset=us-ascii
Ningning Hu, Peter Steenkiste. Evaluation and Characterization of Available Bandwidth Probing Techniques. In the IEEE JSAC Special Issue in Internet and WWW Measurement, Mapping, and Modeling, Vol. 21(6), Aug. 2003
 
talks about a technique called IGI/PTR for measuring available bandwidth. This technique is supposed to measure available bandwidth in a network path faster than Pathload
 
 (``End-to-End Available Bandwidth: Measurement methodology, Dynamics, and Relation with TCP Throughput'', in Proceedings of ACM SIGCOMM, August 2002 (also look at an extended version, to appear in the ACM/IEEE Transactions on Networking, 2003).
 
Does anybody have more information/insights on this?

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. --0-1980066972-1060720903=:36563-- _______________________________________________ IMRG mailing list IMRG@ietf.org https://www1.ietf.org/mailman/listinfo/imrg From exim@www1.ietf.org Wed Aug 13 16:12:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04571 for ; Wed, 13 Aug 2003 16:12:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1yh-0005WM-05 for imrg-archive@odin.ietf.org; Wed, 13 Aug 2003 16:12:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DKCEWI021218 for imrg-archive@odin.ietf.org; Wed, 13 Aug 2003 16:12:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1yg-0005W9-RN for imrg-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 16:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04560 for ; Wed, 13 Aug 2003 16:12:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1yf-0004kR-00 for imrg-web-archive@ietf.org; Wed, 13 Aug 2003 16:12:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n1ye-0004kL-00 for imrg-web-archive@ietf.org; Wed, 13 Aug 2003 16:12:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1yS-0005UW-JB; Wed, 13 Aug 2003 16:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1y6-0005UB-EP for imrg@optimus.ietf.org; Wed, 13 Aug 2003 16:11:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04546 for ; Wed, 13 Aug 2003 16:11:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1y4-0004k8-00 for imrg@irtf.org; Wed, 13 Aug 2003 16:11:36 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19n1y4-0004k1-00 for imrg@irtf.org; Wed, 13 Aug 2003 16:11:36 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 4FC2168974 for ; Wed, 13 Aug 2003 16:11:06 -0400 (EDT) Received: from guns.grc.nasa.gov (guns.grc.nasa.gov [139.88.122.88]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7DKB5rE027502; Wed, 13 Aug 2003 16:11:05 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.grc.nasa.gov (Postfix) with ESMTP id 5B9233BB3CD; Wed, 13 Aug 2003 16:11:05 -0400 (EDT) To: imrg@irtf.org Cc: "Ethan Blanton" From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: Mrs. Robinson Date: Wed, 13 Aug 2003 16:11:05 -0400 Message-Id: <20030813201105.5B9233BB3CD@guns.grc.nasa.gov> Subject: [IMRG] looking for web data Sender: imrg-admin@ietf.org Errors-To: imrg-admin@ietf.org X-BeenThere: imrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Measurement Research Group List-Post: List-Help: List-Subscribe: , Folks- I am looking for a little help. With Ethan Blanton (CCed) I am working on gauging the "burstiness" of TCP connections (in the hopes of figuring out whether it is worth it to try to mitigate these bursts in TCP). We have analyzed a year-long packet trace of web connections (for 2001) to a web server we have here at NASA GRC, which has provided some nice insights. However, we are interested in getting a bit more data that is (a) from a different place and (b) is a little more recent. So, we're looking for additional packet-level traces of web connections. If you'd be willing to share some data with us (anonymized would be completely fine) or you're willing to crunch over your data and give us back the results produced by our tools, we'd be quite appreciative. We intend to publish only high-level insights gained from the traces and not things like where the connections come from, etc. If you are interested in helping we'd be grateful if you could contact us off-list. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ IMRG mailing list IMRG@ietf.org https://www1.ietf.org/mailman/listinfo/imrg From exim@www1.ietf.org Fri Aug 22 08:32:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20401 for ; Fri, 22 Aug 2003 08:32:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qB5O-0007sd-2x for imrg-archive@odin.ietf.org; Fri, 22 Aug 2003 08:32:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MCWA9B030287 for imrg-archive@odin.ietf.org; Fri, 22 Aug 2003 08:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qB5N-0007sQ-VV for imrg-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 08:32:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20368 for ; Fri, 22 Aug 2003 08:32:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qB5L-0003EL-00 for imrg-web-archive@ietf.org; Fri, 22 Aug 2003 08:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qB5K-0003EH-00 for imrg-web-archive@ietf.org; Fri, 22 Aug 2003 08:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qB5E-0007qo-8K; Fri, 22 Aug 2003 08:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3EQ-0001t9-RM for imrg@optimus.ietf.org; Fri, 22 Aug 2003 00:08:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19243 for ; Fri, 22 Aug 2003 00:08:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q3EO-0006BY-00 for imrg@ietf.org; Fri, 22 Aug 2003 00:08:56 -0400 Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net ([63.198.35.122]) by ietf-mx with esmtp (Exim 4.12) id 19q3EN-0006BV-00 for imrg@ietf.org; Fri, 22 Aug 2003 00:08:55 -0400 Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) by adsl-63-198-35-122.dsl.snfc21.pacbell.net (8.12.8p1/8.12.8) with ESMTP id h7M0o8Ze000604; Thu, 21 Aug 2003 17:50:08 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Message-ID: <3F4568C0.329F667D@lbl.gov> Date: Thu, 21 Aug 2003 17:50:08 -0700 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: yeggyb@yahoo.com CC: imrg@ietf.org Subject: [Fwd: Re: [IMRG] New "Available Bandwidth" Measurement tool] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: imrg-admin@ietf.org Errors-To: imrg-admin@ietf.org X-BeenThere: imrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Measurement Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since I am not on the mailing list, I do not know how many replies you may already get on it. Here is the link: http://www-2.cs.cmu.edu/~hnn/igi/ It is a nice paper because it has systematically discussed more details of the technology used IGI/PTR, which is modified Pathload algorithm for efficiency. The problem is the accuracy is lower. Most current bandwidth measurement research has ignored the system capability to handle high-speed network I/O; or the designers have no idea about system capability at all because system issues belong to the engineer. This creates a significant problem on network bandwidth measurement tool development: 10 years ago, we have been able to measure the 100 Mb/s network; however, most new tools are only able to measure 100 Mb/s path now. IT IS USELESS regardless how wonderful the algorithms are. The new problem is toward to two directions in the future -- accuracy and capability Accuracy is the old problem and capability is the new one because the network speed has exceeded the system I/O bandwidth. All methods except algorithm used in pathchar are requiring the system I/O is higher than the network bandwidth in order to make measurement. Due to this issue, we need to find a very different algorithm to use low-speed packets to measure high-speed network, such as pathchar. Research on the packet-pair-dispersion-based algorithm that requires packets' speed higher than the network available bandwidth and very high resolution system timer has no more valuable to the real world, but the pure research. More information can be found at: http://dsd.lbl.gov/DIDC/papers/imc-2003.pdf 100 Gb/s network will be available very soon. If new tools still work only for O(100 Mb/s) network, then, the memory is wasted. I hope to see some new algorithms for 1 Tb/s, but no more tool for O(100 Mb/s) measurement. -Jin -------- Original Message -------- >>> From: Yeggy Easwaran >>> Date: Tue Aug 12, 2003 1:41:43 PM America/Los_Angeles >>> To: imrg@ietf.org >>> Subject: [IMRG] New "Available Bandwidth" Measurement tool >>> >>> Ningning Hu, Peter Steenkiste. Evaluation and Characterization of >>> Available Bandwidth Probing Techniques. In the IEEE JSAC Special >> Issue >>> in Internet and WWW Measurement, Mapping, and Modeling, Vol. 21(6), >>> Aug. 2003 >>> >>> talks about a technique called IGI/PTR for measuring available >>> bandwidth. This technique is supposed to measure available bandwidth >>> in a network path faster than Pathload >>> >>> (``End-to-End Available Bandwidth: Measurement methodology, >> Dynamics, >>> and Relation with TCP Throughput'', in Proceedings of ACM SIGCOMM, >>> August 2002 (also look at an extended version, to appear in the >>> ACM/IEEE Transactions on Networking, 2003). >>> >>> Does anybody have more information/insights on this? _______________________________________________ IMRG mailing list IMRG@ietf.org https://www1.ietf.org/mailman/listinfo/imrg From exim@www1.ietf.org Fri Aug 22 13:37:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09291 for ; Fri, 22 Aug 2003 13:37:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFqN-0005s3-L9 for imrg-archive@odin.ietf.org; Fri, 22 Aug 2003 13:37:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHaxBI022561 for imrg-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFqN-0005rk-BZ for imrg-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 13:36:59 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09163 for ; Fri, 22 Aug 2003 13:36:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFpc-0005Lf-0Y; Fri, 22 Aug 2003 13:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qF9E-0003mJ-Sr for imrg@optimus.ietf.org; Fri, 22 Aug 2003 12:52:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06815 for ; Fri, 22 Aug 2003 12:52:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qF9D-0006uF-00 for imrg@ietf.org; Fri, 22 Aug 2003 12:52:23 -0400 Received: from ece.rice.edu ([128.42.246.164]) by ietf-mx with esmtp (Exim 4.12) id 19qF9C-0006uA-00 for imrg@ietf.org; Fri, 22 Aug 2003 12:52:22 -0400 Received: from localhost (localhost [127.0.0.1]) by ece.rice.edu (Postfix) with ESMTP id C7A8868A98 for ; Fri, 22 Aug 2003 11:52:21 -0500 (CDT) Received: from ece.rice.edu ([127.0.0.1]) by localhost (ece.rice.edu [127.0.0.1:10024]) (amavisd-new) with ESMTP id 16065-01 for ; Fri, 22 Aug 2003 11:52:15 -0500 (CDT) Received: from shag.ece.rice.edu (shag.ece.rice.edu [128.42.246.166]) by ece.rice.edu (Postfix) with ESMTP id E53A768B7C for ; Fri, 22 Aug 2003 11:52:13 -0500 (CDT) Received: from localhost (vinay@localhost) by shag.ece.rice.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA12631 for ; Fri, 22 Aug 2003 11:50:51 -0500 (CDT) X-Authentication-Warning: shag.ece.rice.edu: vinay owned process doing -bs Date: Fri, 22 Aug 2003 11:50:50 -0500 (CDT) From: Vinay Joseph Ribeiro To: Subject: Re: [IMRG] New "Available Bandwidth" Measurement tool In-Reply-To: <3F4568C0.329F667D@lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavis-20021227p3 X-DCC--Metrics: ece.rice.edu 1067; Body=1 Fuz1=1 Fuz2=1 Sender: imrg-admin@ietf.org Errors-To: imrg-admin@ietf.org X-BeenThere: imrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Measurement Research Group List-Post: List-Help: List-Subscribe: , Hi all, While Jin has made some excellent points, I would beg to differ with him on some issues. The point that "network bandwidth has exceeded system I/O bandwidth" is misleading. It gives one the impression that machines connected to Gigabit networks cannot read data at 1Gbps (or close to it) which is not quite true. The real issue with high-speed NIC cards is that they "coalesce" packet arrival interrupts. For example if a NIC receives three 1000byte packets spaced 10 micro-sec apart it may send just 1 interrupt to the higher layer at the end of the 30 micro-sec interval rather than bother the cpu with 3 interrupts one for each packet. This improves efficiency and actually IMPROVES the total system I/O bandwidth. Coalescence clusters packets and so affects packet dispersion techniques that expect only cross-traffic to disperse packets. Several solutions suggest themselves that would allow the use of current packet dispersion techniques. 1. Make use of the larger MTU size. While 1000byte packets can be spaced as close as 8micro-sec on a Giga network, 8000byte packets will be spaced 64micro-sec apart. From my preliminary experiments on a Gigabit testbed I observed that the NIC cards did not coalesce packets spaced this far apart. This solution will require the path MTU to be larger than 1500 bytes. A strong case has been made by Phil Dyksta for the use of jumbo frames: http://sd.wareonearth.com/~phil/jumbo.html Another link by Mathis: http://www.psc.edu/~mathis/MTU/ 2. Modify NIC cards to provide time stamps of when packets arrive at the NIC. If this is achieved then it does not matter for how long packets are delayed in the NIC due to coalescence. With this solution it will not matter if the network speed is 1Gbps or 1Tbps for that matter. I take this opportunity to advertise "pathChirp", a tool that uses special exponentially spaced packet trains to estimate available bandwidth. http://www.spin.rice.edu/Software/pathChirp/ Please feel free to comment/correct any of my opinions. Thanks. Vinay Ribeiro Rice University | vinay@rice.edu | www.ece.rice.edu/~vinay | 713.348.2285 On Thu, 21 Aug 2003, Jin Guojun [NCS] wrote: > Since I am not on the mailing list, I do not know how many replies > you may already get on it. Here is the link: > > http://www-2.cs.cmu.edu/~hnn/igi/ > > It is a nice paper because it has systematically discussed more > details of the technology used IGI/PTR, which is modified Pathload > algorithm for efficiency. The problem is the accuracy is lower. > > Most current bandwidth measurement research has ignored the system > capability to handle high-speed network I/O; or the designers have > no idea about system capability at all because system issues belong > to the engineer. This creates a significant problem on network > bandwidth measurement tool development: > 10 years ago, we have been able to measure the 100 Mb/s network; > however, most new tools are only able to measure 100 Mb/s path now. > IT IS USELESS regardless how wonderful the algorithms are. > > The new problem is toward to two directions in the future -- > > accuracy and capability > > Accuracy is the old problem and capability is the new one > because the network speed has exceeded the system I/O bandwidth. > All methods except algorithm used in pathchar are requiring the > system I/O is higher than the network bandwidth in order to make > measurement. > Due to this issue, we need to find a very different algorithm to use > low-speed packets to measure high-speed network, such as pathchar. > Research on the packet-pair-dispersion-based algorithm that requires > packets' speed higher than the network available bandwidth and very > high resolution system timer has no more valuable to the real world, > but the pure research. More information can be found at: > > http://dsd.lbl.gov/DIDC/papers/imc-2003.pdf > > 100 Gb/s network will be available very soon. If new tools still > work only for O(100 Mb/s) network, then, the memory is wasted. > I hope to see some new algorithms for 1 Tb/s, but no more tool for > O(100 Mb/s) measurement. > > -Jin > > -------- Original Message -------- > >>> From: Yeggy Easwaran > >>> Date: Tue Aug 12, 2003 1:41:43 PM America/Los_Angeles > >>> To: imrg@ietf.org > >>> Subject: [IMRG] New "Available Bandwidth" Measurement tool > >>> > >>> Ningning Hu, Peter Steenkiste. Evaluation and Characterization of > >>> Available Bandwidth Probing Techniques. In the IEEE JSAC Special > >> Issue > >>> in Internet and WWW Measurement, Mapping, and Modeling, Vol. 21(6), > >>> Aug. 2003 > >>> > >>> talks about a technique called IGI/PTR for measuring available > >>> bandwidth. This technique is supposed to measure available bandwidth > >>> in a network path faster than Pathload > >>> > >>> (``End-to-End Available Bandwidth: Measurement methodology, > >> Dynamics, > >>> and Relation with TCP Throughput'', in Proceedings of ACM SIGCOMM, > >>> August 2002 (also look at an extended version, to appear in the > >>> ACM/IEEE Transactions on Networking, 2003). > >>> > >>> Does anybody have more information/insights on this? > > _______________________________________________ > IMRG mailing list > IMRG@ietf.org > https://www1.ietf.org/mailman/listinfo/imrg > _______________________________________________ IMRG mailing list IMRG@ietf.org https://www1.ietf.org/mailman/listinfo/imrg From exim@www1.ietf.org Tue Aug 26 15:31:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28735 for ; Tue, 26 Aug 2003 15:31:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjWv-0001FE-Go for imrg-archive@odin.ietf.org; Tue, 26 Aug 2003 15:31:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJV1pC004777 for imrg-archive@odin.ietf.org; Tue, 26 Aug 2003 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjWu-0001Ed-Oh for imrg-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 15:31:00 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28664 for ; Tue, 26 Aug 2003 15:30:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjW2-000161-GW; Tue, 26 Aug 2003 15:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qHTM-0003w3-LX for imrg@optimus.ietf.org; Fri, 22 Aug 2003 15:21:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15170 for ; Fri, 22 Aug 2003 15:21:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qHTL-0000mt-00 for imrg@ietf.org; Fri, 22 Aug 2003 15:21:19 -0400 Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net ([63.198.35.122]) by ietf-mx with esmtp (Exim 4.12) id 19qHTJ-0000mq-00 for imrg@ietf.org; Fri, 22 Aug 2003 15:21:17 -0400 Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) by adsl-63-198-35-122.dsl.snfc21.pacbell.net (8.12.8p1/8.12.8) with ESMTP id h7MJLHEb000488; Fri, 22 Aug 2003 12:21:17 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Message-ID: <3F466D2D.B66CF075@lbl.gov> Date: Fri, 22 Aug 2003 12:21:17 -0700 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: vinay@ece.rice.edu CC: imrg@ietf.org Subject: Re: [IMRG] New "AvailableBandwidth" Measurement tool]] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: imrg-admin@ietf.org Errors-To: imrg-admin@ietf.org X-BeenThere: imrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Measurement Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A few points I would like to clear for my previous message. (1) The high-speed network I mentioned is not 1 Gb/s, but 10 Gb/s to 1 Tb/s. Current backbone speed is 10Gb/s. 100 Gb/s testbed has been seen in a couple of years ago. We have no problem to measure 1 Gb/s paths, but most tools do. (2) Generic measurement environment vs. specific configuration. Generic environment is what I think for measurement and development. That is, buy a $500 PC to run Linux/FreeBSD etc. The measurement tools should run on any such environment including to use $500,000 machines. Using onboard timestamp and Jumbo MTU is not realistic approach for generic development. This is because: <1> Onboard timestamp NIC is very rare. I only know SysKonnect GigE NICs (v 1.x) has such feature, and they seems to remove this feature on their new NICs (v 2.0). Also, to use this feature requires modifying device driver plus either kernel BPF or L4/IP stack to pass onboard timestamp up to the user layer for all O.S.s if you want your tool to work everywhere. I am working with some new vendors to convince them to add timestamp feature on the new 10Gb NICs, but the final decision is theirs. Key: if a tool only works for a specific environment with very high development (modify kernel) and maintenance cost, why do not we just buy a dedicate NIC such as DAG board for the measurement? <2> Jumbo Frame will not help. It because that Jumbo has not standardized yet. Let's assume that 9K MTU is accepted by everyone in 5 years, it increases single packet size 600% and it will probably stay at this size for another 15 years. How much the network bandwidth will increase in this period? Maybe 1000,000% or more. The paper that I point to has discussed all these issues and issues you mentioned below. So, we need to differ the generic and specific tool development. As to the capability for available bandwidth measurement in the future, it may not be a serious problem because if available bandwidth is higher than the maximum throughput that a machine can make, then just send out packets at full NIC speed. If we can detect that available is lower than the system throughput, then slow it down. Depend on the view point, the system issues may or may not be applied. -Jin -------- Original Message -------- Date: Fri, 22 Aug 2003 11:50:50 -0500 (CDT) From: Vinay Joseph Ribeiro Subject: [Imrg-dist] Re: [IMRG] New "Available Bandwidth" Measurement tool To: Hi all, While Jin has made some excellent points, I would beg to differ with him on some issues. The point that "network bandwidth has exceeded system I/O bandwidth" is misleading. It gives one the impression that machines connected to Gigabit networks cannot read data at 1Gbps (or close to it) which is not quite true. The real issue with high-speed NIC cards is that they "coalesce" packet arrival interrupts. For example if a NIC receives three 1000byte packets spaced 10 micro-sec apart it may send just 1 interrupt to the higher layer at the end of the 30 micro-sec interval rather than bother the cpu with 3 interrupts one for each packet. This improves efficiency and actually IMPROVES the total system I/O bandwidth. Coalescence clusters packets and so affects packet dispersion techniques that expect only cross-traffic to disperse packets. Several solutions suggest themselves that would allow the use of current packet dispersion techniques. 1. Make use of the larger MTU size. While 1000byte packets can be spaced as close as 8micro-sec on a Giga network, 8000byte packets will be spaced 64micro-sec apart. From my preliminary experiments on a Gigabit testbed I observed that the NIC cards did not coalesce packets spaced this far apart. This solution will require the path MTU to be larger than 1500 bytes. A strong case has been made by Phil Dyksta for the use of jumbo frames: http://sd.wareonearth.com/~phil/jumbo.html Another link by Mathis: http://www.psc.edu/~mathis/MTU/ 2. Modify NIC cards to provide time stamps of when packets arrive at the NIC. If this is achieved then it does not matter for how long packets are delayed in the NIC due to coalescence. With this solution it will not matter if the network speed is 1Gbps or 1Tbps for that matter. I take this opportunity to advertise "pathChirp", a tool that uses special exponentially spaced packet trains to estimate available bandwidth. http://www.spin.rice.edu/Software/pathChirp/ Please feel free to comment/correct any of my opinions. Thanks. Vinay Ribeiro Rice University | vinay@rice.edu | www.ece.rice.edu/~vinay | 713.348.2285 On Thu, 21 Aug 2003, Jin Guojun [NCS] wrote: > Since I am not on the mailing list, I do not know how many replies > you may already get on it. Here is the link: > > http://www-2.cs.cmu.edu/~hnn/igi/ > > It is a nice paper because it has systematically discussed more > details of the technology used IGI/PTR, which is modified Pathload > algorithm for efficiency. The problem is the accuracy is lower. > > Most current bandwidth measurement research has ignored the system > capability to handle high-speed network I/O; or the designers have > no idea about system capability at all because system issues belong > to the engineer. This creates a significant problem on network > bandwidth measurement tool development: > 10 years ago, we have been able to measure the 100 Mb/s network; > however, most new tools are only able to measure 100 Mb/s path now. > IT IS USELESS regardless how wonderful the algorithms are. > > The new problem is toward to two directions in the future -- > > accuracy and capability > > Accuracy is the old problem and capability is the new one > because the network speed has exceeded the system I/O bandwidth. > All methods except algorithm used in pathchar are requiring the > system I/O is higher than the network bandwidth in order to make > measurement. > Due to this issue, we need to find a very different algorithm to use > low-speed packets to measure high-speed network, such as pathchar. > Research on the packet-pair-dispersion-based algorithm that requires > packets' speed higher than the network available bandwidth and very > high resolution system timer has no more valuable to the real world, > but the pure research. More information can be found at: > > http://dsd.lbl.gov/DIDC/papers/imc-2003.pdf > > 100 Gb/s network will be available very soon. If new tools still > work only for O(100 Mb/s) network, then, the memory is wasted. > I hope to see some new algorithms for 1 Tb/s, but no more tool for > O(100 Mb/s) measurement. > > -Jin > > -------- Original Message -------- > >>> From: Yeggy Easwaran > >>> Date: Tue Aug 12, 2003 1:41:43 PM America/Los_Angeles > >>> To: imrg@ietf.org > >>> Subject: [IMRG] New "Available Bandwidth" Measurement tool > >>> > >>> Ningning Hu, Peter Steenkiste. Evaluation and Characterization of > >>> Available Bandwidth Probing Techniques. In the IEEE JSAC Special > >> Issue > >>> in Internet and WWW Measurement, Mapping, and Modeling, Vol. 21(6), > >>> Aug. 2003 > >>> > >>> talks about a technique called IGI/PTR for measuring available > >>> bandwidth. This technique is supposed to measure available bandwidth > >>> in a network path faster than Pathload > >>> > >>> (``End-to-End Available Bandwidth: Measurement methodology, > >> Dynamics, > >>> and Relation with TCP Throughput'', in Proceedings of ACM SIGCOMM, > >>> August 2002 (also look at an extended version, to appear in the > >>> ACM/IEEE Transactions on Networking, 2003). > >>> > >>> Does anybody have more information/insights on this? > > _______________________________________________ > IMRG mailing list > IMRG@ietf.org > https://www1.ietf.org/mailman/listinfo/imrg > _______________________________________________ IMRG mailing list IMRG@ietf.org https://www1.ietf.org/mailman/listinfo/imrg From exim@www1.ietf.org Wed Aug 27 23:50:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11548 for ; Wed, 27 Aug 2003 23:50:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBnU-0006vo-Fj for imrg-archive@odin.ietf.org; Wed, 27 Aug 2003 21:42:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1g0JV026640 for imrg-archive@odin.ietf.org; Wed, 27 Aug 2003 21:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBPw-0004xm-T8 for imrg-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 21:17:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26837 for ; Wed, 27 Aug 2003 21:17:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sBPr-0005DM-00 for imrg-web-archive@ietf.org; Wed, 27 Aug 2003 21:17:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sBPr-0005DJ-00 for imrg-web-archive@ietf.org; Wed, 27 Aug 2003 21:17:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4xM-0001Jv-CN; Wed, 27 Aug 2003 14:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rvnW-0001h9-Uf for imrg@optimus.ietf.org; Wed, 27 Aug 2003 04:37:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06553 for ; Wed, 27 Aug 2003 04:36:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rvnU-0001E2-00 for imrg@ietf.org; Wed, 27 Aug 2003 04:36:56 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 19rvnT-0001DN-00 for imrg@ietf.org; Wed, 27 Aug 2003 04:36:55 -0400 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.9/8.12.9/F1) with ESMTP id h7R8aFWj029681; Wed, 27 Aug 2003 10:36:15 +0200 Subject: Re: [IMRG] New "AvailableBandwidth" Measurement tool]] From: Michael Welzl To: "Jin Guojun [NCS]" Cc: vinay@ece.rice.edu, imrg@ietf.org, ghpn-wg@gridforum.org In-Reply-To: <3F466D2D.B66CF075@lbl.gov> References: <3F466D2D.B66CF075@lbl.gov> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1061973336.1735.107.camel@lap10-c703> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 Aug 2003 10:35:36 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: -7.4 () IN_REP_TO,QUOTED_EMAIL_TEXT,RCV_UIBK,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.35 at uibk.ac.at Content-Transfer-Encoding: 7bit Sender: imrg-admin@ietf.org Errors-To: imrg-admin@ietf.org X-BeenThere: imrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Measurement Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To GHPN'ers: the relevant part of this message is the last, "controversial" comment - what do you think of this? Should I write something down on using PTP for Grid-specific network measurements? (If this mail is too long for you, the quick way is: take a look at http://www.welzl.at/ptp and consider its usage for network measurements in Grids.) -------------------------------------------- Hi all, I have a comment, a question and an additional, probably very controversial comment. Comment 1: > <2> Jumbo Frame will not help. It because that Jumbo has not > standardized yet. Let's assume that 9K MTU is accepted by ... another problem I see with Jumbo Frames is that the packet size limits your measurement granularity - the larger your packets, the less precise the result. Question: If the limit is not the link capacity but processing abilities at high speeds (BTW, Jin, I skipped over your paper "system capability effects on ... measurement", it looks very interesting - in fact, I have been wondering myself why nobody ever seemed to care of these things?!), then I assume that packet header processing can become the main problem. So, if you send large packets at a high rate, and then send small packets at the same rate (assuming no background traffic for simplification), you are perhaps going to see reduced throughput provided that processing power is the actual bottleneck, right? My question would be: has anybody ever tried this (if it makes sense at all)? Finally, here's the controversial comment: ANY kind of end-to-end avail-bandwidth measurement method needs to cause at least mild congestion in order to be able to measure anything (assuming no knowledge about the network interior, such as the queuing in use), be it in a separate tool or used within congestion control as in TCP. That is, a queue must grow before you can tell that it did. That's better (earlier) than waiting for packet loss to occur (thus it has been done in TCP enhancements - ECN, or using delay: FAST TCP and Vegas), but still, it means that you need to cause a bit of congestion. I think that claims of non-intrusiveness for end-to-end avail-bw measurement tools are false - they could at best be MILDLY intrusive. Also, we have this problem to deal with: > > All methods except algorithm used in pathchar are requiring the > > system I/O is higher than the network bandwidth in order to make > > measurement. > > Due to this issue, we need to find a very different algorithm to use > > low-speed packets to measure high-speed network, such as pathchar. ...although, as Jin rightly pointed out, it may not be serious because the max. bandwidth a machine can reach (by any means possible) may indeed be the max. bandwidth it is interested in. My controversial opinion is: I believe that it may be beneficial to consider QUERYING for performance (traffic) information instead of probing the network. I devised the "Performance Transparency Protocol (PTP)" as a means to do efficiently retrieve performance information from a path a few years ago, and I showed that it can be very useful for congestion control in my ph.d. thesis, a revised version of which is now available from Kluwer ("Scalable Performance Signalling and Congestion Avoidance"). How does it work? It retrieves the capacity (link capacity in the case of droptail queuing and no traffic class separation), a timestamp, a traffic counter (ifMIB-ifOutOctets) and the address from each router. After two such packets (and with each consecutive one), you get an idea of the available bandwidth at each router (and thus, also the bottleneck) for the interval between the two packets. Obvious problems: * Overhead -> well, is it really more overhead than sending enough extra packets to make a queue grow? * Requires support from ALL routers -> right, but why not start to use it SOMEWHERE ... e.g. in support of one single specific Grid that is hosted by ISPs a, b and c? * Share my information??? Never!!! -> well, the capacity is just what you would get with packet pair, the traffic is just what you could measure by probing the network, a timestamp is not that secret, and the address may at least not be such a problem in a dedicated, specific scenario (Grid example above). It could perhaps also be taken care of by introducing other unique keys, like MPLS labels - something like that Obvious advantages: * A single packet does it all * No problem if the source system throughput is limited * No misinterpretations of, e.g., packet loss (corruption or congestion?), delay (link layer ARQ or congestion?) So, is it really such a bad idea? I think not! I believe that the controlled environment of single, well-defined Grid scenarios would be a very good starting point for this. For more information about PTP (papers, ns code etc.), please take a look at http://www.welzl.at/ptp Cheers, Michael _______________________________________________ IMRG mailing list IMRG@ietf.org https://www1.ietf.org/mailman/listinfo/imrg