From rbriscoe at jungle.bt.co.uk Sat Sep 1 02:02:37 2007 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Sat, 01 Sep 2007 10:02:37 +0100 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D7BC78.6030106@isi.edu> References: <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> <46D6E139.1050202@isi.edu> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> Message-ID: <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk> Joe, I composed responses yesterday to each of your points, but I've realised there's no purpose in sending them until the underlying terms of reference are mended... At 08:00 31/08/2007, Joe Touch wrote: >Bob (et al), ---snip--- > >> (and, as others have noted, it's not > >> clear we _need_ to do anything). > > > > Tell that to the CEO of any network operator. I think you're saying > > there's not an engineering problem. But that's because resource > > allocation problems are economic problems not engineering problems... > >No - I'm saying it isn't a problem. Whether it's economic or otherwise, >as others have noted, not being 'fair' depends on an agreed concept of >fairness. We have one now - per-TCP connection, relative to RTT. That's >not perfect, but it is a definition, and it does work. Well, most people who have entered this debate (mosly on tsvwg) have tried to distance themselves from ever having been definite about per-TCP connection/RTT as the agreed measure. Of course there's not a problem... if you're measuring it the way you are... but that's because the measure you're using isn't a relevant measure - fairness is a social science issue so you need a social or economic measure. Otherwise your judgement of whether 'it works' is circular... Imagine a country had a tax system based on the number of transactions entering and leaving a person's bank accounts. * I'm saying such a metric doesn't produce a fair taxation system (e.g. high earners stuff more money through less transactions). * By analogy, by sticking with transaction count as a measure, you're led to argue that there's not a problem. You can cite surveys of the transaction count into people's bank accounts that show people are being taxed in fair proportion to this count, and further, you're led to say that there can't be a problem because the spread of the count of transactions between most and least is pretty small. If you look instead at the different volumes of congestion that users cause against how much each is contributing to the system, you should be able to see there is a huge problem. There's also a far greater spread of congestion volume caused by different users than is warranted by any value they get from causing it - many orders of magnitude between the lowest quartile and the highest, but the spread of contributions is probably within an order of magnitude. It's not just flow rate. Flow rate must be weighted by the prevailing congestion at each instant and the result accumulated over /time/. Then attributed to each /economic entity/. That's congestion volume per 'user'. And, if we go straight to congestion volume without passing through flow rate, the resulting accountability system is really simple. Ditch flows. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From touch at ISI.EDU Sat Sep 1 03:05:03 2007 From: touch at ISI.EDU (Joe Touch) Date: Sat, 01 Sep 2007 03:05:03 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> <46D6E139.1050202@isi.edu> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk> Message-ID: <46D9394F.1040304@isi.edu> Bob Briscoe wrote: > Joe, > > I composed responses yesterday to each of your points, but I've realised > there's no purpose in sending them until the underlying terms of > reference are mended... The underlying issues are, as far as this thread is concerned, IMO: 1) any mechanism that TCP needs to be per-user fair - to defeat multiple TCP connections as a cheat - is needed both for TCP and flow-rate fairness. 2) that mechanism doesn't exist, so flow-rate fairness alone isn't sufficient 3) if that mechanism did exist, THEN we're back to arguing the definition of fairness at two levels (at least): a) from the user down to the flow/connection within that nonexistent mechanism b) among flows/connections Near as I can tell, FRF addresses ONLY 3b. IMO, this thread is more about 3a; FRF has absolutely nothing to do with that. IMO, 3a drives more about what people consider 'fair' than anything else. You raised an excellent point that there's nothing about this mechanism that we cannot implement, however, 3a requires knowing the policy we want to enforce, and we don't know (or at least don't agree upon) that. Further, we agree that FRF is better than TCP-friendly 'fairness'. We probably ought to agree to disagree about whether TCP-friendly fairness is so utterly broken that it needs to be replaced, and whether the impact required to deploy FRF is worth the benefit gained. That's the devil in our past arguments, and in most of the negative FRF feedback I've seen from the IETF in public. However, those last two points have nothing to do with this thread, again, AFAICT. Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070901/e5a74aaa/signature.bin From rbriscoe at jungle.bt.co.uk Mon Sep 3 05:07:53 2007 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Mon, 03 Sep 2007 13:07:53 +0100 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D9394F.1040304@isi.edu> References: <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> <46D6E139.1050202@isi.edu> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk> Message-ID: <5.2.1.1.2.20070901110955.04232c18@pop3.jungle.bt.co.uk> Joe, To take the last point first about relevance to this thread. You may have missed my second posting (in response to JonC), clarifying that any assumption that multiple TCP connections are bad/unfair/cheating was in the reader's head, not in my posting (and hey, I started this thread!). This thread is about how it would be OK to open multiple connections (or window scaling) if there were accountability for the congestion caused. Or as I put it at the start, "Why shouldn't app-layer people expect the transport layer to correctly handle fairness?" [fairness would actually be done below the transport layer]. Nonetheless, I believe Hitler was bad/unfair/cheating (that may help Ted place me on his political spectrum :) more inline... At 11:05 01/09/2007, Joe Touch wrote: >Bob Briscoe wrote: > > Joe, > > > > I composed responses yesterday to each of your points, but I've realised > > there's no purpose in sending them until the underlying terms of > > reference are mended... > >The underlying issues are, as far as this thread is concerned, IMO: > >1) any mechanism that TCP needs to be per-user fair - to defeat multiple >TCP connections as a cheat - is needed both for TCP and flow-rate fairness. Yes. Indeed, it's needed irrespective of how a user's bits are carved up into flows. Nit: If you really meant "TCP and flow rate fairness", this might indicate we're taking different meanings for FRF. The term "FRF" is surely a general term for TCP fairness, generalised to include other attempts to define fairness; as approximate equality of the rates of individual competing flows. From a couple of other instances later in this thread, I think you've mistakenly used the term "flow rate fairness" where you possibly meant "cost fairness". But in one case, I think you might have really meant flow rate fairness. I need to check whether I need to decode an intermittent substitution cipher! >2) that mechanism doesn't exist, so flow-rate fairness alone isn't >sufficient I'm lost. We must be talking at complete cross-purposes here. But whatever, that mechanism does exist, at least as a proposal (mine). My proposal (re-ECN) can do both: - any form of flow-rate fairness (by confining its scope to each flow myopically) including TCP-fairness - and wider fairness across flows (cost fairness). >3) if that mechanism did exist, THEN we're back to arguing the >definition of fairness at two levels (at least): > > a) from the user down to the flow/connection within that > nonexistent mechanism > > b) among flows/connections > >Near as I can tell, FRF addresses ONLY 3b. > >IMO, this thread is more about 3a; FRF has absolutely nothing to do with >that. Now, I do agree with both these statements. >IMO, 3a drives more about what people consider 'fair' than anything else. I think you're saying "what people believe" is what you believe they should believe? If that's a correct reading, yes I agree. And that's one of the main motivations of my proposal. >You raised an excellent point that there's nothing about this mechanism >that we cannot implement, however, 3a requires knowing the policy we >want to enforce, and we don't know (or at least don't agree upon) that. re-ECN doesn't take a position on what the policy should be - it allows policy to be applied to it. We need a policy control system precisely when we don't know what the policy should be. >Further, we agree that FRF is better than TCP-friendly 'fairness'. Again, eh? FRF is a superset of TCP-friendly. But I'm glad to see you've put 'fairness' in quotes, so we must be agreeing at some level, but there's a misunderstanding or a substitution cipher here somewhere too. >We probably ought to agree to disagree about whether TCP-friendly >fairness is so utterly broken that it needs to be replaced, and whether >the impact required to deploy FRF is worth the benefit gained. That's >the devil in our past arguments, and in most of the negative FRF >feedback I've seen from the IETF in public. I think you might be meaning cost fairness, when you say FRF? Otherwise, there's a deep level of misunderstanding here. Cheers Bob >However, those last two points have nothing to do with this thread, >again, AFAICT. > >Joe > >-- >---------------------------------------------------------------------- >Joe Touch Sr. Network Engineer, USAF TSAT Space Segment > Postel Center Director & Research Assoc. Prof., USC/ISI ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From touch at ISI.EDU Mon Sep 3 19:03:49 2007 From: touch at ISI.EDU (Joe Touch) Date: Mon, 03 Sep 2007 19:03:49 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <5.2.1.1.2.20070901110955.04232c18@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> <46D6E139.1050202@isi.edu> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070901110955.04232c18@pop3.jungle.bt.co.uk> Message-ID: <46DCBD05.7030006@isi.edu> Bob, Bob Briscoe wrote: > Joe, > > To take the last point first about relevance to this thread. > > You may have missed my second posting (in response to JonC), > > clarifying that any assumption that multiple TCP connections are > bad/unfair/cheating was in the reader's head, not in my posting (and > hey, I started this thread!). This thread is about how it would be OK to > open multiple connections (or window scaling) if there were > accountability for the congestion caused. I didn't miss it; it doesn't address the issue that this sort of fairness is defined by a policy that we don't currently have. > Or as I put it at the start, "Why shouldn't app-layer people expect the > transport layer to correctly handle fairness?" [fairness would actually > be done below the transport layer]. IMO, the missing piece is above the transport layer, not below. > Nonetheless, I believe Hitler was bad/unfair/cheating (that may help Ted > place me on his political spectrum :) > > more inline... > > > At 11:05 01/09/2007, Joe Touch wrote: > >> Bob Briscoe wrote: >> > Joe, >> > >> > I composed responses yesterday to each of your points, but I've >> realised >> > there's no purpose in sending them until the underlying terms of >> > reference are mended... >> >> The underlying issues are, as far as this thread is concerned, IMO: >> >> 1) any mechanism that TCP needs to be per-user fair - to defeat multiple >> TCP connections as a cheat - is needed both for TCP and flow-rate >> fairness. > > Yes. Indeed, it's needed irrespective of how a user's bits are carved up > into flows. > > Nit: If you really meant "TCP and flow rate fairness", this might > indicate we're taking different meanings for FRF. The term "FRF" is > surely a general term for TCP fairness, generalised to include other > attempts to define fairness; as approximate equality of the rates of > individual competing flows. > > From a couple of other instances later in this thread, I think you've > mistakenly used the term "flow rate fairness" where you possibly meant > "cost fairness". But in one case, I think you might have really meant > flow rate fairness. I need to check whether I need to decode an > intermittent substitution cipher! Pick an acronym suitable for the mechanism you propose. ;-) >> 2) that mechanism doesn't exist, so flow-rate fairness alone isn't >> sufficient > > I'm lost. We must be talking at complete cross-purposes here. > > But whatever, that mechanism does exist, at least as a proposal (mine). > > My proposal (re-ECN) can do both: > - any form of flow-rate fairness (by confining its scope to each flow > myopically) including TCP-fairness > - and wider fairness across flows (cost fairness). So can RFC2140. The missing piece is "what is fair": one 'chunk' (flow, cost, unit - again, the term isn't as relevant as the concept) per: - user (what's a user?) - process - transport connection - endpoint IP address - HIP ID - IPsec SA Until we decide how aggregate accounting happens, the rest is moot. The fundamental problem with opening multiple TCP flows to 'cheat' is that there are different groups with different views on that aggregation. Given whatever aggregation you find comfortable, there are different versions of fair: - yours - TCP-friendly Now, admittedly, TCP-friendly doesn't jib with what some would call fair, especially because, other things being equal: - smaller RTT gets a bigger slice - lower loss gets a bigger slice - obeying TCP's rules for friendliness The useful point about TCP-friendly is that it's currently sufficient largely (IMO) because users can't do anything to make the first two of those parameters smaller; they can only increase them, and that is self-penalizing. The last parameter is the devil, but it's somewhat a defining characteristic of any mechanism that lacks enforcement, somewhat of a Nash-ism: everyone plays by the rules, and the rules work for everyone. >> 3) if that mechanism did exist, THEN we're back to arguing the >> definition of fairness at two levels (at least): >> >> a) from the user down to the flow/connection within that >> nonexistent mechanism >> >> b) among flows/connections >> >> Near as I can tell, FRF addresses ONLY 3b. >> >> IMO, this thread is more about 3a; FRF has absolutely nothing to do with >> that. > > Now, I do agree with both these statements. > >> IMO, 3a drives more about what people consider 'fair' than anything else. > > I think you're saying "what people believe" is what you believe they > should believe? If that's a correct reading, yes I agree. And that's one > of the main motivations of my proposal. I agree! You want to define a more 'fair' concept of 'fair' among parties, but the problem in this thread is more with defining a 'party' (IP flow, endpoint, HIP ID, etc.) than with what's fair once you do that. >> You raised an excellent point that there's nothing about this mechanism >> that we cannot implement, however, 3a requires knowing the policy we >> want to enforce, and we don't know (or at least don't agree upon) that. > > re-ECN doesn't take a position on what the policy should be - it allows > policy to be applied to it. We need a policy control system precisely > when we don't know what the policy should be. Right! And it's the lack of that policy that is the key to *this* thread. >> Further, we agree that FRF is better than TCP-friendly 'fairness'. > > Again, eh? FRF is a superset of TCP-friendly. But I'm glad to see you've > put 'fairness' in quotes, so we must be agreeing at some level, but > there's a misunderstanding or a substitution cipher here somewhere too. s/FRF/Bob's mechanism/ -- I think we agree here. >> We probably ought to agree to disagree about whether TCP-friendly >> fairness is so utterly broken that it needs to be replaced, and whether >> the impact required to deploy FRF is worth the benefit gained. That's >> the devil in our past arguments, and in most of the negative FRF >> feedback I've seen from the IETF in public. > > I think you might be meaning cost fairness, when you say FRF? Otherwise, > there's a deep level of misunderstanding here. Probably. >> However, those last two points have nothing to do with this thread, >> again, AFAICT. Let's not please lose this last point, however. -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070903/e976b624/signature.bin From garmitage at swin.edu.au Thu Sep 6 23:34:16 2007 From: garmitage at swin.edu.au (grenville armitage) Date: Fri, 07 Sep 2007 16:34:16 +1000 Subject: [e2e] Logging active TCP details in FreeBSD 5, 6 and 7 Message-ID: <46E0F0E8.8040000@swin.edu.au> All, On the off chance this is of general interest, I'd like to let people know of a FreeBSD kernel module we've developed for logging various TCP state variables in a running kernel while sessions are active. Called SIFTR ("sifter"), we built this for our own research into precisely how a FreeBSD TCP stack behaves when faced with real and artificial (e.g. dummynet) paths. Figured it might also be of interest to others. See http://caia.swin.edu.au/urp/newtcp/tools.html (under SIFTR) for a readme, changelog and tarball. The authors would love to get feedback from anyone trying it out. (SIFTR has been developed and tested mostly under FreeBSD 6.2, but we believe it'll be stable under 5.x and 7.x too.) cheers, gja From nataraja at cis.udel.edu Sun Sep 9 06:12:07 2007 From: nataraja at cis.udel.edu (Preethi Natarajan) Date: Sun, 09 Sep 2007 09:12:07 -0400 Subject: [e2e] VSAT/3G Message-ID: <46E3F127.4080109@cis.udel.edu> Hello, Can someone point me to references/information on characteristics (bandwidth, typical loss rates observed, e2e delay) of (i) current VSAT deployments for Internet connectivity in countries such as Africa, India (ii) 3G networks Thanks a ton! Preethi From nina.taft at intel.com Sat Sep 15 01:05:26 2007 From: nina.taft at intel.com (Taft, Nina) Date: Sat, 15 Sep 2007 01:05:26 -0700 Subject: [e2e] IMC 2007 Call For Participation Message-ID: <4D97B70CF7F72144881F66DFF4BD7A1202A7C6C3@fmsmsx413.amr.corp.intel.com> Dear Colleagues, It is now time to register and book your hotel for IMC 2007. Internet Measurement Conference Sponsored by ACM SIGCOMM in cooperation with Usenix October 24-26, 2007 San Diego, CA USA DEADLINES: Book hotel before Sept. 30th to receive discounted rates Please register by Oct.12, 2007 The seventh Internet Measurement Conference (IMC 2007) is a two and one-half day event focusing on networking measurement and analysis. Join us for the latest research on Internet data analysis and its applications. The conference this year will cover a range of topics including security, social networks, wireless networking, routing, topology, applications, and more. This year IMC has expanded its wireless measurement scope, as we adapt to meet the evolving interests of the community. TECHNICAL PROGRAM To view the full technical program, please see: http://www.imconf.net/imc-2007/program.html SPECIAL EVENT - NEW THIS YEAR In addition to the usual technical program, this year there will be a couple of talks on the ethics and legality of network measurement practices among our community. This will be followed by a BoF, in which we will discuss these issues as a community. Invited participants from the law profession as well as privacy experts will join us. We are excited to host this event as these issues are timely. ACCOMODATIONS: The conference will be held in the Paradise Point Resort Hotel on Mission Bay. To receive the discount rate of $205/night for the conference you MUST book your room before September 30th. Please tell them you are with the Internet Measurement Conference to receive our bulk discount rate. After Sept. 30th rooms are not guaranteed and the rate will increase! So please book your reservation promptly. For information on the hotel and how to make a reservation, please see: http://www.imconf.net/imc-2007/venue.html REGISTRATION To register on-line, please go to: http://www.imconf.net/imc-2007/ Please register for IMC no later than Oct. 12th, 2007 we look forward to seeing you soon, from the IMC Steering Committee: Nina Taft, Bruce Maggs Paul Barford Kevin Jeffay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070915/488531f3/attachment.html From rajeevshorey at gmail.com Tue Sep 18 09:20:55 2007 From: rajeevshorey at gmail.com (Rajeev Shorey) Date: Tue, 18 Sep 2007 21:50:55 +0530 Subject: [e2e] ACM SenSys 2007 -- Call for Participation In-Reply-To: <942a90780709180920o59677b36m5c1c86a20ab35db7@mail.gmail.com> References: <942a90780709180913g1f604063yd0a3da7df6a06da0@mail.gmail.com> <942a90780709180915s6a56d26ct437b3d12c2fb942b@mail.gmail.com> <942a90780709180920o59677b36m5c1c86a20ab35db7@mail.gmail.com> Message-ID: <942a90780709180920o1f25df1av503dbc59835ccfda@mail.gmail.com> May we request you to widely circulate the CF Participation of ACM SenSys 2007. ACM SenSys 2007: Call for Participation The 5th ACM Conference on Embedded Networked Sensor Systems November 6-9, 2007 Sydney, Australia http://sensys.acm.org/2007/ ============================================================ Sponsored by ACM SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS and SIGBED. The 5th ACM Conference on Embedded Networked Sensor Systems (SenSys) is a highly selective, single-track forum for the presentation of research results on systems issues in the area of embedded, networked sensors. Distributed systems based on networked sensors and actuators with embedded computation capabilities enable an instrumentation of the physical world at an unprecedented scale and density, thus enabling a new generation of monitoring and control applications. This conference will provide an ideal venue to address the research challenges facing the design, deployment, use, and fundamental limits of these systems. Sensor networks require contributions from many fields, from wireless communication and networking, embedded systems and hardware, distributed systems, data management, and applications, the papers will cover cross-disciplinary work. *Keynote Speaker*: Wednesday, 7 November 2007 Seth Goldstein (CMU), "On the Path Towards Programmable Matter" *Workshops*: Tuesday, 6 November 2007 This year two workshops on current emerging topics in sensor networks will be held in conjunction with SenSys. In addition, there is a Doctoral colloquium. SenseID: Convergence of RFID and Wireless Sensor Networks and their Applications Sensing on Everyday Mobile Phones in Support of Participatory Research SenSys Doctoral Colloquium *"Soap Box" Talks*: A series of 5 minute talks providing strong, controversial, and/or outrageous opinions on a topic within the scope of SenSys, e.g., direction the field should/should not take, future predictions, etc. *SenSys 2007 Organizing Committee:* General Chair: Sanjay Jha (U. New South Wales) Program Co-Chairs: Phillip B. Gibbons (Intel Research), Akos Ledeczi (Vanderbilt) Poster Co-Chairs: Nirupama Bulusu (Portland State), Rachel Cardell-Oliver (U. Western Australia) Demo Co-Chairs: Suman Nath (Microsoft Research), Max Ott (NICTA, Australia) Workshop Chair: Andreas Savvides (Yale) Student Award Chair: Alberto Cerpa (UC Merced) Local Arrangements Chairs: Subhash Challa (U. Technology, Sydney), Salil Kanhere, (U. New South Wales) Publicity Co-Chairs: Rajeev Shorey (GM Research, India), Guoqiang Mao (U. Sydney) Web Chair: Wen Hu (CSIRO, Australia) Registration Chair: Ren Liu (CSIRO, Australia) Publications Chair: Adam Dunkels (SICS) Finance Chair: Chun Tung Chou (U. New South Wales) Steering Committee Chair: John Heidemann (USC) *Program Committee*: Tarek Abdelzaher (UIUC), Gaetano Borriello (U. Washington), Andrew Campbell (Dartmouth), Peter Corke (CSIRO, Australia), Richard Han (U. Colorado), Tian He (U. Minnesota), John Heidemann (USC), Ted Herman (Iowa), Polly Huang (National Taiwan U.), Brad Karp (U. College London), Phil Levis (Stanford), Jie Liu (Microsoft Research), Chenyang Lu (Washington U. in St. Louis), Sam Madden (MIT), Miklos Maroti (U. Szeged, Hungary), Margaret Martonosi (Princeton), Lama Nachman (Intel Research), Kay R?mer (ETH Zurich), Mani Srivastava (UCLA), John Stankovic (U. Virginia), Subhash Suri (UCSB), Thiemo Voigt (SICS, Sweden) *Sponsors*: Academic sponsors: SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS, SIGBED *Corporate sponsors: * Silver: Intel, UNSW, ACORN, CSIRO Bronze: AARNet, NICTA, Archrock, Google, Crossbow All details regarding ACM SenSys 2007, including Preliminary Program, Workshops and Registration can be seen at the following URL: * http://sensys.acm.org/2007/* ** ** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070918/48ef05f1/attachment.html From gdt at gdt.id.au Fri Sep 21 00:18:06 2007 From: gdt at gdt.id.au (Glen Turner) Date: Fri, 21 Sep 2007 16:48:06 +0930 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <7e12cc153d26c4072bc1bf0d5d91a939@mac.com> References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D5B665.6090800@reed.com> <1188454695.3723.23.camel@pc105-c703.uibk.ac.at> <0202239B-D3C8-4AC6-8CEE-B97F79475B2F@nokia.com> <1188550774.3711.97.camel@pc105-c703.uibk.ac.at> <46D80A85.6080707@reed.com> <7e12cc153d26c4072bc1bf0d5d91a939@mac.com> Message-ID: <1190359086.1586.44.camel@roma.44ansell.gdt.id.au> On Fri, 2007-08-31 at 08:07 -0700, rick jones wrote: > On Aug 31, 2007, at 5:33 AM, David P. Reed wrote: > > > It's fascinating to me that Window Scaling (an end-to-end option) > > would be screwed by bugs in *routers*. > > If my experience interacting with end users in netnews is > representative, these "routers" are likely as not the > NAT/firewall/switch boxes like the one sitting between me and my DSL > line at the moment. They get branded with the term "router" all the > time. The problem is well described at http://lwn.net/Articles/92727/ and in the threads at http://oss.sgi.com/archives/netdev/2004-07/msg00146.html http://kerneltrap.org/node/6723 The known faulty equipment is: Cisco PIX NAT feature corrupting in presence of SACK and window scaling. I don't have a Cisco bug ID for that -- the Cisco bug navigator requires the specific version of software to be known to hunt for a bug, which makes finding historical bugs hard. You would presume that people kept their firewall software up-to-date, but the PIX had a bug where it filtered packets with IP.ECN != 00 and that took years to disappear. Linux routers running the Netfilter firewalling package with the tcp-window-tracking module from the Netfilter Patch-o-matic. This bug was fixed in May 2003 http://oss.sgi.com/archives/netdev/2004-07/msg00261.html but made it into a lot of domestic appliance firewall/routers in 2002-4. Workaround is to disable firewall, fix is to upgrade software (which may not be possible since many manufacturers don't support older models and the source code for self-support is often not available, despite the GPL). It is suspected that other faults exist, simply because of the number of bandwidth-shaping middleboxes which munge with the TCP window. Best wishes, Glen