From perfgeek at mac.com Sun Oct 1 09:50:48 2006 From: perfgeek at mac.com (rick jones) Date: Sun, 1 Oct 2006 09:50:48 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451EA4FA.1000301@psc.edu> References: <20060923103853.426C567@aland.bbn.com> <200609271153.16325.zec@tel.fer.hr> <11048837.1159401758631.JavaMail.perfgeek@mac.com> <200609281839.20384.zec@tel.fer.hr> <0b46688bfb6b82fde1d5683c842390a1@mac.com> <451EA4FA.1000301@psc.edu> Message-ID: <900df9a2fa1b27cb2d13558b9022c303@mac.com> > Especially in the case of TSO, there's close to zero benefit to > sending TSO segments that are longer than 1ms of bottleneck wire time, > as the TCP processing load for that packet rate is going to be well > under 0.1% on a modern machine. The time-of-burst sounds intriguing - what has me worried though - in the abstract, not necessarily this specific - is the last part of that sentence - it seems that very often arguments are made about how something is presently or will be soon a very low percentage of CPU on a modern machine - for a single connection and/or single NIC... > At GigE speeds, I haven't seen in practice that a 64k burst (about > 0.5ms) is ever a problem. Nor I. rick jones there is no rest for the wicked, yet the virtuous have no pillows From detlef.bosau at web.de Sun Oct 1 10:14:33 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 01 Oct 2006 19:14:33 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060925142037.112C067@aland.bbn.com> <8f884bb031b3678c4b56874456ec25aa@mac.com> <45196A07.8080102@web.de> <451973FD.50009@ieee.org> <451C5C3E.6080209@web.de> <451D5E71.7090108@ieee.org> <451D804A.5090007@web.de> Message-ID: <451FF779.7090009@web.de> Lachlan Andrew wrote: > Greetings Detlef, > > On 29/09/06, Detlef Bosau wrote: >> I haven?t read all the relevant papers yet, but hasn?t been there some >> rumour that these LRD need at least a minimum buffer size on the >> routers? In other words: If we take care not to configure buffers too >> large, would this cure the problem? > > What do you mean by "need"? It is well known that LRD needs large > buffers in the sense that avoiding heavy loss with LRD traffic needs > large buffers. I have never heard that LRD needs large buffers, in > the sense that eliminating buffers eliminates LRD. May the rumours > that you mention be refering to the first of these? > At least, I understood a post to this list some months ago in that way that a certain minimum of buffer space is a necessary condition for LRD to cause problems. From doug.leith at nuim.ie Mon Oct 2 14:43:19 2006 From: doug.leith at nuim.ie (Douglas Leith) Date: Mon, 02 Oct 2006 22:43:19 +0100 Subject: [e2e] cubic tcp behaviour In-Reply-To: References: Message-ID: <452187F7.5010106@nuim.ie> Thanks for posting your measurements on the web Injong. Without getting into the merits or otherwise of the coefficient of variation as a measure of anything users might care about, the individual time history plots of throughput and cwnd look interesting. I wonder if I could flag up some curious behaviour that seems evident in the measurements for the cubic algorithm. In very many of the individual time history plots it looks as if there are sustained periods (extending to 100s of seconds) of substantial unfairness between competing cubic flows with the same round-trip time. See for example: http://netsrv.csc.ncsu.edu/highspeed/convex-ordering/FullSet_old/RTTFAIR/1MB_4HS_0FLF_2RLF_SLF_320MS/600--CUBIC-CUBIC-SIMPLE--400-3-667--1000-155-0-0-1-1-5-500--200000-0.6-1000-10-600-64000-150--24/ http://netsrv.csc.ncsu.edu/highspeed/convex-ordering/FullSet_old/RTTFAIR/1MB_4HS_0FLF_2RLF_SLF_320MS/600--CUBIC-CUBIC-SIMPLE--400-3-667--1000-155-0-0-1-1-5-500--200000-0.6-1000-10-600-64000-150--17/ Can you comment on this behaviour ? Perhaps I am misinterpreting the data. I think its probably worth pointing out that in all the tests it looks as if the cubic flows are all started at much the same time - is this correct ? If so, the tests do not really probe the responsiveness of cubic and it might well be useful to perform tests where the flows have significantly different start times - it was this sort of experiment (by ourselves a couple of years ago now - blowing my own trumpet, I know, but what the heck :-)) that initially highlighted the convergence issues with scalable-tcp, and the slow convergence of high-speed tcp and bic-tcp. Slow convergence translates into possible sustained unfairness, for example, against new flows starting up. Doug Hamilton Institute www.hamilton.ie end2end-interest-request at postel.org wrote: > Send end2end-interest mailing list submissions to > end2end-interest at postel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.postel.org/mailman/listinfo/end2end-interest > or, via email, send a message with subject or body 'help' to > end2end-interest-request at postel.org > > You can reach the person managing the list at > end2end-interest-owner at postel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of end2end-interest digest..." > > > Today's Topics: > > 1. Stability of various TCP protocols [CUBIC, BIC, HTCP, HSTCP, > STCP] (Injong Rhee) > 2. Re: performance of BIC-TCP, High-Speed-TCP, H-TCP etc > (Injong Rhee) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Sep 2006 12:58:02 -0400 > From: "Injong Rhee" > Subject: [e2e] Stability of various TCP protocols [CUBIC, BIC, HTCP, > HSTCP, STCP] > To: > Cc: netdev at vger.kernel.org > Message-ID: <00d301c6e31f$4304fed0$4a580e98 at ncsu2cc0c3fa00> > Content-Type: text/plain; charset="ks_c_5601-1987" > > Hi, > I'd like to report on a measurement study regarding the stability of various TCP variant protocols. Although we can find quite a bit of work on fairness and convergence of protocols (including some theoretical studies on the topic as well), there is relatively little work on measuring the stability of protocols and its impact on protocol performance and overall health of the networks (e.g., the overall queue fluctions and link utilization). We have measured the degree of rate oscillation and fluctuation of protocols to have some understanding of protocol stability. > We would like to share our results with you to get some feedback from the community. > > We have some theoretical results and also experimental results. Here is the link to the experimental results. You can find links to all of our experimental data that include results from several hundred experiments. > > http://netsrv.csc.ncsu.edu/convex-ordering/ > > If you need our report on theoretical results, we can e-mail you the report. > Injong Rhee > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060928/c42cf65c/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 28 Sep 2006 12:33:32 -0400 > From: "Injong Rhee" > Subject: Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc > To: , > Cc: netdev at vger.kernel.org, Douglas Leith , > lisongxu at gmail.com, floyd at icsi.berkeley.edu, > end2end-interest at postel.org > Message-ID: <00c401c6e31b$d75c9970$4a580e98 at ncsu2cc0c3fa00> > Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; > reply-type=response > > Sure. I don't mind doing this test. I am currently working with Doug Leith > to get to the bottom of this difference. So when we get to the PFLDnet, we > should have some more findings on this. But I am up for this challenge. > > ----- Original Message ----- > From: "Lachlan Andrew" > To: > Cc: "Douglas Leith" ; ; > ; ; "Injong Rhee" > ; > Sent: Wednesday, September 27, 2006 7:20 PM > Subject: Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc > > >> Greetings all, >> >> On 23/09/06, rhee at ncsu.edu wrote: >>> Just i was pondering why we got different results and try to see if we >>> can >>> come to some understanding on this different results we got. Who knows we >>> together might run into some fundamental research issues regarding >>> testing. >> Since many interested parties will be around LA for PFLDnet, how about >> getting together after that (Friday 9 Feb) to re-run some of the >> disputed tests on one set of hardware, with everyone present to debate >> the results? >> >> You're all welcome to come to Caltech to do the testing. We can >> provide a few servers, dummynets and Gigabit switches. Everyone is >> welcome to bring their scripts, and any other hardware they need. >> >> If there is interest, we could also have things like a round-table >> discussion of the benefits of testing with different file-length >> distributions (like long lived flows to understand what is happening >> vs a range of flows to test suitability for deployment), and the >> benefits of repeating other people's tests vs testing in as many >> scenarios as possible. >> >> Who is interested in coming? >> >> Cheers, >> Lachlan >> >> -- >> Lachlan Andrew Dept of Computer Science, Caltech >> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA >> Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 >> > > > > ------------------------------ > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > > > End of end2end-interest Digest, Vol 31, Issue 21 > ************************************************ From detlef.bosau at web.de Tue Oct 3 07:06:17 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 03 Oct 2006 16:06:17 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451EB62D.4090100@psc.edu> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451EB62D.4090100@psc.edu> Message-ID: <45226E59.10206@web.de> John Heffner wrote: > > 2) Compressed acks > > 3) Big writes or reads (i.e., big window updates) from inherently > bursty applications. An example would be a filesystem-limited > transfer, where you have frequently have to to stall a few ms for disk > seeks. A CPU-bound application on a time-slicing system would be > another example. > Please correct me if I?m wrong and I thought about it a few days now, but doesn?t this put the whole ACK clocking principle in question? If we have greedy sources, anything is fine. Ideally there is one packet taken from the network and one packet sent to the network every certain period of time. But if a sender spends large periods of time to gather the information which is to be sent, e.g. it seeks for files or does database requests to answer requests to an SAP system placed by some WWW interface, it "spares up" ACKs for future use - and may send a more or less large burst of data when the information becomes available. I see two possible problems here: 1.: Depending on CWND the burst may become large. 2.: Particularly when the sender has to wait, say, several seconds for the information to become available (again I refer to a database request), it is not clear whether the capacity indicated by CWND and / or the amount "of spared ACKs" (which indicate the amount of data taken from the network) is still available. When a sender is suspended for a certain time and thus does not occupy path capacity, competing flows will continue probing and thus occupy the unused capacity. Perhaps these problems are not disjoint: If the sender takes some time for information gathering, the line runs out of data and the whole "available" path capacity is available for the next burst of data. It?s a provocative question and perhaps it was answered dozens of time, but is the ACK clocking approach feasible for "inherent bursty applications"? Or is it well suited for greedy flows with non bursty applications but in other scenarios it may run into problems? And I?m not even sure whether this could be solved by pacing, as pacing implicetely assumes a certain rate to be available for a flow. But what happens if a flow did not send anything for a while and the path capacity is occupied by competing flows then? Which rate is appropriate for the flow when it continues sending? From jheffner at psc.edu Tue Oct 3 07:47:27 2006 From: jheffner at psc.edu (John Heffner) Date: Tue, 03 Oct 2006 10:47:27 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <45226E59.10206@web.de> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451EB62D.4090100@psc.edu> <45226E59.10206@web.de> Message-ID: <452277FF.3070605@psc.edu> Detlef Bosau wrote: > It?s a provocative question and perhaps it was answered dozens of time, > but is the ACK clocking approach feasible > for "inherent bursty applications"? Or is it well suited for greedy > flows with non bursty applications but in other scenarios it may run > into problems? I don't see this as a problem with ack clocking. Networks generally don't like large bursts, but you can have a (mostly) ack-clocked flow with smoothed bursts. > And I?m not even sure whether this could be solved by pacing, as pacing > implicetely assumes a certain rate to be available for a flow. But what > happens if a flow did not send anything for a while and the path > capacity is occupied by competing flows then? > Which rate is appropriate for the flow when it continues sending? RFC2861 (Congestion Window Validation) is one approach. It's sort of an inverse slow start. Linux has been doing this for some time. -John From sunshine at cis.udel.edu Tue Oct 3 15:47:19 2006 From: sunshine at cis.udel.edu (Jelena Mirkovic) Date: Tue, 3 Oct 2006 18:47:19 -0400 (EDT) Subject: [e2e] SIGCOMM 2007 - CFP Message-ID: Dear colleague, The organization committee is most delighted to invite you to ACM SIGCOMM 2007, the first SIGCOMM in Asia to be held at Kyoto International Conference Hall in Kyoto, Japan. SIGCOMM2007 is the annual conference of the Special Interest Group on Data Communication (SIGCOMM), a vital special interest group of the Association for Computing Machinery (ACM). The Web site for the conference is http://www.sigcomm.org/sigcomm2007/ IMPORTANT DATES ----------------- Paper Submission: Jan. 31, 2007 Acceptance Notification: May 4, 2007 Camera Ready Due: Jun. 5, 2007 Conference: Aug. 27-31, 2007 CALL FOR PAPERS --------------- The SIGCOMM 2007 conference seeks papers describing significant research contributions to the field of computer and data communication networks. We invite submissions on network architecture, design, implementation, operations, analysis, measurement, performance, and simulation. Areas of interest include, but are not limited to: - Analysis and design of network architectures and algorithms - Experimental and measurement results from operational networks - Fundamental insights into network and traffic characteristics - Network fault-tolerance and reliability, debugging, and troubleshooting - Network management and traffic engineering - Network security, vulnerability, and defenses - Network, transport, and application-layer protocols - Networking issues for Web, multimedia, and gaming applications - Operating system and other host support for networking - Peer-to-peer, overlay, and content distribution networks - Resource management, quality of service, and signaling - Routing, switching, and addressing - Tools and techniques for network measurement and simulation - Wireless, mobile, ad-hoc, and sensor networks SIGCOMM 2007 solicits full papers up to 12 pages in length, in two-column ACM conference format. SIGCOMM is a selective conference where full papers typically report novel results firmly substantiated by experimentation, simulation, or analysis. OTHER EVENTS AT SIGCOMM ----------------------- As in previous years, SIGCOMM 2007 will have tutorials, workshops, a poster session, a student travel grant program, a GeoDiversity travel grant program, and a Student Paper Award. We are also soliciting proposals for tutorials, due by Nov 3, 2006. Please contact Tutorial Chairs for further details on tutorials: Paul Francis Hiroshi Esaki WORKSHOP CFP ------------ SIGCOMM 2007 will hold multiple one day workshops that will be scheduled Monday August 27 and Friday August 31, 2007, in Kyoto Japan. The SIGCOMM conference is co-located in Kyoto August 28-30, 2006. The workshop CFP Web page is: http://www.sigcomm.org/sigcomm2007/cfw.html We invite you to submit workshop proposals on any topic related to computer communication and packet networking before November 3rd, 2006 to Paul Francis . As this is the first SIGCOMM in Asia, we encourage proposals that deal with topics of special interest to Asia. A workshop proposal should contain at least: - a draft call for paper (as complete as possible) - the workshop deadlines (internal and external) - tentative composition of the committees - motivation and rationale for the workshop, expected number of submissions and participants - list of potential supporters, if any Important workshop proposal dates: ----------------------------------- Workshop Proposal Due: Nov. 3 Notification of Acceptance: Nov. 15 Workshop Call for Papers Due: Dec. 10 Typical workshop dates: ------------------------ Paper submissions due: Early March Paper accept notifications: Early April Camera-ready due: Early May For more information please contact workshop chairs: Paul Francis Hiroshi Esaki On behalf of the organizing committee: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jelena Mirkovic, Assistant Professor CIS, University of Delaware 412 Smith Hall, Newark, DE 19716 phone: 302-831-6052, fax: 302-831-8458 http://www.cis.udel.edu/~sunshine ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From detlef.bosau at web.de Fri Oct 13 10:41:31 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 13 Oct 2006 19:41:31 +0200 Subject: [e2e] Simulating split connections and ACK pacing. In-Reply-To: <45226E59.10206@web.de> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451EB62D.4090100@psc.edu> <45226E59.10206@web.de> Message-ID: <452FCFCB.4000405@web.de> I apologize if this is a bit of topic. In order to get a bit more insight in ACK pacing issues, I want to simulate split connections. I still want to do this with NS2, because this is the general accepted simulator in the community. However, my problem is that to my knowledge there is still no support for a dynamic AWND. Because I would rather verify my approaches than my code and because I?m still not too familiar with some details, e.g. recovery from zero windows, I would highly appreciate to get in touch with someone who already worked in this area. Thanks a lot. Detlef From craig at aland.bbn.com Thu Oct 19 18:00:45 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Thu, 19 Oct 2006 21:00:45 -0400 Subject: [e2e] modularity of address lookup and management Message-ID: <20061020010045.D88C564@aland.bbn.com> Hi folks: I'm currently working on a challenge related to how one modularizes problems of looking up addresses, assigning (or learning of) addresses on interfaces, at the like. To make this problem concrete, consider the requirement that a multihomed host accept any datagram with any one of the host's IP addresses as the destination. If address control is done in the MAC/device driver layer, then a datagram could trigger one lookup per interface. If address control is done by the IP layer, then there are challenges of mapping IP addresses to MAC layers/interfaces (required, as I recall, on outbound where the source IP address usually must but that of the outbound interface). Somehow, in the back of my head, there's the idea that someone looked at this problem in the early 1990s. There's text in the Router Requirements RFC and Host Requirements sketching out the problems, but not espousing a particular software modularity. Did anyone write something on this problem? Thanks! Craig E-mail: craig at aland.bbn.com or craig at bbn.com From touch at ISI.EDU Mon Oct 23 11:54:58 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 23 Oct 2006 11:54:58 -0700 Subject: [e2e] modularity of address lookup and management In-Reply-To: <20061020010045.D88C564@aland.bbn.com> References: <20061020010045.D88C564@aland.bbn.com> Message-ID: <453D1002.9070605@isi.edu> Craig Partridge wrote: > Hi folks: > > I'm currently working on a challenge related to how one modularizes > problems of looking up addresses, assigning (or learning of) addresses on > interfaces, at the like. > > To make this problem concrete, consider the requirement that a multihomed > host accept any datagram with any one of the host's IP addresses as the > destination. That presumes the weak host model; there are cases where that's not what you want (e.g., to group sets of tunnels to associate then with different virtual hosts/routers inside a real host/router). > If address control is done in the MAC/device driver layer, > then a datagram could trigger one lookup per interface. If address control > is done by the IP layer, then there are challenges of mapping IP addresses > to MAC layers/interfaces (required, as I recall, on outbound where the > source IP address usually must but that of the outbound interface). When is this 'address control' happening? There's already one lookup per packet on arrival to see if it matches one of the interfaces. On departure, that typically happens only for packets whose source addresses are unassigned. I thought RFC1122 talked about this in detail. > Somehow, in the back of my head, there's the idea that someone looked at > this problem in the early 1990s. There's text in the Router Requirements > RFC and Host Requirements sketching out the problems, but not espousing a > particular software modularity. Did anyone write something on this problem? I thought it implied that most of this happened at the network layer, not the link layer. Joe > > Thanks! > > Craig > > E-mail: craig at aland.bbn.com or craig at bbn.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20061023/4895c206/signature.bin From christophe.diot at thomson.net Mon Oct 30 15:41:51 2006 From: christophe.diot at thomson.net (Christophe Diot) Date: Tue, 31 Oct 2006 00:41:51 +0100 Subject: [e2e] CoNext 06 -- call for participation Message-ID: <45468DBF.3050604@thomson.net> The 2nd CoNEXT conference (co-sponsored by ACM SIGCOMM), will take place in Lisbon, Portugal, December 4-7, 2006. CoNEXT 2006 will be a major forum in the area of future networking technologies. CoNEXT emphasizes synergies between various international and technical communities. CoNext will start with a student workshop and a Internet of the future workshop. The conference will be 2.5 days, one track, with 20 technical presentations selected by the TPC among 100 submissions. Please look at the detailed agenda and program at: http://adetti.iscte.pt/events/CONEXT06/Main.php?contents=agenda.htm The Keynote talk will be given by Joao Sobrinho (best ToN paper award in 2005) and a "rising star award" will be delivered to Matthias Grossglauser from EPFL. Note that early registrations end on Nov 3.