From jtk at northwestern.edu Fri Oct 1 13:30:46 2004 From: jtk at northwestern.edu (John Kristoff) Date: Fri Oct 1 13:31:51 2004 Subject: [e2e] T/TCP usage Message-ID: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> After reviewing some of the Internet's protocol designs this afternoon, I was making my way through T/TCP and I began to think about some of the potential DoS vectors it could introduce. Apparently the potential for problems are well known. For example: I'm curious if T/TCP is actively in use or currently enabled by default in any stack. Though I suspect only the latter would be true for very specific turnkey systems or applications. Richard Stevens old T/TCP page indicates that at least at one time some sites were enabling it: I didn't find any evidence to indicate that anyone is using it today. Does anyone have information regarding current use or could someone summarize it's history? John From kostas at cs.sunysb.edu Fri Oct 1 13:48:28 2004 From: kostas at cs.sunysb.edu (Kostas Pentikousis) Date: Fri Oct 1 13:52:52 2004 Subject: [e2e] T/TCP usage In-Reply-To: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> References: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> Message-ID: On Fri, 1 Oct 2004, John Kristoff wrote: |I didn't find any evidence to indicate that anyone is using it today. We neither: K. Pentikousis and H. Badr, "Quantifying the deployment of TCP options - A comparative study", IEEE Communications Letters, 8(10), October 2004. Available from http://www.cs.stonybrook.edu/~kostas/art/ Best regards, Kostas __________________________________________________________________ Kostas Pentikousis www.cs.stonybrook.edu/~kostas From touch at ISI.EDU Fri Oct 1 14:37:14 2004 From: touch at ISI.EDU (Joe Touch) Date: Fri Oct 1 14:36:07 2004 Subject: [e2e] T/TCP usage In-Reply-To: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> References: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> Message-ID: <415DCE0A.4060006@isi.edu> John Kristoff wrote: > After reviewing some of the Internet's protocol designs this afternoon, > I was making my way through T/TCP and I began to think about some of the > potential DoS vectors it could introduce. Apparently the potential for > problems are well known. For example: > > > > I'm curious if T/TCP is actively in use or currently enabled by default > in any stack. Though I suspect only the latter would be true for very > specific turnkey systems or applications. > > Richard Stevens old T/TCP page indicates that at least at one time > some sites were enabling it: > > > > I didn't find any evidence to indicate that anyone is using it today. > Does anyone have information regarding current use or could someone > summarize it's history? > > John http://www.simpleweb.org/ietf/internetdrafts/complete/draft-duke-tcp-roadmap-00.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041001/5c7355c7/signature.bin From mycroft at netbsd.org Fri Oct 1 15:46:47 2004 From: mycroft at netbsd.org (Charles M. Hannum) Date: Fri Oct 1 15:47:53 2004 Subject: [e2e] T/TCP usage In-Reply-To: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> References: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> Message-ID: <200410012246.47945.mycroft@netbsd.org> On Friday 01 October 2004 20:30, John Kristoff wrote: > After reviewing some of the Internet's protocol designs this afternoon, > I was making my way through T/TCP and I began to think about some of the > potential DoS vectors it could introduce. Apparently the potential for > problems are well known. For example: > > Also see: http://midway.sourceforge.net/doc/ttcp-sec.txt That's a bit old, and I probably wouldn't write it quite the same today, but there it is. See sections 3 and 4, in particular, for comments about DoS attacks. Note that at least two implementations of T/TCP that got some use did not have a way for servers to selectively enable the use of TAO (or it had the wrong default; I forget), and that the hole mentioned in section 2 was in fact used to break into real servers, including at least one case where it was actually done through the rlogin service, as I specifically mentioned. In retrospect, I should have expanded more on my comment about it violating existing RFCs. In fact, we had to change the TCP processing in NetBSD to be compatible with T/TCP -- previously it would drop a SYN-data-ACK packet, as prescribed in RFC 793. I believe the same change had to be made in ka9q at the time. From lars.eggert at netlab.nec.de Sat Oct 2 02:45:22 2004 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Sat Oct 2 02:46:03 2004 Subject: [e2e] T/TCP usage In-Reply-To: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> References: <20041001153046.18bb694f@dhcp026232.ittns.northwestern.edu> Message-ID: <415E78B2.3080407@netlab.nec.de> John Kristoff wrote: > After reviewing some of the Internet's protocol designs this afternoon, > I was making my way through T/TCP and I began to think about some of the > potential DoS vectors it could introduce. Apparently the potential for > problems are well known. For example: > > > > I'm curious if T/TCP is actively in use or currently enabled by default > in any stack. Though I suspect only the latter would be true for very > specific turnkey systems or applications. It's still in the FreeBSD code but disabled by default, and enabling it is incompatible with a number of other TCP extensions that are also in the code (I think SYN cookies was one.) The benefits of enabling it are low, because there don't seem to be any applications today that use the required socket API extensions. I used it as part of the Ensemble-TCP work at ISI, and still think it's a nice idea that with a little work could fit well into modern TCP stacks. Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3360 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041002/207afe4f/smime.bin From ramesh at usc.edu Fri Oct 1 15:35:42 2004 From: ramesh at usc.edu (Ramesh Govindan) Date: Sat Oct 2 08:49:31 2004 Subject: [e2e] Call for Papers: First IEEE International Workshop on Networking Meets Databases (NetDB) Message-ID: <415DDBBE.8080609@usc.edu> (Apologies if you receive multiple copies) CALL For PAPERS --------------- 1st IEEE International Workshop on Networking Meets Databases (NetDB) in cooperation with 21st IEEE Conference on Data Engineering (ICDE 2005) April 8th and 9th, 2005 National Center of Science Tokyo, Japan The First Workshop on Networking Meets Databases, NetDB, will bring together researchers in the networking and database communities to debate emerging research directions. We are witnessing the blurring of the traditional boundaries between these two disciplines, especially in the emerging areas of sensor and peer-to-peer networks. We believe time is ripe for these two communities to get together and discuss the common interests, share and exchange expertise and results, and appreciate each other's terminologies and contributions. The goal of this year's workshop is to promote discussion of ideas that will influence and foster continued research in the areas of sensor and peer-to-peer networks. The workshop will provide a venue for researchers to present new ideas that can significantly impact both communities and perhaps give birth to a new community in the long term. We encourage submissions in the areas of sensor and peer-to-peer networks across the broad range of networking and database research. Topics of interest include, but are by no means limited to: - Architectures for sensor and peer-to-peer databases - Applications of sensor and peer-to-peer databases - Data analysis for network traffic estimation and security - Data models, query models, and query languages for sensor and peer-to-peer networks - Data placement and storage in sensor and peer-to-peer networks - Query planning, execution, and optimization in sensor and peer-to-peer networks - Indexing, caching, and replication techniques for sensor and peer-to-peer networks - Scalable distributed data structures for data management in sensor and peer-to-peer networks - Workload characterization and performance evaluation for sensor and peer-to-peer networks - Dynamic schema integration in sensor and peer-to-peer networks - Self-* properties and emergent behavior in sensor and peer-to-peer networks - Transaction management for peer-to-peer networks - Data mining, data retrieval, and streaming in peer-to-peer systems The selection of NetDB papers will be based primarily on their potential to influence future research. This influence can be exercised in many ways, exemplified by but not limited to the following: - Describing a novel approach to an old problem that promises to influence future research - Describing a new problem that requires our attention - Articulating a new perspective about networking and databases - Debunking an old perspective about networking or databases Copies of the accepted papers will be made publicly available via the Web prior to the workshop. Proceedings will be made available as an IEEE formal electronic post-workshop proceeding, where the papers will be included in the digital library of IEEE CS. We are investigating a special issue of a journal to publish a selected set of accepted papers. **Important Dates - Submissions due: November 15, 2004 (10:00 pm Pacific, HARD) - Notification of acceptance: January 10, 2005 - Camera-ready copy due: February 4, 2005 - Workshop: April 8-9, 2005 **Invited Speaker: - Michael Franklin (UCB) **Program Committee Co-Chairs: - Ramesh Govindan (USC) - Cyrus Shahabi (USC) **Program Committee Members: Karl Aberer (EPFL) Divyakant Agrawal (UCSB) Gustavo Alonso (ETH) Philippe Bonnet (Diku, Copenhagen) John Byers (Boston Uiversity) Ugur Cetintemel (Brown University) Amr El Abbadi (UCSB) Steve Gribble (University of Washington) Wei Hong (Intel, Berkeley) Vana Kalogeraki (UC Riverside) Brad Karp (CMU) Sam Madden (MIT) Evaggelia Pitoura (University of Ioannina, Greece) Mema Roussopoulos (Harvard University) Scott Shenker (UCB, ICSI) Ouri E. Wolfson (University of Illinois at Chicago) Jim Xu (Georgia Tech) From iyengar at mail.eecis.udel.edu Fri Oct 8 12:53:22 2004 From: iyengar at mail.eecis.udel.edu (Janardhan Iyengar) Date: Fri Oct 8 12:56:42 2004 Subject: [e2e] Default rwin values Message-ID: Hi all, I am trying to find citable sources for default rwin values on different OSes. From what I've found, defaults of 8KB and 16KB are not as uncommon as I thought they were. So, 1. Can someone tell me current defaults on different OSes? (Maybe a citable source even?) 2. If default rwin values in use are indeed as low as 8 or 16KB, why is that so? Is it sufficient for the most part to have a 16KB rwin? Is kernel memory that hard to come by in times when system memory of 1/2 GB is not unreasonable? thanks! jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- From sudeepg at cse.iitb.ac.in Fri Oct 8 14:25:33 2004 From: sudeepg at cse.iitb.ac.in (Sudeep Goyal) Date: Fri Oct 8 14:20:40 2004 Subject: [e2e] End to end gurantees in MPLS network. In-Reply-To: References: Message-ID: Hi all, I am working on QoS architecture for MPLS and I need to provide "end-to-end" QoS guarantees (delay, jitter, latency) for different applications. Is anyone here aware of such work anywhere or doing smt related? Thanks a lot, Regards, Sudeep On Fri, 8 Oct 2004, Janardhan Iyengar wrote: > Hi all, > > I am trying to find citable sources for default rwin values on different > OSes. From what I've found, defaults of 8KB and 16KB are not as uncommon > as I thought they were. So, > > 1. Can someone tell me current defaults on different OSes? (Maybe a > citable source even?) > > 2. If default rwin values in use are indeed as low as 8 or 16KB, why is > that so? Is it sufficient for the most part to have a 16KB rwin? Is kernel > memory that hard to come by in times when system memory of 1/2 GB is not > unreasonable? > > thanks! > jana > > --------------------------------------------------------------- > Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar > Protocol Engineering Lab -- CIS -- University Of Delaware > --------------------------------------------------------------- > > -- When a great leader's work is done, people say "we did it ourselves". -Lao Tzu From claypool at cs.wpi.edu Fri Oct 8 14:41:04 2004 From: claypool at cs.wpi.edu (Mark Claypool) Date: Fri Oct 8 14:43:38 2004 Subject: [e2e] Default rwin values In-Reply-To: References: Message-ID: <16743.2416.69305.1528@saagar.wpi.edu> > I am trying to find citable sources for default rwin values on different > OSes. From what I've found, defaults of 8KB and 16KB are not as uncommon > as I thought they were. So, > > 1. Can someone tell me current defaults on different OSes? (Maybe a > citable source even?) We looked into this last year for our QFind paper (ref below). Recent versions of Microsoft Windows as well as Linux support TCP window scaling (RFC 1323), allowing the receiver advertised window to grow up to 1 Gbyte. For actual TCP receiver window settings, Windows 98 has a default of 8192 bytes, Windows 2000 has a default of 17520 bytes, Linux has a default of 65535 bytes, and Windows XP may have a window size of 17520, but it also has a mostly undocumented ability to scale the receiver window size dynamically. Hope this helps! Mark ------------------------------------------------------------------------ Mark Claypool CS Associate Professor claypool@cs.wpi.edu Worcester Polytechnic Institute http://www.cs.wpi.edu/~claypool/ Mark Claypool, Robert Kinicki, Mingzhe Li, James Nichols, and Huahui Wu. Inferring Queue Sizes in Access Networks by Active Measurement, In Proceedings of the 5th Passive and Active Measurement Workshop (PAM), Antibes Juan-les-Pins, France, April 2004. Online at: http://www.cs.wpi.edu/~claypool/papers/qfind/ From Venkata.Naidu at Marconi.com Mon Oct 11 06:42:30 2004 From: Venkata.Naidu at Marconi.com (Naidu, Venkata) Date: Mon Oct 11 06:43:52 2004 Subject: [e2e] End to end gurantees in MPLS network. Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F800013048@usvissfp01.win.marconi.com> Sudeep, I know of one (very old) draft on QoS using TE over MPLS: http://www.cse.ohio-state.edu/~jain/ietf/teanal.htm Though the simulation is not in a real network, the results and conclusion are applicable to end-to-end arguments. Venkata. -> -----Original Message----- -> From: end2end-interest-bounces@postel.org -> [mailto:end2end-interest-bounces@postel.org]On Behalf Of Sudeep Goyal -> Sent: Friday, October 08, 2004 5:26 PM -> To: Janardhan Iyengar -> Cc: end2end-interest@postel.org -> Subject: [e2e] End to end gurantees in MPLS network. -> -> -> Hi all, -> -> I am working on QoS architecture for MPLS and I need to provide -> "end-to-end" QoS guarantees (delay, jitter, latency) for -> different applications. -> Is anyone here aware of such work anywhere or doing smt related? -> -> Thanks a lot, -> -> Regards, -> Sudeep -> -> -> -> On Fri, 8 Oct 2004, Janardhan Iyengar wrote: -> -> > Hi all, -> > -> > I am trying to find citable sources for default rwin -> values on different -> > OSes. From what I've found, defaults of 8KB and 16KB are -> not as uncommon -> > as I thought they were. So, -> > -> > 1. Can someone tell me current defaults on different OSes? (Maybe a -> > citable source even?) -> > -> > 2. If default rwin values in use are indeed as low as 8 or -> 16KB, why is -> > that so? Is it sufficient for the most part to have a 16KB -> rwin? Is kernel -> > memory that hard to come by in times when system memory of -> 1/2 GB is not -> > unreasonable? -> > -> > thanks! -> > jana -> > -> > --------------------------------------------------------------- -> > Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar -> > Protocol Engineering Lab -- CIS -- University Of Delaware -> > --------------------------------------------------------------- -> > -> > -> -> -- -> -> When a great leader's work is done, people say "we did it ourselves". -> -Lao Tzu -> From mallman at icir.org Mon Oct 11 08:27:51 2004 From: mallman at icir.org (Mark Allman) Date: Mon Oct 11 08:28:52 2004 Subject: [e2e] Default rwin values In-Reply-To: Message-ID: <20041011152751.35AB277AFEB@guns.icir.org> > I am trying to find citable sources for default rwin values on > different OSes. From what I've found, defaults of 8KB and 16KB are not > as uncommon as I thought they were. So, > > 1. Can someone tell me current defaults on different OSes? (Maybe a > citable source even?) > > 2. If default rwin values in use are indeed as low as 8 or 16KB, why is > that so? Is it sufficient for the most part to have a 16KB rwin? Is > kernel memory that hard to come by in times when system memory of 1/2 > GB is not unreasonable? We didn't try to break things out by OS, but there is a distribution of advertised window values observed in clients that hit our web server in: Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. May 2004. http://www.icir.org/mallman/papers/tcp-evo-submit.ps (See figure 6.) A note: if you compare this with results of a similar analysis around 2000 (found in the following paper) you'll see that advertised windows are increasing. It seems to me this likely means that *default* advertised windows are increasing --- a Good Thing. Mark Allman. A Web Server's View of the Transport Layer. ACM Computer Communication Review, 30(5), October 2000. http://www.icir.org/mallman/papers/webobs-ccr.ps allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041011/66f4d4bb/attachment.bin From helbakou at nortelnetworks.com Tue Oct 12 22:13:47 2004 From: helbakou at nortelnetworks.com (Hesham Elbakoury) Date: Tue Oct 12 22:15:03 2004 Subject: [e2e] IP Secure Mobility Message-ID: <0A11633F61BD9F40B43ABCC694004F9307F2B1F1@zsc3c026.us.nortel.com> I would appreciate if you can point me to recent research in the area of secure IP mobility. Thanks Hesham -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041012/0c8266d9/attachment.html From mrz2003 at tom.com Tue Oct 12 20:01:48 2004 From: mrz2003 at tom.com (Julian) Date: Wed Oct 13 11:38:21 2004 Subject: [e2e] Is there any annual conference of heterogeneous netowrks? Message-ID: <200410130303.i9D33OJ16474@boreas.isi.edu> Hello , Do you know? Thanks! Best regards, Julian Tsinghua Univ. mrz2003@tom.com From qiw3 at lehigh.edu Wed Oct 13 17:32:24 2004 From: qiw3 at lehigh.edu (qiw3@lehigh.edu) Date: Wed Oct 13 17:32:53 2004 Subject: [e2e] MRTG data at Berkeley In-Reply-To: <200410131900.i9DJ03J29001@boreas.isi.edu> References: <200410131900.i9DJ03J29001@boreas.isi.edu> Message-ID: <1097713944.416dc9180dd61@IMP.Lehigh.EDU> Dear all: I am working on network bandwidth measurement and would like to know how to get real time MRTG data log of Berkeley's campus network. We have collected Lehigh's campus network MRTG data (requires an Lehigh account to access) and the Internet-2 MRTG data (free online at internet-2). In order to get the end- to-end MRTG information, Berkeley's MRTG is highly desired. We have an collaborator at Berkeley but don't know where to find the data. If MRTG is accessable to an Berkeley's account, we really appreciate if anyone can tell us how to find the data. Thanks, Qiang Wang Dept. of Computer Science and Engineering Lehigh University ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From bmanning at vacation.karoshi.com Wed Oct 13 18:30:54 2004 From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com) Date: Wed Oct 13 18:31:51 2004 Subject: [e2e] MRTG data at Berkeley In-Reply-To: <1097713944.416dc9180dd61@IMP.Lehigh.EDU> References: <200410131900.i9DJ03J29001@boreas.isi.edu> <1097713944.416dc9180dd61@IMP.Lehigh.EDU> Message-ID: <20041014013054.GA5302@vacation.karoshi.com.> suggest you direct your query to the UCB campus networking staff. --bill On Wed, Oct 13, 2004 at 08:32:24PM -0400, qiw3@lehigh.edu wrote: > Dear all: > I am working on network bandwidth measurement and would like to know how to > get real time MRTG data log of Berkeley's campus network. We have collected > Lehigh's campus network MRTG data (requires an Lehigh account to access) and > the Internet-2 MRTG data (free online at internet-2). In order to get the end- > to-end MRTG information, Berkeley's MRTG is highly desired. We have an > collaborator at Berkeley but don't know where to find the data. If MRTG is > accessable to an Berkeley's account, we really appreciate if anyone can tell > us how to find the data. > > Thanks, > > Qiang Wang > > Dept. of Computer Science and Engineering > Lehigh University > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ From lindahl at berkeley.edu Thu Oct 14 00:25:23 2004 From: lindahl at berkeley.edu (ken lindahl) Date: Thu Oct 14 00:28:56 2004 Subject: [e2e] MRTG data at Berkeley Message-ID: <6.0.1.1.2.20041014002509.031ab000@calmail.berkeley.edu> hi Qiang, you can view the graphs of berkeley's data at http://cricket.berkeley.edu (we are also an NLANR AMP site, if that's of any interest: http://watt.nlanr.net/active/amp-ucb/HPC/body.html ) if you're requesting access to the raw data, please contact me offlist, and we'll see what sort of arrangements we can make. thanks, ken lindahl uc berkeley At 05:32 PM 10/13/2004, qiw3@lehigh.edu wrote: >Dear all: >I am working on network bandwidth measurement and would like to know how to >get real time MRTG data log of Berkeley's campus network. We have collected >Lehigh's campus network MRTG data (requires an Lehigh account to access) and >the Internet-2 MRTG data (free online at internet-2). In order to get the end- >to-end MRTG information, Berkeley's MRTG is highly desired. We have an >collaborator at Berkeley but don't know where to find the data. If MRTG is >accessable to an Berkeley's account, we really appreciate if anyone can tell >us how to find the data. > >Thanks, > >Qiang Wang > >Dept. of Computer Science and Engineering >Lehigh University > >------------------------------------------------- >This mail sent through IMP: http://horde.org/imp/ From qiw3 at lehigh.edu Thu Oct 14 02:14:05 2004 From: qiw3 at lehigh.edu (qiw3@lehigh.edu) Date: Thu Oct 14 02:15:11 2004 Subject: [e2e] MRTG data at Berkeley In-Reply-To: <6.0.1.1.2.20041013235254.03239e28@calmail.berkeley.edu> References: <200410131900.i9DJ03J29001@boreas.isi.edu> <1097713944.416dc9180dd61@IMP.Lehigh.EDU> <6.0.1.1.2.20041013235254.03239e28@calmail.berkeley.edu> Message-ID: <1097745245.416e435d904f8@IMP.Lehigh.EDU> It is truly wonderful to receive so many helps within few hours of my request. Special thanks go to Bill, Randy, Mark, Alex, and Ken!!! I will discuss with Ken offlist. Some information on my project: I am working on an available bandwidth measurement tool using active probing. Our tool is called FEAT (FishEye Available bandwidth Tool). It is similar to pathChirp [Ribeiro 2003] in a sense that FEAT sends a probe stream covering a range of packet rate. However, the stream pattern in FEAT is different and a ?fisheye? effect of the packet stream should improve the measurement accuracy (to be tested on Internet paths). FEAT is a part of AwareWare middleware (https://www.fastlane.nsf.gov/servlet/showaward?award=0438300) I proposed in my dissertation research. To test FEAT on real Internet, I follow the MRTG test method discussed in spruce [Strauss 2003]. I test the tool from one machine at Berkeley to another machine at Lehigh, and record the measured end-to-end available bandwidth. In order to check our measured results against the ?true values?, MRTG validation requires access to MRTG raw data from *all links* of a path, and the capacity of each link. The end-to-end available bandwidth is calculated as the minimum of (capacity ? cross traffic) of all links along the path. Although 5 minutes resolution is low, the MRTG data so far is the most accurate way to validate the output of an avi-bw tool. The path (16 hops) from Lehigh to Berkeley goes from Lehigh campus network -> magpi.net->Abilene->cenic->Berkeley campus (the result from traceroute). If I can collect MRTG data for Berkeley campus, there are still few links missing, especially one link from Lehigh to magpi backbone, the link from magpi backbone to Abilene backbone, and 3 links on cenic. Although these missing links are all 1G capacities, they should have less or no impact on final avi- bw calculation, until checked carefully, I am not at ease to draw conclusions. Available bandwidth measurement should be an interesting topic for the end2end community. From my experience, the difficult (and time consuming) thing for tool validation on real Internet is to find appropriate remote hosts and collect ?true value? data (e.g. MRTG data). It may need a large collaboration in our community. Any one try to discuss this on PAM 2005 (http://www.pam2005.org/)? [Ribeiro 2003] V. Ribeiro, R. Riedi, R. Baraniuk, J. Navratil, and L. Cottrell. pathChirp: Efficient available bandwidth estimation for network paths. In Passive and Active Measurement Workshop, (April 2003). [Strauss 2003] Jacob Strauss, Dina Katabi, Frans Kaashoek. A measurement study of available bandwidth estimation tools. In Proceedings of the 2003 ACM SIGCOMM conference on Internet measurement, pp. 39-44, USA , Oct. 27 - 29, 2003. Thanks, Qiang Wang Dept. of Computer Science and Engineering Lehigh University Quoting ken lindahl : > hi Qiang, > > you can view the graphs of berkeley's data at > http://cricket.berkeley.edu > > (we are also an NLANR AMP site, if that's of any interest: > http://watt.nlanr.net/active/amp-ucb/HPC/body.html ) > > if you're requesting access to the raw data, please contact me > offlist, and we'll see what sort of arrangements we can make. > > thanks, > ken lindahl > uc berkeley > > At 05:32 PM 10/13/2004, qiw3@lehigh.edu wrote: > >Dear all: > >I am working on network bandwidth measurement and would like to know how to > > >get real time MRTG data log of Berkeley's campus network. We have collected > > >Lehigh's campus network MRTG data (requires an Lehigh account to access) and > > >the Internet-2 MRTG data (free online at internet-2). In order to get the > end- > >to-end MRTG information, Berkeley's MRTG is highly desired. We have an > >collaborator at Berkeley but don't know where to find the data. If MRTG is > >accessable to an Berkeley's account, we really appreciate if anyone can tell > > >us how to find the data. > > > >Thanks, > > > >Qiang Wang > > > >Dept. of Computer Science and Engineering > >Lehigh University > > > >------------------------------------------------- > >This mail sent through IMP: http://horde.org/imp/ > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From jshen_cad at yahoo.com.cn Thu Oct 14 03:36:30 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Thu Oct 14 03:36:56 2004 Subject: [e2e] MRTG data at Berkeley In-Reply-To: <1097745245.416e435d904f8@IMP.Lehigh.EDU> Message-ID: <20041014103630.30351.qmail@web15407.mail.cnb.yahoo.com> Hi, > The path (16 hops) from Lehigh to Berkeley goes from > Lehigh campus network -> > magpi.net->Abilene->cenic->Berkeley campus (the > result from traceroute). If I I don't know much about bandwidth utilization in US, but in China the bottleneck usually exists with links between ISP, e.g. ChinaTelecom & SprintLink, Chinatelecom & ChinaUnicom, ChinaTelecom & CERN. Within ISP, links to IXP usually experience high load. And, do you think a 5min sampling interval raw data is enough for available BW estimation? Jing Shen ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From jshen_cad at yahoo.com.cn Thu Oct 14 03:59:19 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Thu Oct 14 03:59:53 2004 Subject: [e2e] Question on TCP throughput and host's access speed Message-ID: <20041014105919.31249.qmail@web15407.mail.cnb.yahoo.com> Hi, I met a question with upload speed and network access speed. We use two leased line from ISP. One is a 2Mbps ADSL the other is a 100Mbps fiber link. Usually it is required to upload files to a server in Japan. To my understanding, upload speed should be higher if leased line is used. On the contrary, upload using ADSL is a little faster than using Fiber link, while packet loss and retransmission happen more frequently when I use Fiber link. Analizing routing path between our computer and server in jappan, we found there is no difference between ADSL access and Fiber Link beside the access method. If I do not make a mistake, TCP throughtput is determined by bottleneck bandwidth, RTT and its fluctuation. So, although ADSL's speed is much slower than fibre, the upload speed should be similar when bottleneck is the same, or ADSL should be slower. Why the phenomon comes up? regards Jing Shen _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From ASCPFu at ntu.edu.sg Thu Oct 14 05:34:27 2004 From: ASCPFu at ntu.edu.sg (Fu Cheng Peng, Franklin) Date: Thu Oct 14 05:35:00 2004 Subject: [e2e] Question on TCP throughput and host's access speed Message-ID: <7CD06E15ADF4104A9F2E4DC2DE678F89010D11C8@EXCHANGE21.staff.main.ntu.edu.sg> This is interested issue. Basically, the uplink speed of ADSL is quite lower than the down link speed. Therefore, intuitively it should be quite slower than the fiber link if all other considtions are same. You may need double check where is the actual bottleneck of actual bandwidth. Perhaps you can check by uploading a file to your client being attached to the fiber link from ADSL client, and vice versa. Another reason may be due to the asymmetry of data path and acks path. -Franklin ==================================== Dr. Fu Cheng Peng, Franklin Asst Professor School of Computer Engineering Nanyang Technological University, Singapore 639798 Tel: (65) 6790-4287 Fax: (65) 6792-6559 www.ntu.edu.sg/home/ascpfu ==================================== > -----Original Message----- > From: end2end-interest-bounces@postel.org > [mailto:end2end-interest-bounces@postel.org] On Behalf Of Jing Shen > Sent: 2004Äê10ÔÂ14ÈÕ 18:59 > To: end-to-end list > Subject: [e2e] Question on TCP throughput and host's access speed > > > Hi, > > I met a question with upload speed and network access > speed. > > We use two leased line from ISP. One is a 2Mbps ADSL > the other is a 100Mbps fiber link. Usually it is > required to upload files to a server in Japan. > To my understanding, upload speed should be higher if > leased line is used. On the contrary, upload using > ADSL is a little faster than using Fiber link, while > packet loss and retransmission happen more frequently > when I use Fiber link. Analizing routing path between > our computer and server in jappan, we found there is > no difference between ADSL access and Fiber Link > beside the access method. > > If I do not make a mistake, TCP throughtput is > determined by bottleneck bandwidth, RTT and its > fluctuation. So, although ADSL's speed is much slower > than fibre, the upload speed should be similar when > bottleneck is the same, or ADSL should be slower. > > Why the phenomon comes up? > > > regards > > Jing Shen > > > > _________________________________________________________ > Do You Yahoo!? > 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà > http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.y isou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From dennis at bbn.com Thu Oct 14 05:54:06 2004 From: dennis at bbn.com (Dennis Rockwell) Date: Thu Oct 14 05:55:53 2004 Subject: [e2e] Question on TCP throughput and host's access speed In-Reply-To: Message from Jing Shen <20041014105919.31249.qmail@web15407.mail.cnb.yahoo.com> . Message-ID: <5584.1097758446@bbn.com> On 14 Oct, Jing Shen wrote: > We use two leased line from ISP. One is a 2Mbps ADSL > the other is a 100Mbps fiber link. [ ... ] > packet loss and retransmission happen more frequently > when I use Fiber link. Retransmissions kill TCP throughput rather thoroughly, especially in long (high delay) paths. > Analizing routing path between > our computer and server in jappan, we found there is > no difference between ADSL access and Fiber Link > beside the access method. What you have discovered is that your 2Mbps link is not the bottleneck; that lies elsewhere in your network path. The extra bandwidth of the fiber link cannot help this application. Good luck! Dennis From liww at hnu.cn Fri Oct 15 07:08:11 2004 From: liww at hnu.cn (liww) Date: Fri Oct 15 07:03:58 2004 Subject: [e2e]where can i find an ip or host address list? Message-ID: <297846276.18963@hnu.cn> hi, Now I'm doing an experiment which needs to probe 100000 more or less hosts in the Internet via ICMP and TCP with slight loads. The goal of this experiment is to find the difference between ICMP and TCP when they are used to probe host connectivity.May be I can randomly generate the amount of IP address I needed. But considering there are a great deal of unused IP addresses in the IPv4 address space,the random approach may be less efficient.One better way is to find a list with addresses or hosts name real in use. Does any one have such an IP address or hosts list? or can direct me where can i get such a list? Thanks! liww -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041015/75251e8b/attachment.html From rja at extremenetworks.com Fri Oct 15 08:26:08 2004 From: rja at extremenetworks.com (RJ Atkinson) Date: Fri Oct 15 08:26:59 2004 Subject: [e2e]where can i find an ip or host address list? In-Reply-To: <297846276.18963@hnu.cn> References: <297846276.18963@hnu.cn> Message-ID: <89A92C60-1EBE-11D9-8149-000D93B505E6@extremenetworks.com> You need to get advance permission from the legitimate owner/operator of any host you might probe. To run a probe of someone else's system without specific advance permission could violate the law and is certainly anti-social behaviour. I would suggest you reconsider your experiment design and invent a different experiment design that does not require you to probe so many hosts -- and ideally a way that does not require you to probe any other people's hosts. On Oct 15, 2004, at 10:08, liww wrote: > Now I'm doing an experiment which needs to probe 100000 more or less > hosts in the Internet via ICMP and TCP with slight loads. The goal of > this experiment is to find the difference between ICMP and TCP when > they are used?to probe host connectivity.May be?I can randomly > generate the amount of IP address I needed. But considering there are > a great deal of unused IP addresses in the IPv4 address space,the > random approach may be less efficient.One better way is to find a list > with addresses or hosts name real in use. > Does any one have such an IP address or hosts list? or can direct me > where can i get such a list? > Thanks! > ? > liww From jshen_cad at yahoo.com.cn Thu Oct 14 19:15:33 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Fri Oct 15 08:27:33 2004 Subject: [e2e] Question on TCP throughput and host's access speed In-Reply-To: <000001c4b202$7c18df20$6e8944c6@telemuse.net> Message-ID: <20041015021533.71011.qmail@web15407.mail.cnb.yahoo.com> Hi, thanks for all your help. The bottleneck does not locate with access line but a link between China Telecom and Verio(Japan). To upload a file of 5MB, it takes 170seconds(average) for ADSL while 420seconds(average) for fiber. Asymetric route exists between our site and server in japan.To our measurement there is no packet loss between ADSL/Fiber and core router of our ISP, while point to point delay between our computer and ISP's core router differs a little (<0.2ms, fiber link is faster). But, what makes me confused is : if TCP modifies its sending window according to ACK received,and bottleneck link would not distinguish between ADSL subscribers and Fiber link subscribers, no matter how asymetric is routing path or how much difference between access line, TCP on both end should behave similar (?). Why there exist so much difference ? thanks Jing Shen --- Lynne Jolitz µÄÕýÎÄ£º > Dennis is correct. Here's a little story from a > manager of international datacenters in Japan and > the US to illustrate how complicated the issue can > become: > > "There was a weak laser in an inexpensive optical > ethernet LAN connection used to convey a WAN from > one floor of a datacenter in Ariake to the other, > resulting in a significant increase in bit error > rate. While the laser was within spec for the > product, the product was used on a fibre at the edge > of the distance of the link - but still also within > spec. > > The simplest thing to do was to replace it with an > optical ethernet WAN connection more suited to the > use. Unfortunately, the datacenter insisted that you > could only use this inadaquate connection to go > between floors. The rule could not be changed to > repair this situation. Everyone along the path > acknowledged the problem, as they all were blamed, > but still the rule 'could not be changed'. > > This problem impacted Japanese consumers using one > of the most heavily trafficed Japanese websites at > the time. The problem persisted for months until we > were able to consolodate on one floor only." (from > my book on datacenter management and operations). > > Regards, > Lynne. > > > -----Original Message----- > > From: end2end-interest-bounces@postel.org > > [mailto:end2end-interest-bounces@postel.org]On > Behalf Of Dennis Rockwell > > Sent: Thursday, October 14, 2004 5:54 AM > > To: Jing Shen > > Cc: end-to-end list > > Subject: Re: [e2e] Question on TCP throughput and > host's access speed > > > > > > On 14 Oct, Jing Shen wrote: > > > > > We use two leased line from ISP. One is a 2Mbps > ADSL > > > the other is a 100Mbps fiber link. [ ... ] > > > > > packet loss and retransmission happen more > frequently > > > when I use Fiber link. > > > > Retransmissions kill TCP throughput rather > thoroughly, > > especially in long (high delay) paths. > > > > > Analizing routing path between > > > our computer and server in jappan, we found > there is > > > no difference between ADSL access and Fiber Link > > > beside the access method. > > > > What you have discovered is that your 2Mbps link > is not the > > bottleneck; that lies elsewhere in your network > path. The > > extra bandwidth of the fiber link cannot help this > > application. > > > > Good luck! > > > > Dennis > > > > ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From weixl at caltech.edu Thu Oct 14 19:55:12 2004 From: weixl at caltech.edu (Xiaoliang (David) Wei) Date: Fri Oct 15 08:27:34 2004 Subject: [e2e] Question on TCP throughput and host's access speed References: <20041015021533.71011.qmail@web15407.mail.cnb.yahoo.com> Message-ID: <027001c4b262$63fa6570$df2dd783@seashadow> Hi Jing, > But, what makes me confused is : if TCP modifies its > sending window according to ACK received,and > bottleneck link would not distinguish between ADSL > subscribers and Fiber link subscribers, no matter how > asymetric is routing path or how much difference > between access line, TCP on both end should behave > similar (?). Why there exist so much difference ? If the return path suffers packet loss, there may be ack compression and introduce more bursty sending traffic, due to TCP window control. Then you may see packet loss (or NIC queue overflow) in your local machine -- before getting to the access point. And the buffer on the ADSL interface may be larger than the buffer on the fiber interface. If you are using Linux, it will be good to have a web100 patch to get some statistics. Then you will probably find more conclusive answers. -David From dga at lcs.mit.edu Fri Oct 15 09:09:00 2004 From: dga at lcs.mit.edu (David G. Andersen) Date: Fri Oct 15 09:11:06 2004 Subject: [e2e]where can i find an ip or host address list? In-Reply-To: <89A92C60-1EBE-11D9-8149-000D93B505E6@extremenetworks.com> References: <297846276.18963@hnu.cn> <89A92C60-1EBE-11D9-8149-000D93B505E6@extremenetworks.com> Message-ID: <20041015160900.GB13990@lcs.mit.edu> On Fri, Oct 15, 2004 at 11:26:08AM -0400, RJ Atkinson scribed: > > You need to get advance permission from the legitimate owner/operator > of any host you might probe. To run a probe of someone else's system > without > specific advance permission could violate the law and is certainly > anti-social > behaviour. IANAL, but court decisions in the US have generally said that pinging hosts isn't against the law. Lots of research projects do this all of the time. They often generate complaints, however, and it's best to take several steps to avoid stepping on people's toes. I'll send out the list I've compiled once I find it - totally hosed with the NSDI deadline right now. > I would suggest you reconsider your experiment design and invent a > different > experiment design that does not require you to probe so many hosts -- > and ideally > a way that does not require you to probe any other people's hosts. The fewer probes to random hosts, the better! One way to start with this experiment might be to compare all-pairs ICMP and TCP pings using Planetlab. It'll measure a large number of paths (on the order of a few thousand), and won't generate any complaints. If you need more detail, The next step would be to compare ICMP and TCP pings to port 80 on large web servers, which probably don't care about a little extra ICMP or TCP traffic. Only after that would I evaluate the need for probing 100,000 random hosts... -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ From rja at extremenetworks.com Fri Oct 15 09:21:28 2004 From: rja at extremenetworks.com (RJ Atkinson) Date: Fri Oct 15 09:21:58 2004 Subject: [e2e]where can i find an ip or host address list? In-Reply-To: <20041015160900.GB13990@lcs.mit.edu> References: <297846276.18963@hnu.cn> <89A92C60-1EBE-11D9-8149-000D93B505E6@extremenetworks.com> <20041015160900.GB13990@lcs.mit.edu> Message-ID: <44522300-1EC6-11D9-8149-000D93B505E6@extremenetworks.com> On Oct 15, 2004, at 12:09, David G. Andersen wrote: > On Fri, Oct 15, 2004 at 11:26:08AM -0400, RJ Atkinson scribed: >> >> You need to get advance permission from the legitimate owner/operator >> of any host you might probe. To run a probe of someone else's system >> without >> specific advance permission could violate the law and is certainly >> anti-social >> behaviour. > > IANAL, but court decisions in the US have generally said that > pinging hosts isn't against the law. Lots of research projects do > this all of the time. They often generate complaints, however, > and it's best to take several steps to avoid stepping on people's > toes. I'll send out the list I've compiled once I find it - totally > hosed with the NSDI deadline right now. David, There are court cases contrary to what you say, both in the US and overseas. Moreover, the correspondent is in China, not the US. Chinese law is quite unrelated to any US legal precedents that might exist in some US jurisdictions. And trying to establish a TCP connection is not the same as sending an ICMP Echo Request. I stand by my original comment *as I originally phrased it*. Ran From dmitri at cs.tamu.edu Fri Oct 15 11:51:11 2004 From: dmitri at cs.tamu.edu (Dmitri Loguinov) Date: Fri Oct 15 11:52:02 2004 Subject: Fw: [e2e]where can i find an ip or host address list? Message-ID: <010101c4b2e7$f05469f0$1996fa18@viper> Ran, Do you mind citing a court case where someone is convicted for pinging a host (or 100,000 of them for research purposes)? Dmitri ----- Original Message ----- From: RJ Atkinson To: David G. Andersen Cc: end2end-interest@postel.org Sent: Friday, October 15, 2004 11:21 AM Subject: Re: [e2e]where can i find an ip or host address list? On Oct 15, 2004, at 12:09, David G. Andersen wrote: > On Fri, Oct 15, 2004 at 11:26:08AM -0400, RJ Atkinson scribed: >> >> You need to get advance permission from the legitimate owner/operator >> of any host you might probe. To run a probe of someone else's system >> without >> specific advance permission could violate the law and is certainly >> anti-social >> behaviour. > > IANAL, but court decisions in the US have generally said that > pinging hosts isn't against the law. Lots of research projects do > this all of the time. They often generate complaints, however, > and it's best to take several steps to avoid stepping on people's > toes. I'll send out the list I've compiled once I find it - totally > hosed with the NSDI deadline right now. David, There are court cases contrary to what you say, both in the US and overseas. Moreover, the correspondent is in China, not the US. Chinese law is quite unrelated to any US legal precedents that might exist in some US jurisdictions. And trying to establish a TCP connection is not the same as sending an ICMP Echo Request. I stand by my original comment *as I originally phrased it*. Ran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041015/e759a074/attachment.html From marc.herbert at free.fr Fri Oct 15 13:18:26 2004 From: marc.herbert at free.fr (Marc Herbert) Date: Fri Oct 15 13:19:03 2004 Subject: [e2e] probing and laws (where can i find an ip or host address list?) In-Reply-To: <44522300-1EC6-11D9-8149-000D93B505E6@extremenetworks.com> References: <297846276.18963@hnu.cn> <89A92C60-1EBE-11D9-8149-000D93B505E6@extremenetworks.com> <20041015160900.GB13990@lcs.mit.edu> <44522300-1EC6-11D9-8149-000D93B505E6@extremenetworks.com> Message-ID: On Fri, 15 Oct 2004, RJ Atkinson wrote: > >> You need to get advance permission from the legitimate > >> owner/operator of any host you might probe. To run a probe of > >> someone else's system without specific advance permission could > >> violate the law and is certainly anti-social behaviour. > > > > IANAL, but court decisions in the US have generally said that > > pinging hosts isn't against the law. Lots of research projects do > > this all of the time. They often generate complaints, however, > > and it's best to take several steps to avoid stepping on people's > > toes. I'll send out the list I've compiled once I find it - totally > > hosed with the NSDI deadline right now. > There are court cases contrary to what you say, both in the US and > overseas. Moreover, the correspondent is in China, not the US. > Chinese law is quite unrelated to any US legal precedents that might > exist in some US jurisdictions. I find this discussion a bit unreal considering the amount of probes due to viruses (or whatever) I (we) receive per minute on my DSL line. Add to that the few hundreds spam messages received per day... I don't really have an opinion about probes and I will respect any "law" about it. But I tend to find a bit weird, funny and ultimately irrelevant any regulation massively ignored, violated and impossible to enforce in reality. I don't really see the point of having a "social behaviour" today when I have a look at the log of any DSL line. I think we will be dead before most zombie-PCs or their owners (who usually have a much more interesting real life than applying security patches) adopt a "social behaviour". Hopefully some enforcement _technique_ (and not only some hand-waving law) will help solve this issue much before that. Just for fun, Imagine a state with laws but without any police or justice... I am exaggerating of course (I won't deny court cases about probing do exist). But just a bit (compare numbers of cases and numbers of probes). At first I thought this rant (longer than initially planned) was off-topic. But finally I think it fits in some "end to end" topic not so badly. -- "Je n'ai fait cette lettre-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte." -- Blaise Pascal From ygu1 at cs.uic.edu Fri Oct 15 13:23:59 2004 From: ygu1 at cs.uic.edu (Yunhong Gu1) Date: Fri Oct 15 13:25:02 2004 Subject: [e2e] Question on TCP throughput and host's access speed In-Reply-To: <20041015021533.71011.qmail@web15407.mail.cnb.yahoo.com> References: <20041015021533.71011.qmail@web15407.mail.cnb.yahoo.com> Message-ID: > But, what makes me confused is : if TCP modifies its > sending window according to ACK received,and > bottleneck link would not distinguish between ADSL > subscribers and Fiber link subscribers, no matter how > asymetric is routing path or how much difference > between access line, TCP on both end should behave > similar (?). Why there exist so much difference ? > Jing, I think you can do some UDP benchmark testing along the links, since they are reserved by you or your lab. It is very likely that there are some problems in the fibre link. In addition, TCP's performance can also be affected by the buffer size in the routers. This could be one of the reasons of the different throughputs. Yunhong From ygu1 at cs.uic.edu Fri Oct 15 13:30:00 2004 From: ygu1 at cs.uic.edu (Yunhong Gu1) Date: Fri Oct 15 13:31:06 2004 Subject: [e2e]where can i find an ip or host address list? In-Reply-To: <297846276.18963@hnu.cn> References: <297846276.18963@hnu.cn> Message-ID: Maybe you can use a web crawler to retrieve valid IP addresses. It is reasonable to me that it should be ok to ping or start a TCP connection to those public web servers. Yunhong On Fri, 15 Oct 2004, liww wrote: > hi, > Now I'm doing an experiment which needs to probe 100000 more or less hosts in the Internet via ICMP and TCP with slight loads. The goal of this experiment is to find the difference between ICMP and TCP when they are used to probe host connectivity.May be I can randomly generate the amount of IP address I needed. But considering there are a great deal of unused IP addresses in the IPv4 address space,the random approach may be less efficient.One better way is to find a list with addresses or hosts name real in use. > Does any one have such an IP address or hosts list? or can direct me where can i get such a list? > Thanks! > > liww > From dga at lcs.mit.edu Fri Oct 15 13:47:27 2004 From: dga at lcs.mit.edu (David G. Andersen) Date: Fri Oct 15 13:47:59 2004 Subject: [e2e] probing and laws (where can i find an ip or host address list?) In-Reply-To: References: <297846276.18963@hnu.cn> <89A92C60-1EBE-11D9-8149-000D93B505E6@extremenetworks.com> <20041015160900.GB13990@lcs.mit.edu> <44522300-1EC6-11D9-8149-000D93B505E6@extremenetworks.com> Message-ID: <20041015204727.GP13990@lcs.mit.edu> On Fri, Oct 15, 2004 at 10:18:26PM +0200, Marc Herbert scribed: > > I don't really see the point of having a "social behaviour" today when > I have a look at the log of any DSL line. I think we will be dead > before most zombie-PCs or their owners (who usually have a much more > interesting real life than applying security patches) adopt a "social > behaviour". Hopefully some enforcement _technique_ (and not only some > hand-waving law) will help solve this issue much before that. As someone who runs a moderately large network testbed, I beg my users to exercise exactly that social behavior, because unrestrained probing generates a fairly large volume of complaints that I and the people who (generously and without compensation other than the occasional free beer) host my machines have to deal with. Idiot With Firewall syndrome is well known, and best avoided, if only to save yourself a lot of hassle. Just ask the planetlab folks how many machines have been shut down by well-intentioned admins. Even on a smaller testbed with very careful users, I get a complaint or two per month, and typically have a machine switched off a few times per year because someone saw a traceroute and decided it was a port scan with malicious intent. So please, exercise care when probing -- not because you're intruding on other people's networks, but because it'll save you and your admins a lot of pain. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ From randy at psg.com Fri Oct 15 14:13:12 2004 From: randy at psg.com (Randy Bush) Date: Fri Oct 15 14:14:00 2004 Subject: [e2e]where can i find an ip or host address list? References: <297846276.18963@hnu.cn> Message-ID: <16752.15720.413549.179722@ran.psg.com> fwiw, there was a bit of discussion of this on some place like nanog some months back. the part of the conclusion i remember is o for the probing ip address, the source of the packets o when i look it up in the rir databases, e.g., whois -h whois.arin.net o i should see a comment something like experiment in progress, see http://research.example.com/ that should keep the rir listed abuse contacts for your address space from getting a lot of email. they will still get the occasional rabid self-righteous rant, but we all get those anyway. of course, you will need to negotiate this with your local organization's network admins. but you should be working with them anyway, as they're the ones gonna be getting the email. randy From liww at hnu.cn Fri Oct 15 20:21:12 2004 From: liww at hnu.cn (liww) Date: Fri Oct 15 20:17:10 2004 Subject: [e2e]where can i find an ip or host address list? References: <297846276.18963@hnu.cn> <89A92C60-1EBE-11D9-8149-000D93B505E6@extremenetworks.com> <297853914.18968@hnu.cn> Message-ID: <297893853.27602@hnu.cn> To tell the truth, i'm not aware that my mail have lead to a discussion on law and social behavior. i will reevaluate my experiment late. but there still is a question bother me, how do the researchers, who conduct similar experiments such as Internet map discovery, Internet topology etc., resolve this law problem ? Liww ----- Original Message ----- From: "David G. Andersen" To: "RJ Atkinson" Cc: "liww" ; Sent: Saturday, October 16, 2004 12:09 AM Subject: Re: [e2e]where can i find an ip or host address list? > On Fri, Oct 15, 2004 at 11:26:08AM -0400, RJ Atkinson scribed: > > > > You need to get advance permission from the legitimate owner/operator > > of any host you might probe. To run a probe of someone else's system > > without > > specific advance permission could violate the law and is certainly > > anti-social > > behaviour. > > IANAL, but court decisions in the US have generally said that > pinging hosts isn't against the law. Lots of research projects do > this all of the time. They often generate complaints, however, > and it's best to take several steps to avoid stepping on people's > toes. I'll send out the list I've compiled once I find it - totally > hosed with the NSDI deadline right now. > > > I would suggest you reconsider your experiment design and invent a > > different > > experiment design that does not require you to probe so many hosts -- > > and ideally > > a way that does not require you to probe any other people's hosts. > > The fewer probes to random hosts, the better! One way to start > with this experiment might be to compare all-pairs ICMP and TCP > pings using Planetlab. It'll measure a large number of paths (on > the order of a few thousand), and won't generate any complaints. > If you need more detail, The next step would be to compare ICMP and > TCP pings to port 80 on large web servers, which probably don't > care about a little extra ICMP or TCP traffic. > > Only after that would I evaluate the need for probing 100,000 > random hosts... > > -Dave > > -- > work: dga@lcs.mit.edu me: dga@pobox.com > MIT Laboratory for Computer Science http://www.angio.net/ > > > > Powered by MessageSoft SMG > SPAM, virus-free and secure email > http://www.messagesoft.com > > From hassy617 at student.otago.ac.nz Fri Oct 15 21:16:06 2004 From: hassy617 at student.otago.ac.nz (Syed Hasan) Date: Fri Oct 15 21:17:02 2004 Subject: [e2e] Network level qos support for web services Message-ID: <1097900166.4170a0865f020@www.studentmail.otago.ac.nz> Dear all, QoS is an important issue for web services. The Internet still provides best effort service. Without qos support from the network (Internet)how web servicescan provide qos? Differentiated services (Diffserv) has been proved successful in providing better than best effor services in some large private networks. Although it is still unknown how it will deliver the same in the global Internet. For its successful large scale deployment in the global Internet diffserv research community will have to invent some mechanisms which will attract the companies that rely on the Internet for their critical business operation. With companies more and more doing business on the web, now comes the question of how diffserv can give better performance for their web services ? >From the beginning diffserv mechanisms (tagging, policing, scheduling) have been designed for long lived tcp flows like voice, video etc. How much diffserv is suited for short web traffic (flows that are less than 10KB)? How much a company which wants to reduce response tome for its web services can rely on diffserv? So does we need to tune diffserv for web services? If not then what is the solution for a company which wants better service for its critical web services? Faisal From Jon.Crowcroft at cl.cam.ac.uk Sat Oct 16 04:12:23 2004 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat Oct 16 04:13:08 2004 Subject: [e2e] probing and laws (where can i find an ip or host address list?) In-Reply-To: Message from Marc Herbert of "Fri, 15 Oct 2004 22:18:26 +0200." Message-ID: so we have been working with various folks to try to see if its possible to define a "code of practice" for large scale network measurements that involve active traffic personally, i dont give two hoots about the discussions in this forum about legality - believe me we talke to _lawyers_ (so did anyone who has in the last 5 or more years run large scale measurement experiments, and got cease and desist letters sent to their organisations boss by some legal nono in the "target" organisation typically semi-automatically triggered by poorly configured IDS, and often not even realising that there is an international dimension to the jurisdictional point (pretty amusing someone telling me in cambridge, running a ping from a planetlab in brasil, that I am "breaking laws in idaho" for example - so thats really going to affect me if I am a bad guy now isnt it?) but, if you run large scale experiments, you hit a much higher level of perfectly legitimate (correctly configured) IDS alarm levels to do with the traffic +pattern+ you create being anomalous, and often starting to ressemble some of the zombine exploit and other relatively low rate, but large address space scan behaviours that we are starting to udnerstand and program into our defenses. so it behoves us, as good network citezens to think up a way that we can continue to do live research on live networks - one STRONG argument in favour of this is that at the very least, we need to do it, just to TEST new distributed IDS algorithms! meanwhile the ideas we have are a sort of CERT model - a registry of _good guys_, where one lists the systems one is probing from, the algorithms used to do the probe and choose destinations, and a set of contacts for getting more details (including legal ones, as well as very rapid response for example to remove addresses of extra-sensitive sites from any possible target - this latter is vital as there is no one-size-fits-all rule, (see above just for jurisdiciton, but also policy, social behaviour, and so forth - sometimes just old IDSs that cannot be re-programmed etc etc) another track in this direction is to talk about ways to exchange data between the IDSs, so we can get a better global/distributed view of what is going on "out there" as this will also help figure out improving our defenses, but passively, rather than actively, therefore less annoying to over-senstive folks! (of course, the inter-IDS exchange traffic itself could itself be construed a problem by some people - sigh)... one _very important_ thing we were told by a LOT of ops people was have a whois entry that points at people AND a website with LOTS of contact info and descriptions of what your organisation does and why and who to reach for each type of thing....and have those people _all_ aware ahead of time that you are doing it.... even so, you will get a tour of interesting world wide socio-litiguous behavioural norms and exceptions beyond your wildest dreams so enjoy cheers j. its fun to exchange horror stories about the sorts of daft communications one does get from paranoid sys-admins and operators - my favourite recently was someone who told us to go away as we were breaking the misuse of computer law (a uk law) - he was in another country (not clear it applies, but not relevant), but most amusing he sent us all his log files to "prove" what we were doing including ps auxww listings from all his unix servers - had i been a bad guy, that might have been rather useful:-) - had i been his boss, it might have been a career limiting move... From dpreed at reed.com Sat Oct 16 10:50:03 2004 From: dpreed at reed.com (David P. Reed) Date: Sat Oct 16 10:53:05 2004 Subject: [e2e] Network level qos support for web services In-Reply-To: <1097900166.4170a0865f020@www.studentmail.otago.ac.nz> References: <1097900166.4170a0865f020@www.studentmail.otago.ac.nz> Message-ID: <41715F4B.90609@reed.com> Syed Hasan wrote: >So does we need to tune diffserv for web services? If not then what is the >solution for a company which wants better service for its critical web >services? > > Faisal - since actual "service quality" has very little to do with what the protocol community calls "QoS", it is my opinion that web services should look elsewhere than diffserv to obtain their service quality. QoS at the router level is a great "marketing" word, but frankly, stuff like ECN and traffic engineering are much bigger levers on the user experience. But to him who has only routers and algorithms to sell, every problem looks like a job for "diffserv". In other words, there is an end-to-end argument that suggests you start by looking at what the dominant factors in ensuring web services quality might be, rather than assuming it has something to do with the router layer. I personally think that tools for traffic engineering have a much bigger payoff - if network administrators and equipment managers can move the load around so buffers in routers never exceed an average of <1 packet for each outbound interface, you maximize the benefit you can achieve, leaving little for QoS mechanisms to do. If you must focus on critical vs. non-critical traffic, use 1 bit of high vs. low priority (which can be inserted at packet entry based on simple rules like iptables rules). The 80-20 rule suggests that any further efforts will have marginal returns at major costs, probably better spent on investing in fibers and switches to remove bottlenecks discovered by traffic engineering tools. Of course the router software suppliers don't want people to think this way, and the theory community needs optimization problems to publish about.... -------------- next part -------------- A non-text attachment was scrubbed... Name: dpreed.vcf Type: text/x-vcard Size: 113 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041016/1dcc7501/dpreed-0001.vcf From lars.eggert at netlab.nec.de Sun Oct 17 00:43:27 2004 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Sun Oct 17 00:44:07 2004 Subject: [e2e] Network level qos support for web services In-Reply-To: <41715F4B.90609@reed.com> References: <1097900166.4170a0865f020@www.studentmail.otago.ac.nz> <41715F4B.90609@reed.com> Message-ID: <4172229F.50907@netlab.nec.de> David P. Reed wrote: > Syed Hasan wrote: > >> So does we need to tune diffserv for web services? If not then what is >> the >> solution for a company which wants better service for its critical web >> services? >> > Faisal - since actual "service quality" has very little to do with what > the protocol community calls "QoS", it is my opinion that web services > should look elsewhere than diffserv to obtain their service quality. I agree. A number of year back, we showed that - depending on where your bottleneck resource is - you can often do effective "diffserv" at the application layer, i.e., inside a web server. Application-Level Differentiated Services for Web Servers. Lars Eggert and John Heidemann. World Wide Web Journal, Vol, 3, Issue 2, 1999, pp. 133-142. http://www.larseggert.de/papers/app-lvl-diff-serv.pdf Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3360 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041017/956d1e2d/smime.bin From kempf at docomolabs-usa.com Sun Oct 17 10:24:17 2004 From: kempf at docomolabs-usa.com (James Kempf) Date: Sun Oct 17 10:24:07 2004 Subject: [e2e] Network level qos support for web services References: <1097900166.4170a0865f020@www.studentmail.otago.ac.nz> Message-ID: <002b01c4b46e$241e6330$4a6015ac@dcml.docomolabsusa.com> > QoS is an important issue for web services. The Internet still provides > best effort service. Without qos support from the network (Internet)how > web servicescan provide qos? > I hear this statement constantly from people with experience in circuit-switched telephony, and I'm curious where the data is to back it up. In Japan, about 10% of the fixed wireless telephony customers use Internet telephony and, to my knowledge, none of the DSL or FTH providers there are using QoS. In the US, AT&T, Sprint, and other fixed line carriers, along with startups like Vonage are offering Internet telephony and they don't require QoS in order for you to get the service (and no DSL provider offers QoS, to my knowledge). If QoS is so necessary for real time services over the Internet, then maybe you can explain to my why all these customers are buying the service (and the companies involved are presumably making money) without it? A possible counter example, CableLabs ,deploys some kind of RSVP QoS on their IP over cable, but I am not sure how it is used and I don't believe it is required for VoIP. jak From michael.welzl at uibk.ac.at Sun Oct 17 12:41:09 2004 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Sun Oct 17 12:39:09 2004 Subject: [e2e] Network level qos support for web services References: <1097900166.4170a0865f020@www.studentmail.otago.ac.nz> Message-ID: <000d01c4b481$401ade20$0200a8c0@fun> Hi, > QoS is an important issue for web services. The Internet still provides > best effort service. Without qos support from the network (Internet)how > web servicescan provide qos? I also believe that "normal" web service apps are better served with an application level solution like the one Lars mentioned. Still, this brings about a question I'm interested in: Are there (applications using, requirements for, ...) web services out there which really DO require network QoS (i.e. have strict delay bounds, require throughput guarantees... something like this)? AFAIK, web services are mainly for business application, but I guess that the notion of "composed web services" can lead to quite a delay overhead - does anybody care? Cheers, Michael From huitema at windows.microsoft.com Sun Oct 17 15:44:58 2004 From: huitema at windows.microsoft.com (Christian Huitema) Date: Sun Oct 17 15:46:07 2004 Subject: [e2e] Network level qos support for web services Message-ID: > Are there (applications using, requirements for, ...) web services out > there which really DO require network QoS (i.e. have strict delay bounds, > require throughput guarantees... something like this)? In practice, there are three kinds of networks: those that have enough capacity for the desired application, those that don't, and those that are in between. QOS schemes are only useful in the latter case, when the network almost has enough capacity for the application's demand, but not quite. They are useless if the network is to narrow: no amount of QOS will enable HDTV on a narrowband modem line. They are also useless if the network has enough capacity, since they only serve there to make the network more complex. QOS is not the only possible response in the "in between" state. If the network has "almost enough capacity", one can generally redesign the application to consume slightly less resource, e.g. use more compression. If the application is valuable, there will be incentives to increase the network capacity so it will always work. The "in between" case is a transient state, and the domain of applicability of QOS solutions is very narrow. -- Christian Huitema From dga at lcs.mit.edu Sun Oct 17 17:38:46 2004 From: dga at lcs.mit.edu (David G. Andersen) Date: Sun Oct 17 17:39:10 2004 Subject: [e2e] Network level qos support for web services In-Reply-To: References: Message-ID: <20041018003846.GA38214@lcs.mit.edu> On Sun, Oct 17, 2004 at 03:44:58PM -0700, Christian Huitema scribed: > > QOS is not the only possible response in the "in between" state. If the > network has "almost enough capacity", one can generally redesign the > application to consume slightly less resource, e.g. use more > compression. If the application is valuable, there will be incentives to > increase the network capacity so it will always work. > > The "in between" case is a transient state, and the domain of > applicability of QOS solutions is very narrow. Except, perhaps, as a simple priority scheme at the end-user's border router, which _is_ often congested, but has sufficient capacity for the important thing. But this isn't a complex, high-falutin', sigcomm-worthy QoS. It's a rule or two that says "please prioritize my VOIP calls over my kazaa download, please." These latter rules can make a very big difference in end-user happiness---I experience it frequently, sharing my bandwidth with a measurement node and two network-using housemates. But one dummynet statement is generally enough to make all of our QoS problems go away. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ From michael.welzl at uibk.ac.at Sun Oct 17 22:53:39 2004 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Sun Oct 17 22:57:11 2004 Subject: [e2e] Network level qos support for web services In-Reply-To: <20041018003846.GA38214@lcs.mit.edu> References: <20041018003846.GA38214@lcs.mit.edu> Message-ID: <1098078819.4793.4.camel@lap10-c703.uibk.ac.at> Folks, These are interesting thoughts, and I agree with them. However, they don't answer my question at all. Forgive me for using the word "QoS" and let me rephrase my question: Are there (applications using, requirements for, ...) web services out there which have specific network requirements (i.e. have strict delay bounds, require throughput guarantees... something like this)? I'm interested in things from the web services community - I know that Grid computing is largely based upon web services these days, and yes, these folks do have their requirements. Cheers, Michael On Mon, 2004-10-18 at 02:38, David G. Andersen wrote: > On Sun, Oct 17, 2004 at 03:44:58PM -0700, Christian Huitema scribed: > > > > QOS is not the only possible response in the "in between" state. If the > > network has "almost enough capacity", one can generally redesign the > > application to consume slightly less resource, e.g. use more > > compression. If the application is valuable, there will be incentives to > > increase the network capacity so it will always work. > > > > The "in between" case is a transient state, and the domain of > > applicability of QOS solutions is very narrow. > > Except, perhaps, as a simple priority scheme at the end-user's > border router, which _is_ often congested, but has sufficient capacity > for the important thing. > > But this isn't a complex, high-falutin', sigcomm-worthy QoS. > It's a rule or two that says "please prioritize my VOIP calls > over my kazaa download, please." These latter rules can make > a very big difference in end-user happiness---I experience > it frequently, sharing my bandwidth with a measurement node and > two network-using housemates. But one dummynet statement is generally > enough to make all of our QoS problems go away. > > -Dave From sridhar.ramesh at gmail.com Sun Oct 17 23:05:02 2004 From: sridhar.ramesh at gmail.com (Sridhar Ramesh) Date: Sun Oct 17 23:06:10 2004 Subject: [e2e] Network level qos support for web services In-Reply-To: References: Message-ID: On Sun, 17 Oct 2004 15:44:58 -0700, Christian Huitema wrote: > > Are there (applications using, requirements for, ...) web services out > > there which really DO require network QoS (i.e. have strict delay > bounds, > > require throughput guarantees... something like this)? > > In practice, there are three kinds of networks: those that have enough > capacity for the desired application, those that don't, and those that > are in between. QOS schemes are only useful in the latter case, when the > network almost has enough capacity for the application's demand, but not > quite. They are useless if the network is to narrow: no amount of QOS > will enable HDTV on a narrowband modem line. They are also useless if > the network has enough capacity, since they only serve there to make the > network more complex. > > QOS is not the only possible response in the "in between" state. If the > network has "almost enough capacity", one can generally redesign the > application to consume slightly less resource, e.g. use more > compression. If the application is valuable, there will be incentives to > increase the network capacity so it will always work. > > The "in between" case is a transient state, and the domain of > applicability of QOS solutions is very narrow. > > -- Christian Huitema > I have a problem with the part "enough capacity for the application's demand". Applications like file transfer typically do not come with a fixed demand but try to fill out whatever the network gives them (being built over TCP which does its probing and flow control). By assigning their packets a lower priority than those of voice or video with which they may be sharing network resources, we could throttle them down when the higher priority apps are active, right ? Who really cares if the file download takes a couple of minutes longer because we were making a long distance VoIP call ? Regards, Sridhar From s.malik at tuhh.de Mon Oct 18 04:20:24 2004 From: s.malik at tuhh.de (Sireen Habib Malik) Date: Mon Oct 18 04:21:12 2004 Subject: [e2e] Question on TCP throughput and host's access speed Message-ID: <4173A6F8.3070201@tuhh.de> Hi Jing Shen, A possible cause might be that the bottleneck(s) in your path(s) might have different utilizations: high utilization would dilate the file sojourn time. Recall (FileSize/(Capacity * (1-Utilization)) from M/G/1-Processor Sharing model. Also, the aggregate traffic might have different correlation structures leading to different queuing delays and losses. Positive correlations build larger buffer occupancy leading to higher losses. Here is one reference on the relevant point: "Web Pages Sojourn Times in High Speed Networks" by Malik et. al., IEEE International Workshop on IP Operations and Managment-2004 (IPOM-2004), Beijing, China. -- SM From fahad.dogar at gmail.com Mon Oct 18 05:13:52 2004 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Mon Oct 18 05:14:11 2004 Subject: [e2e] SLA violation in RSVP Message-ID: I believe admission control is implemented in RSVP by only admitting flows whose bandwidth requirements are met by the network. I was wondering whether there is any mechanism in RSVP which could ensure that flows do not violate their agreed SLA's once they are admitted. For example, how does RSVP ensure that flows do not over-subscribe the bandwidth that has been reserved for them? Thanks in advance, Fahad From mwd24 at thompson.cl.cam.ac.uk Mon Oct 18 05:17:12 2004 From: mwd24 at thompson.cl.cam.ac.uk (Michael Dales) Date: Mon Oct 18 05:18:10 2004 Subject: [e2e] probing and laws (where can i find an ip or host address list?) In-Reply-To: References: Message-ID: A good summary of the sort of thing Jon was talking about can be found here: http://www.cl.cam.ac.uk/~tjd21/research-probes.html Perhaps this sort of things needs to be made into an RFC or somehow standardised. -- Michael Dales University of Cambridge Computer Laboratory http://www.cl.cam.ac.uk/~mwd24/ From braden at ISI.EDU Mon Oct 18 10:46:21 2004 From: braden at ISI.EDU (Bob Braden) Date: Mon Oct 18 10:47:18 2004 Subject: [e2e] SLA violation in RSVP Message-ID: <200410181746.KAA28640@gra.isi.edu> *> I believe admission control is implemented in RSVP by only admitting *> flows whose bandwidth requirements are met by the network. *> I was wondering whether there is any mechanism in RSVP which could *> ensure that flows do not violate their agreed SLA's once they are *> admitted. For example, how does RSVP ensure that flows do not *> over-subscribe the bandwidth that has been reserved for them? *> *> Thanks in advance, *> Fahad *> RSVP is [only] a signaling protocol. You are presumably asking a question about the service models of Integrated Service. Bob Braden From bmeandzija at packeteer.com Mon Oct 18 10:50:26 2004 From: bmeandzija at packeteer.com (Branislav Meandzija) Date: Mon Oct 18 10:51:17 2004 Subject: [e2e] Network level qos support for web services Message-ID: <616482A6F824904C8010A2B40CFAF0A766D28C@mailcup1.packeteer.com> It depends what you call QoS schemes. The kinds of things we've been doing for years now do their level 3/ level 4 magic especially on networks that do not have enough capacity (excuse the self-advertisement). Branislav > -----Original Message----- > From: end2end-interest-bounces@postel.org > [mailto:end2end-interest-bounces@postel.org]On Behalf Of Christian > Huitema > Sent: Sunday, October 17, 2004 3:45 PM > To: Michael Welzl; end-to-end list > Subject: RE: [e2e] Network level qos support for web services > > > > Are there (applications using, requirements for, ...) web > services out > > there which really DO require network QoS (i.e. have strict delay > bounds, > > require throughput guarantees... something like this)? > > In practice, there are three kinds of networks: those that have enough > capacity for the desired application, those that don't, and those that > are in between. QOS schemes are only useful in the latter > case, when the > network almost has enough capacity for the application's > demand, but not > quite. They are useless if the network is to narrow: no amount of QOS > will enable HDTV on a narrowband modem line. They are also useless if > the network has enough capacity, since they only serve there > to make the > network more complex. > > QOS is not the only possible response in the "in between" > state. If the > network has "almost enough capacity", one can generally redesign the > application to consume slightly less resource, e.g. use more > compression. If the application is valuable, there will be > incentives to > increase the network capacity so it will always work. > > The "in between" case is a transient state, and the domain of > applicability of QOS solutions is very narrow. > > -- Christian Huitema > From algold at rnp.br Mon Oct 18 12:40:24 2004 From: algold at rnp.br (Alexandre L. Grojsgold) Date: Mon Oct 18 12:41:14 2004 Subject: [e2e] Network level qos support for web services In-Reply-To: References: Message-ID: On Mon, 18 Oct 2004, Sridhar Ramesh wrote: > > I have a problem with the part "enough capacity for the application's > demand". Applications like file transfer typically do not come with a > fixed demand but try to fill out whatever the network gives them > (being built over TCP which does its probing and flow control). > By assigning their packets a lower priority than those of voice > or video with which they may be sharing network resources, we > could throttle them down when the higher priority apps are active, right ? > Who really cares if the file download takes a couple of minutes > longer because we were making a long distance VoIP call ? > > Regards, > Sridhar > ... and I have a problem with "who really cares". I care. If there are enough users willing to make phone calls over IP, getting priority over my file transfer, it may take much much longer. Alexandre. From craig at aland.bbn.com Mon Oct 18 13:10:43 2004 From: craig at aland.bbn.com (Craig Partridge) Date: Mon Oct 18 13:11:16 2004 Subject: [e2e] explicit transport notification paper Message-ID: <20041018201044.F41551AB@aland.bbn.com> Rajesh Krishnan, James P.G. Sterbenz, Wesley M. Eddy, Craig Partridge and Mark Allman, "Explicit transport error notification (ETEN) for error-prone wireless and satellite networks" in Computer Networks, Volume 46, Issue 3, 22 October 2004, Pages 343-362. http://www.icir.org/mallman/papers/eten-comnet.ps Some members of this list have heard one or the other of the authors of this paper talk about some of the results. Speaking purely for myself, I think the most important contribution in the paper is to place some bounds on how well TCP can recover from error-related loss in a perfect information environment (where TCP knows immediately when an error occurs anywhere in the path). It sets an upper bound on how well one can do and that's a useful bound to know. Craig From fahad.dogar at gmail.com Wed Oct 20 00:12:05 2004 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Wed Oct 20 00:12:21 2004 Subject: [e2e] Admission Control and Policing in MPLS Message-ID: Hi, I would like to know the mechanism employed in MPLS networks for admission control and the process of subsequently policing the flow in order to ensure that it does not violate the SLA. Any help or pointers to any standardized requirements would be greatly appreciated. Thanks in advance, Fahad From ssuryaputra at HatterasNetworks.com Wed Oct 20 06:24:39 2004 From: ssuryaputra at HatterasNetworks.com (Stephen Suryaputra) Date: Wed Oct 20 06:26:29 2004 Subject: [e2e] Admission Control and Policing in MPLS Message-ID: <8052E2EA753D144EB906B7A7AA399714022A06D1@mailserv.hatteras.com> Fahad, I don't think admission control is standardized, even for ATM. What I meant by admission here is the decision process on accept/reject the flow during signaling phase (or provisioning). For policing, it can be done by using single-rate or dual-rate three color marker (RFC 2697 and 2698) that are defined for diffserv. Since mpls edge device typically supports diffserv, these policing mechanisms are pretty common. Hope this helps, -----Original Message----- From: end2end-interest-bounces@postel.org [mailto:end2end-interest-bounces@postel.org]On Behalf Of Fahad Dogar Sent: Wednesday, October 20, 2004 3:12 AM To: end2end-interest@postel.org Subject: [e2e] Admission Control and Policing in MPLS Hi, I would like to know the mechanism employed in MPLS networks for admission control and the process of subsequently policing the flow in order to ensure that it does not violate the SLA. Any help or pointers to any standardized requirements would be greatly appreciated. Thanks in advance, Fahad From tphelan at sonusnet.com Wed Oct 20 06:52:02 2004 From: tphelan at sonusnet.com (Phelan, Tom) Date: Wed Oct 20 06:52:24 2004 Subject: [e2e] Admission Control and Policing in MPLS Message-ID: Hi Fahad, There is a recently published implementation agreement from the MPLS Forum (an industry consortium advancing MPLS) that deals with admission control for MPLS networks. MPLS Proxy Admission Control is defined in the Forum's 6.0.0 (provisioning and operational aspects) and 7.0.0 (protocol) IAs. They're available at http://www.mplsforum.org/tech/mpls-proxy-admission-control-definition-ia.pdf and http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf. Tom Phelan > -----Original Message----- > From: Fahad Dogar [mailto:fahad.dogar@gmail.com] > Sent: Wednesday, October 20, 2004 3:12 AM > To: end2end-interest@postel.org > Subject: [e2e] Admission Control and Policing in MPLS > > > Hi, > > I would like to know the mechanism employed in MPLS networks for > admission control and the process of subsequently policing the flow in > order to ensure that it does not violate the SLA. > > Any help or pointers to any standardized requirements would be greatly > appreciated. > > Thanks in advance, > Fahad > From emmanuel.papirakis at cilys.com Thu Oct 21 09:50:55 2004 From: emmanuel.papirakis at cilys.com (Emmanuel Papirakis) Date: Thu Oct 21 09:51:30 2004 Subject: [e2e] Rateless Internet Message-ID: <4177E8EF.4010202@cilys.com> According to: http://www.rateless.com.nyud.net:8090/rcx1.html Universal Congestion Control is an algorithm for transmission speed control. It is based on a simple and clean idea. Speed is varied in a wave-like fashion. The top of the wave achieves near-optimal throughput, while the bottom is low enough to let coexisting protocols like TCP smoothly receive a fair share of bandwidth. The time lengths of the peaks and troughs can be adjusted parametrically to achieve customized levels of fairness between Rateless Internet and TCP. Is it really possible to acheive TCP friendliness through such techniques ? Emmanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041021/eebcce76/attachment.html From ssuryaputra at HatterasNetworks.com Fri Oct 22 17:11:30 2004 From: ssuryaputra at HatterasNetworks.com (Stephen Suryaputra) Date: Fri Oct 22 17:12:35 2004 Subject: [e2e] Network level qos support for web services Message-ID: <8052E2EA753D144EB906B7A7AA399714022A06D7@mailserv.hatteras.com> Hi, Is there any latency requirements for transactions? I assume that web services are mainly for that, not that I know anything about web services. Pardon if I made a wrong assessment. Cheers, -----Original Message----- From: end2end-interest-bounces@postel.org on behalf of Syed Hasan Sent: Sat 10/16/2004 12:16 AM To: end-to-end list Cc: Subject: [e2e] Network level qos support for web services Dear all, QoS is an important issue for web services. The Internet still provides best effort service. Without qos support from the network (Internet)how web servicescan provide qos? Differentiated services (Diffserv) has been proved successful in providing better than best effor services in some large private networks. Although it is still unknown how it will deliver the same in the global Internet. For its successful large scale deployment in the global Internet diffserv research community will have to invent some mechanisms which will attract the companies that rely on the Internet for their critical business operation. With companies more and more doing business on the web, now comes the question of how diffserv can give better performance for their web services ? >From the beginning diffserv mechanisms (tagging, policing, scheduling) have been designed for long lived tcp flows like voice, video etc. How much diffserv is suited for short web traffic (flows that are less than 10KB)? How much a company which wants to reduce response tome for its web services can rely on diffserv? So does we need to tune diffserv for web services? If not then what is the solution for a company which wants better service for its critical web services? Faisal From chengjin at cs.caltech.edu Wed Oct 27 21:18:24 2004 From: chengjin at cs.caltech.edu (Cheng Jin) Date: Thu Oct 28 13:13:49 2004 Subject: [e2e] Extended CFP for PLFDnet 2005 Message-ID: +---------------------------+ | | | Extended deadline : Nov 3 | | | +---------------------------+ Call For Papers =============== Third International Workshop on Protocols for Fast Long-Distance Networks PFLDnet2005 ------------------------------------------------------------------------- http://www.ens-lyon.fr/LIP/RESO/pfldnet2005 pfldnet2005@ens-lyon.fr ------------------------------------------------------------------------- Fast long-distance networks (i.e., networks operating at 622 Mbit/s, 2.5 Gbit/s, or 10 Gbit/s and spanning several countries or states) are now becoming commonplace. More and more researchers now routinely transfer between 10 GB and multi-TB datasets over gigabit networks. Application domains for such massive transfers include data-intensive Grids (e.g., in Particle Physics, Earth Observation, Bio informatics, and Radio Astronomy), database mirroring for Web sites (e.g., in e-commerce), and push-based Web cache updates. Although the network infrastructure is now in place, or will soon be, the transport and application protocols available to date perform rather poorly over such networks. Current versions of TCP, for instance, recover very slowly from packet loss when the RTT and the link capacity are large, thus requiring a large congestion window for high throughput. A number of research teams have begun investigating these protocol issues. The First International Workshop on Protocols for Fast Long-Distance Networks (http://datatag.web.cern.ch/datatag/pfldnet2003/) and the Second International Workshop on Protocols for Fast Long-Distance Networks (http://www-didc.lbl.gov/PFLDnet2004/) were very successful in bringing together many researchers from the U.S., Asia and Europe who are working on these problems. This workshop will continue this tradition, and provide a perfect setting for researchers in this area to exchange ideas and experience. This single-track workshop will provide researchers and technologists with a focused, highly interactive opportunity to present, discuss and exchange experience on leading research, development and future directions in high performance transport and application protocols (TCP, UDP, HTTP, FTP, etc.) over fast long-distance networks. This year, a particular emphasis will be on End Systems Issues (hardware and software). Each day will start with a plenary talk and end with a panel. In between, formal presentations of papers will be followed by extensive and informal Q&A sessions. Authors are invited to submit unpublished extended abstract for consideration. In order to facilitate discussions, attendance will be limited to 60 participants. Please register early to ensure your participation. Depending on the number of people who register, we may need to restrict the number of people from a given organization to allow for a broader representation of the research community. Registration will open on October 1, 2004. Call For Papers --------------- Participants wishing to present a paper should upload a FOUR-page extended abstract to http://www.ens-lyon.fr/LIP/RESO/Soumission by Nov 3, 2004. Authors whose abstracts are selected for presentation will have the option to submit a full paper, to be published on the PFLDnet 2005 web site and in the PFLDnet 2005 proceedings. We may try to collect the best papers for a special edition of a journal, if the authors are interested. Scope ----- The PFLDnet2005 workshop will focus on research issues and challenges as well as lessons learned from experience. Topics of interest include and are not limited to: . Protocol issues in fast long-distance networks . TCP enhancements and their comparison . Novel data transport protocols designed for new application services . RDMA over WANs . Effects of shaping on TCP and UDP traffic . Effects of striping and multi-streaming . Bulk-data transfer applications both TCP and non-TCP based . Data replication and multicasting strategies and protocols . Simulation-based results . Experiments on real networks and actual measurements . Experience with different types of hardware (PCs, routers, switches, Gigabit Ethernet cards, etc.) Important Dates --------------- Extended Abstract Submission Deadline: Nov 3 Reviews due: Nov 19 Acceptance Notification: Dec 5 Final paper submission: Jan 21 Workshop: February 3 and 4 Committees ---------- Co-Chairs: Pascale Vicat-Blanc Primet, INRIA ENS Lyon - FR Richard Hughes-Jones, Univ Manchester - UK Cheng Jin, Caltech - USA Steering Committee: Brian L Tierney, Lawrence Berkeley National Lab - USA Linda Winkler, Argonne National Lab, USA R. Les Cottrell , Stanford Linear Accelerator Center - USA Technical Program Committee: Bill Allcock (ANL - USA) Eitan Altman (INRIA France) Richard Carlson (Internet 2 - USA) Andrew Chien (UCSD - USA) Peter Clarke (UCL - UK) Les Cottrell (Stanford Linear Accelerator Center (USA) Cees De Laat (UvA - NL) Michel Diaz (LAAS -CNRS - FR) Sally Floyd (ICIR - USA) Tomohiro Kudoh (AIST JP) Douglas Leith (Hamilton Institute- IR) Steven Low (California Institute of Technology, USA) Jason Leigh (UIC - USA) Olivier Martin (CERN- CH) Medy Sanadidi (UCLA - USA) Robin Tasker (CCLRC - UK) Brian L Tierney (LBNL - USA) Gab Montenegro (SUN Microsystems - US) Local Organization Committee: Olivier Gluck (LIP - ENS Lyon) Brice Goglin (LIP - ENS Lyon) Jean-Christophe Mignot (LIP - ENS Lyon) Sylvie Boyer (LIP - ENS Lyon) Sponsors: --------- Industrials: Foundry Networks, IBM, Juniper Networks Academics: ENS Lyon, CNRS, INRIA, LIP, RESO, UCBL From marcel at end2end.l.wanda.ch Fri Oct 29 16:05:26 2004 From: marcel at end2end.l.wanda.ch (Marcel Waldvogel) Date: Fri Oct 29 16:06:27 2004 Subject: [e2e] Internet path dynamics In-Reply-To: <200409220011.i8M0BTp3043151@jaguar.icir.org> References: <200409220011.i8M0BTp3043151@jaguar.icir.org> Message-ID: <4182CCB6.9020207@end2end.l.wanda.ch> I am looking for data on how frequently the actual routing path changes. I am aware of studies that infer BGP AS route changes and those that monitor OSPF messages, but for our work, we would be interested in the rate of change to the set of routers on an end-to-end path. As I do not want to flood arbitrary sites with constant traceroutes (see the "probing and laws" thread) nor limit myself to skewed subsets (such as PlanetLab), I would appreciate pointers to existing data sets. -Marcel >You may find: > > On the Constancy of Internet Path Properties > Y. Zhang, N. Duffield, V. Paxson, and S. Shenker > Proc. ACM SIGCOMM Internet Measurement Workshop, November 2001. > > http://www.icir.org/vern/papers/constancy-IMW01.ps.gz > >of interest in this regard. > > Vern > > From randy at psg.com Fri Oct 29 17:16:16 2004 From: randy at psg.com (Randy Bush) Date: Fri Oct 29 17:17:15 2004 Subject: [e2e] Internet path dynamics References: <200409220011.i8M0BTp3043151@jaguar.icir.org> <4182CCB6.9020207@end2end.l.wanda.ch> Message-ID: <16770.56656.573619.976199@roam.psg.com> http://route-views.org/ From mrz2003 at tom.com Sat Oct 30 04:48:32 2004 From: mrz2003 at tom.com (Julian) Date: Sat Oct 30 04:50:17 2004 Subject: [e2e] Who can recommend such a classic paper to me (to calculate the throughput of multiplexed TCP flows) Message-ID: <200410301149.i9UBnoi24904@boreas.isi.edu> Hello , The scenario is that a definite number of client workstations are connected to a buffer, using TCP.And the buffer is connected with a server. The input and output line rates are known, and the parameters of each TCP connection are also known. Then how to calculate the individual throughput of each connection and the overall throughput of them? Who can do me a favor to provide a classic paper analyzing such a scenario? Thanks! Best regards, Julian Tsinghua Univ. mrz2003@tom.com From Vicks123 at gmail.com Sat Oct 30 17:15:45 2004 From: Vicks123 at gmail.com (Vikram Panduranga) Date: Sat Oct 30 17:16:20 2004 Subject: [e2e] Any paper/work on client response for unrequested data sent Message-ID: Hi, I'm working on an experiment to analyze the response from a client machine when unrequested data is sent to an open port of the client. The client will not be on a firewall. I appreciate if anyone can inform me related work or paper. thanks, Vikram From t-kuntan at microsoft.com Sun Oct 31 00:07:57 2004 From: t-kuntan at microsoft.com (Kun Tan) Date: Sun Oct 31 00:08:26 2004 Subject: [e2e] What are the typical packet error rate in a high-speed network? Message-ID: <98089B080DDD6C4DABF54EB13C145547014E0C94@APJ-MSG-02.fareast.corp.microsoft.com> Hello, I'm now wondering about what is the typical packet error rate (packet corrupt due to transmission error) in a high-speed network environment, for example, a 10Gbps LAN? I appreciate if anyone can inform me about the related statistics or papers. Thanks, - Kun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041031/ef42f8d9/attachment.html