From craig at bbn.com Mon Aug 2 12:40:15 2004 From: craig at bbn.com (Craig Partridge) Date: Mon Aug 2 12:40:26 2004 Subject: [e2e] TCP Performance in Satellite Networks In-Reply-To: Your message of "Thu, 29 Jul 2004 09:22:36 BST." <14239.195.92.67.79.1091089356.squirrel@195.92.67.79> Message-ID: <20040802194015.D408C1AD@aland.bbn.com> Remind me what RR-TCP and TCP DSACK do mechanically? Also, increasing dupthresh is inevitably going to increase timeout events. Even with reordering, sometimes dupe acks do loss and by increasing the threshold you're going to see more timeouts. The question is whether by increasing the dupe ack threshold you (a) reduce the number of spurious retransmissions and thus (b) improve performance enough that the occasional longer delay for a real retransmission is worth it. Craig In message <14239.195.92.67.79.1091089356.squirrel@195.92.67.79>, "Arjuna Sathi aseelan" writes: > >Dear All, > I am a PhD student and am testing the performance of TCP on >Satellite Networks when packet reordering occurs. I am a novice, so please >excuse me if somethings are irrelevant. I perform reordering >by normal distribution and packets are delayed in the range of 0ms to >200ms. This error module was attached to all the satellite nodes. I use an >Iridium constellation network. I perform experiments for 100s. The maximum >congestion window was set to 500. > >>From what I see is that when I use Sally Floyd's RR-TCP and TCP DSACK - >the performance was similar to standard TCP SACK. DSACK's were generated >and received successfully but the restoration of the congestion window >upon false retransmits never took place!! Even though I had a high maximum >window size, the congestion window grew only upto 10 segments. > >Moreover when I increase the dupthresh values (to 4,5,6), I see more >timeout events, so I guess increasing the dupthresh values when reordering >occurs is not the right way since it leads to more timeouts because of the >large RTT. Am I right? I would like to know why does RR-TCP and DSACK have >no impact on the performance. Has anyone tested the performance of both >the protocols on a Satellite environment? I would be very much obliged if >someone could clarify these doubts please. > >Regards, >Arjuna From sm at mirapoint.com Thu Aug 5 21:47:04 2004 From: sm at mirapoint.com (Sam Manthorpe) Date: Thu Aug 5 21:47:56 2004 Subject: [e2e] ACK on PUSH? Message-ID: There has to be a good reason for this, but does anyone know why it is that the two TCP stacks I use regularly don't seem to a force an ACK when they receive a data packet with PUSH flagged? (as opposed to doing delayed ack). Thanks, -- Sam ------------------------ Sam Manthorpe, Mirapoint From mycroft at netbsd.org Fri Aug 6 05:53:23 2004 From: mycroft at netbsd.org (Charles M. Hannum) Date: Fri Aug 6 05:54:05 2004 Subject: [e2e] ACK on PUSH? In-Reply-To: References: Message-ID: <200408061253.23532.mycroft@netbsd.org> On Friday 06 August 2004 04:47, Sam Manthorpe wrote: > There has to be a good reason for this, but does anyone > know why it is that the two TCP stacks I use regularly don't > seem to a force an ACK when they receive a data packet > with PUSH flagged? (as opposed to doing delayed ack). This is something I implemented in 1994 (and which was copied by many people after that) because it fixed a very nasty performance problem with some applications. Later on it was decided to solve the same problem by instead castrating delayed ACK and forcing an immediate ACK on every other packet. As I wrote on comp.protocols.tcp-ip at the time (in 1994): I've found a problem with the TCP delayed ack algorithm. If the writer's buffer becomes full before sending an entire window, the writer will stop and the ack will be delayed and the transmission will be stalled pending a timeout on (and transmission of) the delayed ack. As an experiment, I've applied the following patch to my (NetBSD) kernel, and it alleviates the problem. The worst case for this change is that the writer sets the PSH bit on every outgoing packet, in which case delayed ack is effectively disabled. This is not an issue of correctness, however, and since most vendors use the PSH bit a bit more intelligently, it doesn't seem like a serious problem. From mycroft at netbsd.org Fri Aug 6 05:53:37 2004 From: mycroft at netbsd.org (Charles M. Hannum) Date: Fri Aug 6 05:55:06 2004 Subject: [e2e] ACK on PUSH? In-Reply-To: <200408061246.27767.abuse@spamalicious.com> References: <200408061246.27767.abuse@spamalicious.com> Message-ID: <200408061253.37014.mycroft@netbsd.org> On Friday 06 August 2004 12:46, Charles M. Hannum wrote: > This is something I implemented in 1994 (and which was copied by many > people after that) because it fixed a very nasty performance problem with > some applications. Later on it was decided to solve the same problem by > instead castrating delayed ACK and forcing an immediate ACK on every other > packet. Actually, I want to expand on this a bit... The performance problem this addressed persisted in some systems, including FreeBSD, until at least 2002. (It may still, but I haven't tested it since then.) It is the reason that MacOS X.2, for example, gets significantly worse throughput (sometimes as much as 10x) downloading the same data as a NetBSD machine sitting right next to it on the same network. From wuchang at cse.ogi.edu Fri Aug 6 14:59:53 2004 From: wuchang at cse.ogi.edu (Wu-chang Feng) Date: Fri Aug 6 15:00:10 2004 Subject: [e2e] IP puzzle paper Message-ID: <4113FF59.4000905@cse.ogi.edu> To follow up on a thread from late last year, the following techreport describes a constant-state, high-speed implementation of network layer puzzles. Wu-chang Feng, Ed Kaiser, Wu-chi Feng, Antoine Luu "The Design and Implementation of Network Layer Puzzles" OGI CSE Technical Report 04-003, August 2004. http://www.cse.ogi.edu/sysl/projects/puzzles/04-003.pdf Source code release forthcoming.... Wu From e.w.vos at kpn.com Mon Aug 9 15:38:00 2004 From: e.w.vos at kpn.com (E.w.vos) Date: Mon Aug 9 12:47:06 2004 Subject: [e2e] (no subject) Message-ID: An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040809/7b7d2a93/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: new_price.zip Type: application/octet-stream Size: 5932 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040809/7b7d2a93/new_price.obj From nischal at lamar.colostate.edu Mon Aug 9 22:38:57 2004 From: nischal at lamar.colostate.edu (Nischal Piratla) Date: Mon Aug 9 22:39:35 2004 Subject: [e2e] Ouput or input reordering in routers Message-ID: <411F1C0C@webmail.colostate.edu> I have read on this forum (as pasted below)that the NPU vendors make sure that there is no reordering within a router. Let us consider a data transfer scenario with multiple hops. Assume that the first half of the routers along the path do not provide input or output reordering. Also, we will assume that there is reordering due to load-balancing (processing), in these routers. Now lets say that the remaining routers have input or output reordering enabled, i.e., they do not allow reordering. Here are my concerns: 1) Since the latter bunch of routers do consider the arrival order as actual order of packets, do they maintain the reordering that occured in earlier hops? 2) Or, is there a different meachanism to find out the actual order, while inside the latter bunch of routers? 3) Even if it is a TCP flow, will the routers ever crack into the IP packets to extract TCP sequence numbers for input/output reordering? Thank you, - Nischal Piratla Abhijit, check out the IBM and Motorola network processors, as well as Vitesse (IQ2200), TI and Intel (IXP2800). Cisco uses the IQ, the IXP and, I believe some IBM ones. The designers of most NPUs considered reordering a no-no, so provided built-in hardware to track flows, as identified in simplest form by tuples, like: input-interface, port/channel, IP details, etc. However, the output process, no matter how parallel the input, can be controlled more finely in most NPUs by the firmware designer, so he/she can extend the ordering checks at pkt-output time to see if any pkt on a particular output queue shouold be released form transmission, regardless of which input path it arrived on. The IXP2400, in fact, doesn't support anything but programmer ordering checks. Alex Abhijit Bare wrote: > > I understand that multiple input interfaces at a given NPU may process packets > of a single stream in different orders. I was wondering if anybody can direct > me to some detailed description of such architectures in use. > > Also, as we move on to high speed routers, the router architectures are > becoming more parallel in their design. For example, VOQ structures or > multi-plane switching fabcrics etc. Does this mean that we should expect more > packet reordering as the network speeds increase ? Certainly, it depends upon > the specific router architectures. But still internally they may end up in > more reordering, putting higher burden on the packet re-sequencing units. > > Abhijit > > >===== Original Message From cannara at attglobal.net ===== > >Exactly right, in fact single-chip network processors from most all the > >vendors have internal hardware (e.g., CAMs) simply to prevent pkts from being > >released before all prior ones that arrived via the same input path. > However, > >since an input path is typically a channel on an interface, such as SPIx and > >multiple interfaces exist on NPUs, there may be instances of pkts that > >traversed different upstream paths getting reordered at a given processor > that > >can't know better. > > > >Alex > > > >"Ghanwani, Anoop" wrote: > >> > >> As far as I know, under normal circumstances most routers do not > >> reorder packets. I think Juniper routers had a problem with reordering, > >> > >> but the general design practice (as far as I know) is that reordering > >> is a no-no. > >> > >> See > >> http://www.lightreading.com/document.asp?doc_id=4009&page_number=8 > >> for an interesting discussion on this subject. > >> > >> -Anoop > >> > >> > -----Original Message----- > >> > From: abhijit [mailto:abhijit at engr.colostate.edu] > >> > Sent: Friday, August 08, 2003 2:45 PM > >> > To: end2end-interest at postel.org > >> > Subject: [e2e] Reordering in routers > >> > > >> > > >> > Hi all, > >> > I am studying the packet-reordering problem over the Internet > >> > from the point > >> > of view of the routers being a reason of reordering. > >> > > >> > In the paper by "Packet Reordering is Not Pathological > >> > Network Behavior" by > >> > Bennet, Partridge, and Shectman, the router queuing structure > >> > was said to be > >> > the reason behind the reordering observed at MAE-east. The > >> > DEC gigaswitch used > >> > at MAE-east point used hunt groups i.e. collection of ports > >> > together acting as > >> > input ports that caused the packets getting distributed and > >> > hence reordered. > >> > > >> > I am studying queuing architectures and queuing disciplines > >> > of present > >> > routers. But I do not find any routers with parallel input > >> > queuing sothat > >> > incoming packets are distributed over a number of queues > >> > before getting > >> > processed. It will be great if anybody can give me > >> > information or pointers > >> > over this problem, especially: > >> > 1. Are the internal structure issues i.e. queuing > >> > architectures (input, output > >> > queues, VOQ, VIQ etc), disciplines (packet scheduling or > >> > buffer management > >> > schemes) responsible or can be responsible for reordering? > >> > 2. Or the external reasons such as route flapping, multi-path > >> > routing, > >> > parallel links between two routers, etc. are more responsible > >> > for reordering > >> > happening in the present Internet? > >> > > >> > I appreciate any information shared on this problem. > >> > Regards, > >> > Abhijit > >> > /****************************************** Research Assistant Computer Networking Research Laboratory Department of Electrical and Computer Eng. 1373, Colorado State University, Fort Collins, CO 80523 USA http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal ******************************************* From ssuryaputra at HatterasNetworks.com Tue Aug 10 08:31:21 2004 From: ssuryaputra at HatterasNetworks.com (Stephen Suryaputra) Date: Tue Aug 10 08:31:40 2004 Subject: [e2e] Ouput or input reordering in routers Message-ID: <8052E2EA753D144EB906B7A7AA399714022A06A8@mailserv.hatteras.com> Nischal, I happened to work on one core router before, so my answer is based on state of the art in 1998-1999: 1) Routers use the arrival order, so if the previous hop router reorders the packet, then there is nothing that the current hop can do. 2) Nope, see answer below. 3) Typically, deep packet inspection that goes to the TCP level is slowing the performance of the datapath (more memory read to know what's going on). Furthermore, trying to figure out flows to just fix the order of the packets does not scale very well (esp. in the core). However, I do think that putting back the order at the access router is feasible (since more and more of those devices are doing firewall and the number of TCP flows is much more manageable). Hope this help, -----Original Message----- From: end2end-interest-bounces@postel.org [mailto:end2end-interest-bounces@postel.org]On Behalf Of Nischal Piratla Sent: Tuesday, August 10, 2004 1:39 AM To: end2end-interest@postel.org Subject: [e2e] Ouput or input reordering in routers I have read on this forum (as pasted below)that the NPU vendors make sure that there is no reordering within a router. Let us consider a data transfer scenario with multiple hops. Assume that the first half of the routers along the path do not provide input or output reordering. Also, we will assume that there is reordering due to load-balancing (processing), in these routers. Now lets say that the remaining routers have input or output reordering enabled, i.e., they do not allow reordering. Here are my concerns: 1) Since the latter bunch of routers do consider the arrival order as actual order of packets, do they maintain the reordering that occured in earlier hops? 2) Or, is there a different meachanism to find out the actual order, while inside the latter bunch of routers? 3) Even if it is a TCP flow, will the routers ever crack into the IP packets to extract TCP sequence numbers for input/output reordering? Thank you, - Nischal Piratla Abhijit, check out the IBM and Motorola network processors, as well as Vitesse (IQ2200), TI and Intel (IXP2800). Cisco uses the IQ, the IXP and, I believe some IBM ones. The designers of most NPUs considered reordering a no-no, so provided built-in hardware to track flows, as identified in simplest form by tuples, like: input-interface, port/channel, IP details, etc. However, the output process, no matter how parallel the input, can be controlled more finely in most NPUs by the firmware designer, so he/she can extend the ordering checks at pkt-output time to see if any pkt on a particular output queue shouold be released form transmission, regardless of which input path it arrived on. The IXP2400, in fact, doesn't support anything but programmer ordering checks. Alex Abhijit Bare wrote: > > I understand that multiple input interfaces at a given NPU may process packets > of a single stream in different orders. I was wondering if anybody can direct > me to some detailed description of such architectures in use. > > Also, as we move on to high speed routers, the router architectures are > becoming more parallel in their design. For example, VOQ structures or > multi-plane switching fabcrics etc. Does this mean that we should expect more > packet reordering as the network speeds increase ? Certainly, it depends upon > the specific router architectures. But still internally they may end up in > more reordering, putting higher burden on the packet re-sequencing units. > > Abhijit > > >===== Original Message From cannara at attglobal.net ===== > >Exactly right, in fact single-chip network processors from most all the > >vendors have internal hardware (e.g., CAMs) simply to prevent pkts from being > >released before all prior ones that arrived via the same input path. > However, > >since an input path is typically a channel on an interface, such as SPIx and > >multiple interfaces exist on NPUs, there may be instances of pkts that > >traversed different upstream paths getting reordered at a given processor > that > >can't know better. > > > >Alex > > > >"Ghanwani, Anoop" wrote: > >> > >> As far as I know, under normal circumstances most routers do not > >> reorder packets. I think Juniper routers had a problem with reordering, > >> > >> but the general design practice (as far as I know) is that reordering > >> is a no-no. > >> > >> See > >> http://www.lightreading.com/document.asp?doc_id=4009&page_number=8 > >> for an interesting discussion on this subject. > >> > >> -Anoop > >> > >> > -----Original Message----- > >> > From: abhijit [mailto:abhijit at engr.colostate.edu] > >> > Sent: Friday, August 08, 2003 2:45 PM > >> > To: end2end-interest at postel.org > >> > Subject: [e2e] Reordering in routers > >> > > >> > > >> > Hi all, > >> > I am studying the packet-reordering problem over the Internet > >> > from the point > >> > of view of the routers being a reason of reordering. > >> > > >> > In the paper by "Packet Reordering is Not Pathological > >> > Network Behavior" by > >> > Bennet, Partridge, and Shectman, the router queuing structure > >> > was said to be > >> > the reason behind the reordering observed at MAE-east. The > >> > DEC gigaswitch used > >> > at MAE-east point used hunt groups i.e. collection of ports > >> > together acting as > >> > input ports that caused the packets getting distributed and > >> > hence reordered. > >> > > >> > I am studying queuing architectures and queuing disciplines > >> > of present > >> > routers. But I do not find any routers with parallel input > >> > queuing sothat > >> > incoming packets are distributed over a number of queues > >> > before getting > >> > processed. It will be great if anybody can give me > >> > information or pointers > >> > over this problem, especially: > >> > 1. Are the internal structure issues i.e. queuing > >> > architectures (input, output > >> > queues, VOQ, VIQ etc), disciplines (packet scheduling or > >> > buffer management > >> > schemes) responsible or can be responsible for reordering? > >> > 2. Or the external reasons such as route flapping, multi-path > >> > routing, > >> > parallel links between two routers, etc. are more responsible > >> > for reordering > >> > happening in the present Internet? > >> > > >> > I appreciate any information shared on this problem. > >> > Regards, > >> > Abhijit > >> > /****************************************** Research Assistant Computer Networking Research Laboratory Department of Electrical and Computer Eng. 1373, Colorado State University, Fort Collins, CO 80523 USA http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal ******************************************* From matta at cs.bu.edu Thu Aug 19 15:41:13 2004 From: matta at cs.bu.edu (Ibrahim Matta) Date: Thu Aug 19 15:39:28 2004 Subject: [e2e] Report on the first COST(EU)-NSF(USA) NeXtworking Message-ID: <0511C607B17F804EBE96FFECD1FD98590B4A19@cs-exs2.cs-nt.bu.edu> Dear Colleagues: We would like to bring to your attention the report on the First COST-IST (EU) / NSF-ANI (USA) Workshop on Exchanges and Trends in Networking (NeXtworking) A preliminary version is available at: http://www.cs.bu.edu/faculty/matta/public/NeXtworking03-v0.pdf Additional information on the workshop is available from the workshop website at: http://cgi.di.uoa.gr/~istavrak/costnsf/ Sincerely, Ioannis Stavrakakis (istavrak@di.uoa.gr) Ibrahim Matta (matta@cs.bu.edu) Michael Smirnov (smirnow@fokus.fraunhofer.de) ----------------------------------------------------------------- First COST-IST (EU) / NSF-ANI (USA) Workshop on Exchanges and Trends in Networking (NeXtworking) Abstract: This workshop was the first attempt to bring together the Networking research communities from the USA and Europe in a common forum, to exchange research ideas and trends in Networking. Unique features of this meeting were the joint and balanced participation of researchers from the European and USA research communities and the high concentration of top, mature and highly respected researchers from both communities. Specific workshop objectives were to: * Discuss key, new and upcoming networking technologies and open issues by focusing on the driving fundamental aspects and principles. * Provide the opportunity to the networking communities in Europe and USA to get together and have a first-hand exposure to the advancements and strengths in the other side of the Atlantic. * Provide a forum that could help the workshop-sponsoring funding agencies in Europe and USA identify the key and necessary future networking technologies and direct research funding accordingly. Any opinions, findings, conclusions or recommendations expressed in this report are those of the authors and do not necessarily reflect the views of the authors' institutions or the European Cooperation in the field of Scientific and Technical research (COST) or the National Science Foundation (NSF). Ioannis Stavrakakis, General Workshop Chair and TPC co-Chair Ibrahim Matta, TPC co-Chair Michael Smirnov, TPC co-chair From agthorr at barsoom.org Mon Aug 23 12:42:07 2004 From: agthorr at barsoom.org (Agthorr) Date: Mon Aug 23 12:42:41 2004 Subject: [e2e] Identifying firewalled and NATed hosts Message-ID: <20040823194207.GF27459@barsoom.org> I'm working on a Gnutella measurement study. Using a crawler I developed, I capture snapshots of the Gnutella overlay topology. Unfortunately, a significant fraction of Gnutella nodes are so overwhelmed that their TCP connection backlog is full and they refuse connection attempts with an RST packet. I know they are aren't firewalled because I can connect to them eventually if I am persistent. To better characterize this problem, I'd like to distinguish these hosts from firewalled and NATed hosts. Continually trying to connect to the overwhelmed hosts is both time-consuming and a bit invasive. Is there a quick, not-too-invasive test I can perform to identify an IP address as a NAT device rather than an end-host? -- Daniel Stutzbach Computer Science Ph.D Student http://www.barsoom.org/~agthorr University of Oregon From charles at cs.columbia.edu Sat Aug 28 22:15:02 2004 From: charles at cs.columbia.edu (Charles Shen) Date: Sat Aug 28 22:15:13 2004 Subject: [e2e] Looking for measurement hosts Message-ID: <007a01c48d87$23314770$37413b80@ccs> Dear all, We are working on a measurement project to determine route change by delay changes. We need some remote hosts to participate in the measurement. If you are able to provide a remote host account, please kindly let me know. (Although Planetlab could be a choice, it seems to be sufficiently overloaded to make such measurement difficult). Thanks and best regards, Charles -- http://www.cs.columbia.edu/IRT/ From dga at lcs.mit.edu Sun Aug 29 06:40:06 2004 From: dga at lcs.mit.edu (David G. Andersen) Date: Sun Aug 29 06:40:23 2004 Subject: [e2e] Looking for measurement hosts In-Reply-To: <007a01c48d87$23314770$37413b80@ccs> References: <007a01c48d87$23314770$37413b80@ccs> Message-ID: <20040829134006.GE2722@lcs.mit.edu> On Sun, Aug 29, 2004 at 01:15:02AM -0400, Charles Shen scribed: > Dear all, > > We are working on a measurement project to determine route change by delay > changes. We need some remote hosts to participate in the measurement. If you > are able to provide a remote host account, please kindly let me know. > (Although Planetlab could be a choice, it seems to be sufficiently > overloaded to make such measurement difficult). If your traffic and CPU demands are low, then I'd encourage you to use the RON testbed, available through Emulab. I'm trying to maintain a "measurement-friendly" environment through aggressive up-front admission control to prevent sigcomm deadline meltdowns, and so far it seems to be working. see http://www.emulab.net/ The policies for use of the widearea nodes are at: http://www.emulab.net/docwrapper.php3?docname=widearea.html You'll need to send us a description of the experiments you want to perform -- basically, how much bandwidth, how often, how long? and then .. go to town with your measurements. :) One caveat: Emulab is having a three-day downtime starting this afternoon (!) while the university of utah does some major power re-wiring for their building. So.. some patience may be required. The RON testbed nodes will be up, but we won't be able to create new accounts for you. Best way to get access is to have a PI-type person create a new project (which needs to be approved), and then you can autonomously create accounts for your students/staff. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ From matt at internet2.edu Sun Aug 29 08:03:30 2004 From: matt at internet2.edu (Matthew J Zekauskas) Date: Sun Aug 29 08:04:15 2004 Subject: [e2e] Looking for measurement hosts In-Reply-To: <007a01c48d87$23314770$37413b80@ccs> References: <007a01c48d87$23314770$37413b80@ccs> Message-ID: For what it's worth, there are at least two latency measurement infrastructures deployed in research networks here in the US (and a bit abroad). Internet2 has OWAMP ( http://e2epi.internet2.edu/owamp/ ) nodes deployed at all of the Abilene router nodes, which you are free to test to. The limitation is that since they are within the Abilene backbone, they are not reachable from the commodity Internet (but are reachable from Universities and Labs around the world). NLANR MNA has AMP, which is also mostly deployed at R&E sites, although since they are at universities, they ought to be reachable from the commodity Internet. See http://mna.nlanr.net/amp/ . Outside the US, the RIPE Test-Traffic infrastructure has some deployment (http://www.ripe.net/test-traffic/ ). None of these will probably be excited about running any code that you develop, however. You are probably aware of the other two projects collecting similar data, but Just In Case: The PingER project has been capturing RTTs for sites all over the world for many years (since 1996?), although it is focused on sites that are interested in High-Energy Physics data. CAIDA's skitter project has been probing many sites all over the world for almost as long. I believe you can request some skitter data to support an active research project. If running code within the Abilene backbone is useful to you, and for some reason the local Planetlab nodes are not good enough (they have nodes at all Abilene backbone sites too), let me know, and I'll see if running your code is a possibility. As a final plug: the Abilene Observatory has a program that will allow researchers both access to our data and the possibility of adding your own equipment at Abilene nodes. See . --Matt --On Sunday, August 29, 2004 1:15 AM -0400 Charles Shen wrote: > Dear all, > > We are working on a measurement project to determine route change by delay > changes. We need some remote hosts to participate in the measurement. If you > are able to provide a remote host account, please kindly let me know. > (Although Planetlab could be a choice, it seems to be sufficiently > overloaded to make such measurement difficult). > > Thanks and best regards, > > Charles > > -- > http://www.cs.columbia.edu/IRT/ > > From matt at internet2.edu Sun Aug 29 08:19:01 2004 From: matt at internet2.edu (Matthew J Zekauskas) Date: Sun Aug 29 08:20:17 2004 Subject: [e2e] Looking for measurement hosts In-Reply-To: References: <007a01c48d87$23314770$37413b80@ccs> Message-ID: <0AC5D7135E62B21E31233F83@DCFF15AFC1F6764BA3927E50> possible typo: --On Sunday, August 29, 2004 11:03 AM -0400 Matthew J Zekauskas wrote: > See http://mna.nlanr.net/amp/ http://mna.nlanr.net/AMP/ However, their web server is inaccessible to me now, so I can't check. --Matt From cottrell at slac.stanford.edu Sun Aug 29 10:05:15 2004 From: cottrell at slac.stanford.edu (Cottrell, Les) Date: Sun Aug 29 10:06:20 2004 Subject: [e2e] Looking for measurement hosts Message-ID: <35C208A168A04B4EB99D1E13F2A4DB01217548@exch-mail1.win.slac.stanford.edu> As Matt says the PingER Project has ping RTTs going back many years (to Jan 1995) between many thousands of sites. Today there are about 35 measurements sites and over 500 remote sites (ping echo responders). Originally for High Energy Physics, increasingly this is to understand the Digital Divide so we monitor to over 100 countries. The measurements are made every 30 minutes and consist of 21 pings (11 with 100byte payload and 10 with 1000 byte payload). For more details see http://www-iepm.slac.stanford.edu/pinger/ A second project IEPM-BW makes more intense measurements mainly between HENP, Grid and high performance network sites. There are about 50 production hosts/sites involved. However there are only a few (measurement hosts (the ones that send the probes). Unfortunately in both cases the hosts are production hosts and we do not control them and cannot give you accounts, only the individual site admins can do this. With today's security concerns this of course is a serious hurdle. On the other hand we can make the historical PingER data available to you via FTP (for large amounts) or via a URL for more modest amounts, or via web services for more on demand near real-time results. Another possibility which we would be interested in exploring would be to make make your type of measurements in the IEPM-BW project framework and make the results available to you via Web services. Then you could retrieve the results in near real-time and run you analysis. In this case we (or you, see below) would install your measurement engine, and the IEPM-BW infrastructure would make the measurements between the IEPM-BW sites. This way you would not need any accounts, but would rely on us to install the measurement engine. We could also explore getting you an account at SLAC (since we do have some say in the SLAC hosts) so you could install the measurement engine yourself. If and when your toolkit is ready for production, we could then install the measurements engine at other IEPM-BW measurement sites. If you are interested please contact me. My phone is 1-650-926-2523. -----Original Message----- From: end2end-interest-bounces@postel.org [mailto:end2end-interest-bounces@postel.org] On Behalf Of Charles Shen Sent: Saturday, August 28, 2004 10:15 PM To: end2end-interest@postel.org Subject: [e2e] Looking for measurement hosts Dear all, We are working on a measurement project to determine route change by delay changes. We need some remote hosts to participate in the measurement. If you are able to provide a remote host account, please kindly let me know. (Although Planetlab could be a choice, it seems to be sufficiently overloaded to make such measurement difficult). Thanks and best regards, Charles -- http://www.cs.columbia.edu/IRT/ From nspring at cs.washington.edu Sun Aug 29 16:20:51 2004 From: nspring at cs.washington.edu (Neil Spring) Date: Sun Aug 29 16:21:20 2004 Subject: [e2e] Looking for measurement hosts In-Reply-To: <007a01c48d87$23314770$37413b80@ccs> References: <007a01c48d87$23314770$37413b80@ccs> Message-ID: <20040829232050.GA17161@cs.washington.edu> On Sun, Aug 29, 2004 at 01:15:02AM -0400, Charles Shen wrote: > (Although Planetlab could be a choice, it seems to be sufficiently > overloaded to make such measurement difficult). PlanetLab's recently upgraded scheduler is designed to make the number of errant java processes irrelevant. Scriptroute on PlanetLab is designed to allow you to run arbitrary but safe network measurement code and access kernel-supplied timestamps through their safe raw socket interface. A current caveat with delay measurements on PlanetLab is somewhat flaky clocks; a problem I do not yet correct for within the scriptroute daemon but is being mitigated in other ways. I'd be happy to talk more; I may have an unreasonably high opinion of my Scriptroute code, but I think writing off PlanetLab is premature. -neil From henk at ripe.net Mon Aug 30 14:57:42 2004 From: henk at ripe.net (Henk Uijterwaal (RIPE NCC)) Date: Mon Aug 30 14:58:25 2004 Subject: [e2e] Looking for measurement hosts In-Reply-To: References: <007a01c48d87$23314770$37413b80@ccs> Message-ID: Charles, > Outside the US, the RIPE Test-Traffic infrastructure has some > deployment (http://www.ripe.net/test-traffic/ ). > > None of these will probably be excited about running any code > that you develop, however. No, I am not going to let you run code on any of our boxes :-) However, if you are interested in the data: * traceroutes between all O(100) measurement boxes, taken 6-10 times per hour, * one-way-delay measurements between the boxes, measured 2 times per minute, on average. all the way back to 1999, for the full mesh of machines, then please contact me to discuss details. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). From jshen_cad at yahoo.com.cn Tue Aug 31 04:16:18 2004 From: jshen_cad at yahoo.com.cn (=?gb2312?q?Jing=20Shen?=) Date: Tue Aug 31 04:17:27 2004 Subject: [e2e] WRED and QoS Message-ID: <20040831111618.95806.qmail@web15211.mail.bjs.yahoo.com> Hi, We are trying to implement DiffServ Based e2e QoS provisioning in our network. Someone recommend that WRED should be used on each node which is setup to send traffic according to DSCP/IP_precedence. They disclame that that is the best solution for current network. But, as I know WRED will biase normal TCP flows, while UDP and greedy TCP flows will win in Bandwidth competition. I'm trying to find some concrete analysis on impact of WRED on e2e QoS in diffserv network. Is there any work on it? thanks in advance. 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 anoop.ghanwani at hp.com Tue Aug 31 09:53:09 2004 From: anoop.ghanwani at hp.com (Ghanwani, Anoop) Date: Tue Aug 31 09:54:31 2004 Subject: [e2e] WRED and QoS Message-ID: <83AB0942FD087D499DF2DD5CEE1B613374CB5A@cacexc06.americas.cpqcorp.net> > I'm trying to find some concrete analysis on impact of > WRED on e2e QoS in diffserv network. Is there any > work on it? You can try: http://www.magma.ca/~terrim/RedLit.htm and the references on that page. Anoop