From Jon.Crowcroft at cl.cam.ac.uk Wed Aug 1 01:35:28 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 01 Aug 2007 09:35:28 +0100 Subject: [e2e] low latency multicast trees Message-ID: nowadays we're starting to see soem serious multicast action out there in them thar woods, so maybe its time to re-visit low latency trees (I know most the stuff is IPTV and single source/streamed, but someone is gonna wanna do games any day now) so nowadays we have some pretty good network coordinate systems (often using 13 dimeosnional embeddings etc etc, but pretty good) and though I know the Internet is not a planar graph (repeat after me: The Internet is Not a Planar Graph), it sure looks like one a lot of the time. so gemoetric centered trees using internet coordinate systems to map where all the leaves are and all the potential RPs are? anyone tried it cheers j. oh, ok, this isn't tcp-friendly... and we don't do routing:) From grunwald at cs.colorado.edu Wed Aug 1 06:20:28 2007 From: grunwald at cs.colorado.edu (Dirk Grunwald) Date: Wed, 01 Aug 2007 07:20:28 -0600 Subject: [e2e] low latency multicast trees In-Reply-To: References: Message-ID: <46B0889C.2010303@cs.colorado.edu> Jon Crowcroft wrote: > nowadays we're starting to see soem serious multicast action out there in them thar woods, > so maybe its time to re-visit low latency trees (I know most the stuff is IPTV and single > source/streamed, but someone is gonna wanna do games any day now) > -- I'm assuming you're referring to intra-AS multicast? My impression was that inter-AS multicast wasn't done because (largely) there's no revenue model for it. I was also under the impression that most companies providing TV services were either using PON to duplicate & distribute the bulk of it, or, when using IP layer multicast, carefully engineering the provisioning network (as in the UTOPIA network - http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/35/32917/01541706.pdf ) Are companies really trying to distribute IPTV over the broader internet? From Jon.Crowcroft at cl.cam.ac.uk Wed Aug 1 06:32:20 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 01 Aug 2007 14:32:20 +0100 Subject: [e2e] low latency multicast trees In-Reply-To: <46B0889C.2010303@cs.colorado.edu> References: <46B0889C.2010303@cs.colorado.edu> Message-ID: In missive <46B0889C.2010303 at cs.colorado.edu>, Dirk Grunwald typed: >>Jon Crowcroft wrote: >>> nowadays we're starting to see soem serious multicast action out there in them thar woods, >>> so maybe its time to re-visit low latency trees (I know most the stuff is IPTV and single >>> source/streamed, but someone is gonna wanna do games any day now) >>> -- >>I'm assuming you're referring to intra-AS multicast? My impression was >>that inter-AS multicast wasn't done because (largely) there's no revenue >>model for it. yes intradomain - there are several revenue models for interdomain (just as much as there are reenue models for interdomain unicast) but there's not yet the demand...gotta start somewhere:) >>I was also under the impression that most companies providing TV >>services were either using PON to duplicate & distribute the bulk of it, >>or, when using IP layer multicast, carefully engineering the >>provisioning network (as in the UTOPIA network - >>http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/35/32917/01541706.pdf >>Are companies really trying to distribute IPTV over the broader internet? yes - see PCCW's IPTV in Hong Kong, France Telecom's MaLigne TV, Telefonica's Imagenio in Spain, and AT&T's U-verse for example - these are perfectly serious offerings which work (actually some better than other more "traditional" digital tv stacks) cheers jon From touch at ISI.EDU Thu Aug 2 06:44:27 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 02 Aug 2007 06:44:27 -0700 Subject: [e2e] low latency multicast trees In-Reply-To: References: Message-ID: <46B1DFBB.3000705@isi.edu> Jon Crowcroft wrote: > nowadays we're starting to see soem serious multicast action out there in them thar woods, > so maybe its time to re-visit low latency trees (I know most the stuff is IPTV and single > source/streamed, but someone is gonna wanna do games any day now) People do games using mcast, but through server systems (typically where they control membership and monitor usage). Those systems allow resynchronization - sort of like the way multiparty audio/video used to work before we could do echo cancellation and multi-pane video on endsystems. They've been doing this for quite a while - e.g., from MUDs to things like SimCity. As Dirk noted, a key concern is revenue issues - Dirk highlighted the problem of network provider billing, but the game host sites (e.g., gaming companies) want tight control over their billing too. 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/20070802/d808d705/signature.bin From touch at ISI.EDU Mon Aug 13 19:31:27 2007 From: touch at ISI.EDU (Joe Touch) Date: Mon, 13 Aug 2007 19:31:27 -0700 Subject: [e2e] testing - please ignore Message-ID: <46C113FF.6030905@isi.edu> This is a list test. -------------- 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/20070813/c9b366f3/signature.bin From touch at ISI.EDU Sun Aug 26 01:11:46 2007 From: touch at ISI.EDU (Joe Touch) Date: Sun, 26 Aug 2007 01:11:46 -0700 Subject: [e2e] test (please ignore) Message-ID: <46D135C2.4010802@isi.edu> -------------- 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/20070826/4ab45f1f/signature.bin From detlef.bosau at web.de Mon Aug 27 01:23:55 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 27 Aug 2007 10:23:55 +0200 Subject: [e2e] HARQ Message-ID: <46D28A1B.2050209@web.de> Hi to all. I have some HARQ issues, I do not fully understand. First of all, there are three kinds of HARQ. I do not fully understand the difference between HARQ Type 1 and ordinary ARQ (without a buzzy H in the beginning). The other two types are incremental redundancy and chase combining. Is this correct? Now, HARQ often comes with adaptive channel coding. To my understanding, chase combining requires any sending attempts for one PDU to be coded identically, in particular the MSCS/PS must not be changed for different sending attempts for the same PDU, although the channel properties may change in between. Another concern is whether we have are restricted to a stop and wait scheme with IR / Chase combining. I don?t know a possibility to use sliding window here, because a receiver must know, which received Frames belong to the same original PDU. This is particularly important as I?ve learned that in HSDPA the RLC endpoints are the RNC and the UE. So, there is a transport line (Iub) between RNC and BS introduces storage capacity into the path and which makes the use of a stop?n wait scheme here questionable. Can someone help me out here? Thanks! -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From L.Wood at surrey.ac.uk Mon Aug 27 05:37:45 2007 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Mon, 27 Aug 2007 13:37:45 +0100 Subject: [e2e] HARQ References: <46D28A1B.2050209@web.de> Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316AC7@EVS-EC1-NODE1.surrey.ac.uk> See http://en.wikipedia.org/wiki/Hybrid_ARQ L. Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/ -----Original Message----- From: end2end-interest-bounces at postel.org on behalf of Detlef Bosau Sent: Mon 2007-08-27 9:23 To: end2end-interest list Subject: [e2e] HARQ Hi to all. I have some HARQ issues, I do not fully understand. First of all, there are three kinds of HARQ. I do not fully understand the difference between HARQ Type 1 and ordinary ARQ (without a buzzy H in the beginning). The other two types are incremental redundancy and chase combining. Is this correct? Now, HARQ often comes with adaptive channel coding. To my understanding, chase combining requires any sending attempts for one PDU to be coded identically, in particular the MSCS/PS must not be changed for different sending attempts for the same PDU, although the channel properties may change in between. Another concern is whether we have are restricted to a stop and wait scheme with IR / Chase combining. I don?t know a possibility to use sliding window here, because a receiver must know, which received Frames belong to the same original PDU. This is particularly important as I?ve learned that in HSDPA the RLC endpoints are the RNC and the UE. So, there is a transport line (Iub) between RNC and BS introduces storage capacity into the path and which makes the use of a stop?n wait scheme here questionable. Can someone help me out here? Thanks! -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070827/1fe23026/attachment.html From detlef.bosau at web.de Mon Aug 27 08:31:10 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 27 Aug 2007 17:31:10 +0200 Subject: [e2e] HARQ In-Reply-To: <603BF90EB2E7EB46BF8C226539DFC20701316AC7@EVS-EC1-NODE1.surrey.ac.uk> References: <46D28A1B.2050209@web.de> <603BF90EB2E7EB46BF8C226539DFC20701316AC7@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: <46D2EE3E.20309@web.de> L.Wood at surrey.ac.uk wrote: > > See http://en.wikipedia.org/wiki/Hybrid_ARQ > ;-) I looked at this page before. However, the difference between "old" ARQ and HARQ I becomes not quite clear to me. > . > > Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/ > So, you flood the receiver with a well defined set of blocks and the receiver reports any blocks which are missing? At least, this appears to be the basic idea. Is this correct? Will this work when there blocks of several flows mixed, as it happens on an air interface in mobile networks? Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From L.Wood at surrey.ac.uk Mon Aug 27 09:00:51 2007 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Mon, 27 Aug 2007 17:00:51 +0100 Subject: [e2e] Saratoga was RE: HARQ References: <46D28A1B.2050209@web.de> <603BF90EB2E7EB46BF8C226539DFC20701316AC7@EVS-EC1-NODE1.surrey.ac.uk> <46D2EE3E.20309@web.de> Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316AC9@EVS-EC1-NODE1.surrey.ac.uk> HARQ is just a name for combining ARQ with FEC. Since ARQ (without FEC - see RFC3366) can be done over FEC in a separate higher layer anyway, this is arguably implementation detail to try and increase efficiency by closely combining the two, with incremental redundancy varying repeats to increase likelihood of correct reception from combining coded frames. Yes, Saratoga uses NACKs. It's designed for high utilisation of otherwise unused links in private networks. Two Saratoga peers can multiplex multiple flows between them. Allocation of link capacity between multiple nodes can be done by a MAC layer, or by a coarse scheduling algorithm; this depends on the scenario, and is not specified. Congestion control is optional and not specified; when you own the link, the traffic and the nodes, you can rely on knowledge of your environment and scheduling without congestion control presuming that every errored packet is a loss - again, to try and increase efficiency. Or you could reimplement TCP-Friendly Rate Control (TFRC) to make Saratoga behave like TCP - but DCCP, SCTP and TCP already do that; Saratoga is intended to be useful in environments where those protocols become performance-limited by the prevailing terrestrial-shared-Internet assumptions that make them so useful elsewhere. Saratoga's strengths are TFRC's weaknesses, and vice versa. L. Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/ -----Original Message----- From: Detlef Bosau [mailto:detlef.bosau at web.de] Sent: Mon 2007-08-27 16:31 To: Wood L Dr (Electronic Eng) Cc: end2end-interest at postel.org Subject: Re: [e2e] HARQ L.Wood at surrey.ac.uk wrote: > > See http://en.wikipedia.org/wiki/Hybrid_ARQ > ;-) I looked at this page before. However, the difference between "old" ARQ and HARQ I becomes not quite clear to me. > . > > Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/ > So, you flood the receiver with a well defined set of blocks and the receiver reports any blocks which are missing? At least, this appears to be the basic idea. Is this correct? Will this work when there blocks of several flows mixed, as it happens on an air interface in mobile networks? Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070827/69bf1d60/attachment.html From craig at aland.bbn.com Mon Aug 27 19:25:47 2007 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 27 Aug 2007 22:25:47 -0400 Subject: [e2e] testing... Message-ID: <20070828022547.32FF3123848@aland.bbn.com> Submissions seem to be vanishing into the ether -- sorry for the nuisance! Craig ************************* Chief Scientist, BBN Technologies Outreach Director, GENI Project Office E-mail: craig at aland.bbn.com or craig at bbn.com Phone: +1 517 324 3425 From hgs at CS.COLUMBIA.EDU Mon Aug 27 19:29:56 2007 From: hgs at CS.COLUMBIA.EDU (Henning Schulzrinne) Date: Mon, 27 Aug 2007 22:29:56 -0400 Subject: [e2e] Fwd: Review of the Federal Networking Plan Message-ID: Please contact Dan Reed, not me, for questions or comments. *From: *Jay Vegso > *Date: *August 27, 2007 11:39:48 AM EDT *To: *cra_us at cra.org *Subject: **Review of the Federal Networking Plan* *Reply-To: *jvegso at cra.org [Sent on behalf of Dan Reed, CRA Board Chair, to the Computing Research Association's contacts at academic departments and research labs/centers.] The NSTC Committee on Technology has asked for help in revising the Draft Federal Plan for Advanced Networking Research and Development. This document was developed to provide guidance to Federal agency networking programs on networking research priorities over the next 7-8 years. They seek your views on priority areas of networking research and development. Could you, or someone knowledgeable of networking needs in your organization, please review the draft plan and provide them with comments by September 30, 2007? In January 2007, Dr. John Marburger, Director of OSTP, charged the NSTC Committee on Technology to establish the Interagency Task Force on Advanced Networking (ITFAN). The Charge and Terms of Reference directed ITFAN to develop an interagency Federal Plan for Advanced Networking Research and Development to provide input to the FY 2009 Federal budget planning cycle. A Draft Interim Report was delivered May 15. To finalize this report they are seeking inputs from the wide spectrum of the networking research and development communities including university, Federal laboratory, and commercial researchers and developers. The final report will provide input to the Federal agencies for the FY 2010 and beyond Federal budget planning cycles. The report including the Charge, Terms of Reference, and findings can be found at the Web site: www.nitrd.gov/advancednetworkingplan/ or at: www.nitrd.gov under ?What?s New?, ?Solicitation for comment ?? In addition to providing the Draft Interim Report, this Web site provides guidance and formats for providing comments. They ask that you provide them, by September 30, 2007, your comments, suggestions, and additions on the information and networking research priorities to finalize this report. Your comments and perspective are important to provide a broad understanding and perspective on future networking needs and priorities. Thank you, Dan Reed CRA Board Chair From touch at ISI.EDU Wed Aug 29 01:49:50 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 29 Aug 2007 01:49:50 -0700 Subject: [e2e] GENI Working Groups & First GENI Engineering Conference Message-ID: <46D5332E.9070400@isi.edu> Posted for Craig Partridge... Joe (as list admin) -------------------------------- Dear Colleagues: We'd like to make you aware of two important GENI activities taking place in the coming weeks. First, as you may know, the specification and design of the GENI facility is taking place collaboratively within several working groups. A number of initial working groups completed their efforts during the start of this year, and so with the advent of the GPO and GSC, it was a good time to revamp the working group structure and launch a new set of working groups. The initial structure, governance, and charters for these working groups will be online at www.geni.net within a few days. Staffing and mailing lists are in progress and should be mostly complete by August 17th with work kicking off shortly thereafter. Anyone interested in participating in a working group should subscribe to the geni-announce mailing list, also available via the GENI website, for more information as it becomes available. Please direct questions to Aaron Falk . Second, and related, the GENI Project Office and the Digital Technology Center at the University of Minnesota, with support from NSF, will be hosting the first GENI Engineering Conference October 9-11 in Minneapolis. The conference will combine open meetings of the GENI working groups with plenary sessions of technical presentations and information about the GPO's plans to put out a solicitation for GENI risk-reduction development work late this year. A limited number of grants to support travel to the conference are available. Travel grant applications are due September 4th. Early conference registration closes September 10th. We look forward to seeing you in Minneapolis. For information on the conference and to register, see www.geni.net For announcements of GENI Project Office meetings, solicitations, and other news, register for the (low volume) GENI-announce mail list at . Aaron Falk, Interim Architect, GENI Project Office Craig Partridge, Outreach Director, GENI Project Office From rbriscoe at jungle.bt.co.uk Wed Aug 29 09:23:38 2007 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Wed, 29 Aug 2007 17:23:38 +0100 Subject: [e2e] opening multiple TCP connections getting popular Message-ID: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> e2e-interest folks, This product is being very aggressively marketed: It opens 10 HTTP/TCP connections to accelerate video downloads - essentially using the well-known broken feature of TCP (see the I-D below) to enable one user to compete more aggressively for the same bandwidth against other users. But it flies below the limit of 10 concurrent half open connections added to Windows XP SP2 - claimed to be added to slow down worms but also limiting p2p filesharing clients. Amazingly, these guys are approaching ISPs to re-sell this product - so their customers will just be competing more aggressively with each other and largely end up back where they started. It's worth reading the Business Week article linked off the above page to see just how convincingly this is being marketed - They fooled the technology assessment people in at least one large ISP (mentioning no names). If you're tempted to poke fun at all these people because they clearly don't understand, I actually think we should be chastened ourselves. Why shouldn't app-layer people expect the transport layer to correctly handle fairness? To quote the Internet Draft "Flow Rate Fairness: Dismantling a Religion" "...flow rate fairness isn't even capable of reasoning about questions like, "How many flows is it fair to start between two endpoints? ... ...there will certainly be no solution until the networking community gets its head out of the sand and understands how unrealistic its view is; and how important this issue is--a conflict between the vested interests of real businesses and real people." King Cnut commanded the tide not to wash over him sitting on his throne on the English beach, but at least when the experiment failed he humbly accepted he was subject to greater powers, never wearing his crown again. I'm worrying away at the IETF to work on a proper solution to the TCP-fairness problem, rather than merely issuing the decree that RFC2616 HTTP/1.1 clients should observe a 2 connection limit to each server. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From dpreed at reed.com Wed Aug 29 11:09:41 2007 From: dpreed at reed.com (David P. Reed) Date: Wed, 29 Aug 2007 14:09:41 -0400 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> Message-ID: <46D5B665.6090800@reed.com> It's worth pointing out that this is nothing new. So-called download-accelerators that do exactly that have been around for at least 5 years now, and are extensively used on Windows platforms, because they work as advertised. I think the one I used to use on Windows was called "Lightning Download" and it was freeware. But a deeper question is this: if I want a movie each day, and my daily average rate of consumption is not going to change because I can't watch movies faster than my eyeballs work, why is this going to be a big problem? Is there any evidence of people downloading movies that they don't watch? The mitzvah gained from shorter latencies allows other people to download at their convenience with out me competing with them. In fact, isn't dragging one's download out just maximizing all the users wait time? Maybe the sky isn't falling? Bob Briscoe wrote: > e2e-interest folks, > > This product is being very aggressively marketed: > > It opens 10 HTTP/TCP connections to accelerate video downloads - > essentially using the well-known broken feature of TCP (see the I-D > below) to enable one user to compete more aggressively for the same > bandwidth against other users. But it flies below the limit of 10 > concurrent half open connections added to Windows XP SP2 - claimed to > be added to slow down worms but also limiting p2p filesharing clients. > > Amazingly, these guys are approaching ISPs to re-sell this product - > so their customers will just be competing more aggressively with each > other and largely end up back where they started. It's worth reading > the Business Week article linked off the above page to see just how > convincingly this is being marketed - They fooled the technology > assessment people in at least one large ISP (mentioning no names). > > If you're tempted to poke fun at all these people because they clearly > don't understand, I actually think we should be chastened ourselves. > Why shouldn't app-layer people expect the transport layer to correctly > handle fairness? > > To quote the Internet Draft "Flow Rate Fairness: Dismantling a Religion" > > "...flow rate fairness isn't even capable of reasoning about questions > like, "How many flows is it fair to start between two endpoints? ... > ...there will certainly be no solution until the networking community > gets its head out of the sand and understands how unrealistic its view > is; and how important this issue is--a conflict between the vested > interests of real businesses and real people." > > King Cnut commanded the tide not to wash over him sitting on his > throne on the English beach, but at least when the experiment failed > he humbly accepted he was subject to greater powers, never wearing his > crown again. I'm worrying away at the IETF to work on a proper > solution to the TCP-fairness problem, rather than merely issuing the > decree that RFC2616 HTTP/1.1 clients should observe a 2 connection > limit to each server. > > > Bob > > > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > From Jon.Crowcroft at cl.cam.ac.uk Wed Aug 29 11:54:05 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 29 Aug 2007 19:54:05 +0100 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <46D5B665.6090800@reed.com> References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D5B665.6090800@reed.com> Message-ID: I agree I dont really see the new problem, or any problem at all - every day I have an SSH session, a remote file system mounted and two different browsers - so i have lots of TCP connections mostly from one site to another site, albeit to possibly slightly different machnes (although often all via the ssh tunnel, so via th e same end point) the point is that, like topological DDoS attacks, the crucial point is what share ot the bottleneck piint in the net I get - since in my caser the bottleneck is a 20Mbps DSL line I pay for, i see it is fair, and agnostic of me t, to run as many or few TCP conenctions as I choose over my (I bought it) dsl line, and I see the access ISPs right to choke the line if they have a problem - it is way below the IP or TCP level and is to do with traffic engineering in general how thee trade off between my use of capacity and the service provider's offering of capacity are matched - tcp is not about resource allocation, it is about congestion control which is about avoiding probklems when they arise, not about normal operational cake-slicing imho. bob: you are suffering from what I might call the TCP-delusion, (with apologies to richard dawkings) In missive <46D5B665.6090800 at reed.com>, "David P. Reed" typed: >>It's worth pointing out that this is nothing new. So-called >>download-accelerators that do exactly that have been around for at least >>5 years now, and are extensively used on Windows platforms, because >>they work as advertised. I think the one I used to use on Windows was >>called "Lightning Download" and it was freeware. >> >>But a deeper question is this: if I want a movie each day, and my daily >>average rate of consumption is not going to change because I can't watch >>movies faster than my eyeballs work, why is this going to be a big >>problem? Is there any evidence of people downloading movies that they >>don't watch? >> >>The mitzvah gained from shorter latencies allows other people to >>download at their convenience with out me competing with them. >> >>In fact, isn't dragging one's download out just maximizing all the users >>wait time? >> >>Maybe the sky isn't falling? >> >>Bob Briscoe wrote: >>> e2e-interest folks, >>> >>> This product is being very aggressively marketed: >>> >>> It opens 10 HTTP/TCP connections to accelerate video downloads - >>> essentially using the well-known broken feature of TCP (see the I-D >>> below) to enable one user to compete more aggressively for the same >>> bandwidth against other users. But it flies below the limit of 10 >>> concurrent half open connections added to Windows XP SP2 - claimed to >>> be added to slow down worms but also limiting p2p filesharing clients. >>> >>> Amazingly, these guys are approaching ISPs to re-sell this product - >>> so their customers will just be competing more aggressively with each >>> other and largely end up back where they started. It's worth reading >>> the Business Week article linked off the above page to see just how >>> convincingly this is being marketed - They fooled the technology >>> assessment people in at least one large ISP (mentioning no names). >>> >>> If you're tempted to poke fun at all these people because they clearly >>> don't understand, I actually think we should be chastened ourselves. >>> Why shouldn't app-layer people expect the transport layer to correctly >>> handle fairness? >>> >>> To quote the Internet Draft "Flow Rate Fairness: Dismantling a Religion" >>> >>> "...flow rate fairness isn't even capable of reasoning about questions >>> like, "How many flows is it fair to start between two endpoints? ... >>> ...there will certainly be no solution until the networking community >>> gets its head out of the sand and understands how unrealistic its view >>> is; and how important this issue is--a conflict between the vested >>> interests of real businesses and real people." >>> >>> King Cnut commanded the tide not to wash over him sitting on his >>> throne on the English beach, but at least when the experiment failed >>> he humbly accepted he was subject to greater powers, never wearing his >>> crown again. I'm worrying away at the IETF to work on a proper >>> solution to the TCP-fairness problem, rather than merely issuing the >>> decree that RFC2616 HTTP/1.1 clients should observe a 2 connection >>> limit to each server. >>> >>> >>> Bob >>> >>> >>> ____________________________________________________________________________ >>> >>> Bob Briscoe, Networks Research Centre, BT >>> Research >>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 >>> 645196 >>> >>> cheers jon From Jon.Crowcroft at cl.cam.ac.uk Wed Aug 29 14:44:52 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 29 Aug 2007 22:44:52 +0100 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D5B665.6090800@reed.com> Message-ID: 1. I think one good thing about Bob Briscoe's rant about the fairness religion is that it does question if we should be worrying about it so much - I personally think that the net mainly survives because access links in most the world are slower than the core and servers (and p2p systems) are balanced: if you like, Van's idea of packet conservation applies at the higher level of file transfer/upload v. download, explicitly so in bittorrent's tit-for tat system. 2. I think you are right to suggest people will (and already do) script downloading more videos than they can watch - Netflix and similar services already deliver a standing N films a day to many people who timeout and send some back without viewing; if I have enough storage, i might do the same - On the other hand, if I am part of a video distribution swarm/torrent, then the people that do this will be acting to REDUCE load because they will serve the local subset from the majority of people who just want the nearest uncongested set of servers/peers, so if some fraction of uber-users are greedy, they actually benefit the community in a community based content distribution system (eg. seeds/supernodes/superpeers etc) 3. If (and some places, like japan where I am right now, already have) we move to a lot of fiber to the home, then the edge access speeds may outdistance the core once again (as in the late 80s and early 90s), then the e2e congestion control stuff will be important again - For me there are two parts to the fairness: a) Whether you want proportional, or max min, or some other type of fairness policy - This comes down to different business models, if you are a service provider, and different social policies (market capitalism or welfare state) if you are a government/regulator etc b) Whether its applied on a per user, per session, or per internet-portal (access line) granularity, or even at larger granilarities (institutional) c) The inverse of this is that there has to be a mechanism at each level to prevent sybil/aliasing identity attacks 4. Note: One of the goals in some of the FIND projects working on large scale net virtualisation is to provide different granularity virtual internets... which is good as it says we dont have to argue, but we provide all the parallel universes you want... In missive , "Lachlan Andrew" typed: >>Greetings John, >> >>On 29/08/2007, Jon Crowcroft wrote: >>> tcp is not about resource allocation >> >>So why is there so much talk about ensuring everything is "TCP >>friendly"? The TCP community certainly seems to think TCP is about >>resource allocation, even if the E2E community doesn't. >> >> >> >>My reply to David Reed seems to have been blocked by the e2e's header >>rules (my mailer automatically puts co-recipients like e2e in the "Cc" >>field, which doesn't get through), so here it is again. >> >>Greetings David, >> >>On 29/08/2007, David P. Reed wrote: >>> >>> But a deeper question is this: if I want a movie each day, and my daily >>> average rate of consumption is not going to change because I can't watch >>> movies faster than my eyeballs work, why is this going to be a big >>> problem? Is there any evidence of people downloading movies that they >>> don't watch? >> >>Yes, there is. Just last weekend I was talking to someone who claimed >>that he is morally justified in downloading pirated video because he >>doesn't watch it, and just collects it. >> >>The "limited demand" argument seems to assume: >>1. Video definition doesn't keep getting higher (home IMAX anyone?) >>2. People don't "channel surf", and download 10 different videos just >>to select which to watch >>3. Spikes in demand are no more harmful than smoothed demand. >> >>The same logic can be applied to say that we can use any non-standard >>TCP congestion control, which the IETF is so hesitant to standardize. >> >>Surely it is better to give people an incentive to download movies at >>uncongested times (and not causing undue congestion by their own >>actions). Congestion pricing does just that. >> >>$0.02 >> >>-- >>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 cheers jon From touch at ISI.EDU Wed Aug 29 22:07:00 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 29 Aug 2007 22:07:00 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> Message-ID: <46D65074.9060403@isi.edu> Bob, Bob Briscoe wrote: > e2e-interest folks, > > This product is being very aggressively marketed: > > It opens 10 HTTP/TCP connections to accelerate video downloads - ... > > Amazingly, these guys are approaching ISPs to re-sell this product There have been other companies predicated on similar model - e.g., packeteer. The IETF doesn't do compliance verification, and doesn't issue seals of approval. ... > If you're tempted to poke fun at all these people because they clearly > don't understand, I actually think we should be chastened ourselves. Why > shouldn't app-layer people expect the transport layer to correctly > handle fairness? The issue isn't how many flows are fair. It's whether users can get around such notions by spawning processes, opening multiple sockets, etc. The transport layer is per-connection fair. If you want per user or per parent process fair, you need user/process IDs (which isn't what we have). That's not a protocol issue per se; it creeps deeply into the OS. It also begs the question of what fairness is - and whether you'll need biometrics to enforce this all the way to layers 8, 9, 10, 11, etc. in the stack ;-) If you want per-login fairness, or per port group, or per process group, you can enforce this through RFC2140-style aggregation. It seems like you're bothered by two problems: 1) the IETF doesn't enforce its standards in products 2) TCP fairness doesn't flow up through the OS to a unit you prefer (e.g., a user) Neither one is solvable at the transport layer. 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/20070829/7691a3b1/signature.bin From michael.welzl at uibk.ac.at Wed Aug 29 23:18:15 2007 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 30 Aug 2007 08:18:15 +0200 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D5B665.6090800@reed.com> Message-ID: <1188454695.3723.23.camel@pc105-c703.uibk.ac.at> On Wed, 2007-08-29 at 22:44 +0100, Jon Crowcroft wrote: > 1. I think one good thing about Bob Briscoe's rant about the fairness religion > is that it does question if we should be worrying about it so much - Indeed > I personally think that the net mainly survives because > access links in most the world are slower than the core and servers > (and p2p systems) are balanced: if you like, > Van's idea of packet conservation applies at the higher level of > file transfer/upload v. download, explicitly so in bittorrent's tit-for tat > system. That raises an interesting question: given the fact that different experimental high-speed TCP variants are already widely deployed, and given the fact that the Window Scaling option is not widely used (*), what would happen to the net in the scenario that you sketched of Japan, where fibre to the home is becoming more common, if people would start using the Window Scaling option? Is the net only stable because either your personal access link or the lack of this option limits your sending rate anyway? Cheers, Michael (*) - cf. http://www.icir.org/tbit/TCPevolution-Mar2005.pdf - and we also persistently saw this behavior in PlanetLab Does anybody know if there's a generally known, agreed upon reason for not using Window Scaling? Google tells me that some broken routers can't handle it... but, interestingly, Wikipedia (via google :-) ) tells me that, since kernel version 2.6.8, the option is enabled in Linux by default, and that it's used (by default? don't know) in Vista... so what, are we already heading for trouble? From mellia at tlc.polito.it Thu Aug 30 00:21:07 2007 From: mellia at tlc.polito.it (Marco Mellia) Date: Thu, 30 Aug 2007 09:21:07 +0200 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <1188454695.3723.23.camel@pc105-c703.uibk.ac.at> 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> Message-ID: <46D66FE3.70701@tlc.polito.it> Hi Michael, Just to add a "bit" on the window scaling option, we are continously monitoring our traffic on both our campus LAN and on a commercial ISP provider. As you can see, there is no big change in the percentage of window scaling option sucessfully negotiated in the last year... Polito probe http://tstat.tlc.polito.it/cgi-bin/tstat_rrd.cgi?template=normidx&var=tcp_opts_WS&dir=rrd_data/Polito/LIVE&logscale=&bigpic=true&advopt=true&yauto=false&advcmd=&describe=&hifreq=false&ymin=0 ISP probe http://tstat.tlc.polito.it/cgi-bin/tstat_rrd.cgi?template=normidx&var=tcp_opts_WS&dir=rrd_data/Polito/LIVE&logscale=&bigpic=true&advopt=true&yauto=false&advcmd=&describe=&hifreq=false&ymin=0 Hope this helps. Marco > Does anybody know if there's a generally known, agreed upon reason > for not using Window Scaling? Google tells me that some broken > routers can't handle it... but, interestingly, Wikipedia (via > google :-) ) tells me that, since kernel version 2.6.8, the option > is enabled in Linux by default, and that it's used (by default? don't > know) in Vista... so what, are we already heading for trouble? > > > From detlef.bosau at web.de Thu Aug 30 07:27:06 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 30 Aug 2007 16:27:06 +0200 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <1188454695.3723.23.camel@pc105-c703.uibk.ac.at> 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> Message-ID: <46D6D3BA.6040909@web.de> Michael Welzl wrote: > > > That raises an interesting question: given the fact that different > experimental high-speed TCP variants are already widely deployed, > and given the fact that the Window Scaling option is not widely > used (*), what would happen to the net in the scenario that you > sketched of Japan, where fibre to the home is becoming more common, > if people would start using the Window Scaling option? > > That depend?s on the scenario. Once, I was told that ba a colleague, that enabling Window Saling drastically enhanced his throughput from somewhere in USA to Germany. Interestingly, as it turned out, he used some quite ordinary 600 MBps line as backbone. Now, I think, what?s happened is quite easy to understand. First: Perhaps, this was probably the first time when the DRAM of the installed c*sc* hardware along the path was fully used if not exhausted. To my knowledge, this is called "protection of investment". Second: Any competing users will have loved him for that one, because _he_ _certainly_ achieved high throughput. Basically, TCP congestion control is heterachical without any central, hierachical control So, there are almost necessarily some more or less sophisticated scenarios where TCP congestion control is not that fair than a hierachical, central admission control. You are of course always free to define concrete requirements, if necessary, which can be so implemented then using ressource control and admission control mechanisms. However, this will require more or less complex router support and does not fit exactly into the "orthodox" end to end paradigm, where the "intelligence" of a TCP flow is situated in the end points and not in the intermediate nodes. This is however neither a brand new insight in TCP nor does it cause unbearable grief in all days life. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From rbriscoe at jungle.bt.co.uk Thu Aug 30 07:27:52 2007 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Thu, 30 Aug 2007 15:27:52 +0100 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: References: <46D5B665.6090800@reed.com> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D5B665.6090800@reed.com> Message-ID: <5.2.1.1.2.20070830142121.03fa7b00@pop3.jungle.bt.co.uk> Jon, I think you've jumped to the conclusion I'm saying mulitple TCPs is a problem. I'm not saying that at all - I positively encourage it (in my paper cited in my posting I positively ref your paper on MulTCP) because w TCPs still respond to congestion... But I would only encourage it IFF there's some accountability framework to prevent everyone setting w -> infinity. The posting was criticising those (ie those suffering from the TCP delusion) who say we don't need accountability for the volume of congestion different people cause, because they say TCP shares out capacity fairly. more inline... At 19:54 29/08/2007, Jon Crowcroft wrote: >I agree > >I dont really see the new problem, or any problem at all - > >every day I have an SSH session, a remote file system mounted and two >different browsers >- so i have lots of TCP connections mostly from one site to another site, >albeit >to possibly slightly different machnes (although often all via the ssh >tunnel, so >via th e same end point) > >the point is that, like topological DDoS attacks, the crucial point is >what share >ot the bottleneck piint in the net I get - since in my caser the >bottleneck is a >20Mbps DSL line I pay for, i see it is fair, and agnostic of me t, to run >as many >or few TCP conenctions as I choose over my (I bought it) dsl line, and I >see the >access ISPs right to choke the line if they have a problem - it is way >below the >IP or TCP level and is to do with traffic engineering in general how thee >trade >off between my use of capacity and the service provider's offering of capacity >are matched - tcp is not about resource allocation, it is about congestion >control which is about avoiding probklems when they arise, not about normal >operational cake-slicing imho. 1/ This isn't just an issue between a user and her local ISP. Shifting the focus from your personal DSL use (which is probably to an over-provisioned academic campus at the other end), a typical filesharing user is just as likely to be hitting a bottleneck in another ISP's backhaul (or bottlenecks in both local and remote backhauls). Even if her bottleneck is remote, I'd still like her to be able to behave like w TCPs, but we need a simple accountability framework that allows her own ISP to choke her if she causes excessive congestion, whether the bottleneck is local or remote (which, as you know, is what I've proposed). I think we're agreeing (modulo the misunderstanding about what I was saying the problem was). 2/ If everyone was trying to fill their access link with TCPs (or MulTCP) continuously, the bottlenecks would nearly always NOT be their own lines, no matter how carefully they spread out the traffic. This is in fact close to the current situation - even without everyone participating in p2p filesharing, bottlenecks have already moved out of the lines into the backhaul. So I'd question your assertion that the norm is that you can do what you want within your line limit, and the exception is the ISP should be able to throttle you. Contention is the norm (which I'm sure your contract makes clear). So we need a way to do resource allocation. Yes, TCP is not the answer to this question. But a simple accountability framework that allows users to choose w TCPs AND gives them a reason for not setting w to infinity *is* needed. Are we actually agreed on that too? Bob >bob: you are suffering from what I might call the TCP-delusion, (with >apologies >to richard dawkings) >In missive <46D5B665.6090800 at reed.com>, "David P. Reed" typed: > > >>It's worth pointing out that this is nothing new. So-called > >>download-accelerators that do exactly that have been around for at least > >>5 years now, and are extensively used on Windows platforms, because > >>they work as advertised. I think the one I used to use on Windows was > >>called "Lightning Download" and it was freeware. > >> > >>But a deeper question is this: if I want a movie each day, and my daily > >>average rate of consumption is not going to change because I can't watch > >>movies faster than my eyeballs work, why is this going to be a big > >>problem? Is there any evidence of people downloading movies that they > >>don't watch? > >> > >>The mitzvah gained from shorter latencies allows other people to > >>download at their convenience with out me competing with them. > >> > >>In fact, isn't dragging one's download out just maximizing all the users > >>wait time? > >> > >>Maybe the sky isn't falling? > >> > >>Bob Briscoe wrote: > >>> e2e-interest folks, > >>> > >>> This product is being very aggressively marketed: > >>> > >>> It opens 10 HTTP/TCP connections to accelerate video downloads - > >>> essentially using the well-known broken feature of TCP (see the I-D > >>> below) to enable one user to compete more aggressively for the same > >>> bandwidth against other users. But it flies below the limit of 10 > >>> concurrent half open connections added to Windows XP SP2 - claimed to > >>> be added to slow down worms but also limiting p2p filesharing clients. > >>> > >>> Amazingly, these guys are approaching ISPs to re-sell this product - > >>> so their customers will just be competing more aggressively with each > >>> other and largely end up back where they started. It's worth reading > >>> the Business Week article linked off the above page to see just how > >>> convincingly this is being marketed - They fooled the technology > >>> assessment people in at least one large ISP (mentioning no names). > >>> > >>> If you're tempted to poke fun at all these people because they clearly > >>> don't understand, I actually think we should be chastened ourselves. > >>> Why shouldn't app-layer people expect the transport layer to correctly > >>> handle fairness? > >>> > >>> To quote the Internet Draft "Flow Rate Fairness: Dismantling a Religion" > >>> > >>> "...flow rate fairness isn't even capable of reasoning about questions > >>> like, "How many flows is it fair to start between two endpoints? ... > >>> ...there will certainly be no solution until the networking community > >>> gets its head out of the sand and understands how unrealistic its view > >>> is; and how important this issue is--a conflict between the vested > >>> interests of real businesses and real people." > >>> > >>> King Cnut commanded the tide not to wash over him sitting on his > >>> throne on the English beach, but at least when the experiment failed > >>> he humbly accepted he was subject to greater powers, never wearing his > >>> crown again. I'm worrying away at the IETF to work on a proper > >>> solution to the TCP-fairness problem, rather than merely issuing the > >>> decree that RFC2616 HTTP/1.1 clients should observe a 2 connection > >>> limit to each server. > >>> > >>> > >>> Bob > >>> > >>> > >>> > ____________________________________________________________________________ > >>> > >>> Bob Briscoe, Networks Research Centre, BT > >>> Research > >>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > >>> 645196 > >>> > >>> > > cheers > > jon ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From perfgeek at mac.com Thu Aug 30 07:48:37 2007 From: perfgeek at mac.com (rick jones) Date: Thu, 30 Aug 2007 07:48:37 -0700 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <46D66FE3.70701@tlc.polito.it> 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> <46D66FE3.70701@tlc.polito.it> Message-ID: <501750dd7521cc2411c5d68f23a1d202@mac.com> Is window scaling something one would expect to see negotiated even when the window was going to be less than 65535? rick jones there is no rest for the wicked, yet the virtuous have no pillows From touch at ISI.EDU Thu Aug 30 08:24:41 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 30 Aug 2007 08:24:41 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> Message-ID: <46D6E139.1050202@isi.edu> Lachlan Andrew wrote: > Greetings Joe > > On 29/08/2007, Joe Touch wrote: >> The transport layer is per-connection fair. If you want per user or per >> parent process fair, you need user/process IDs (which isn't what we >> have). That's not a protocol issue per se; it creeps deeply into the OS. >> >> It also begs the question of what fairness is - and whether you'll need >> biometrics to enforce this all the way to layers 8, 9, 10, 11, etc. in >> the stack ;-) If you want per-login fairness, or per port group, or per >> process group, you can enforce this through RFC2140-style aggregation. >> >> It seems like you're bothered by two problems: >> >> 2) TCP fairness doesn't flow up through the OS to >> a unit you prefer (e.g., a user) >> >> Neither one is solvable at the transport layer. > > "Fair" doesn't mean "one size fits all" like current transport-layer > fairness. To me, it means that users to whom an incremental > increase in throughput is more valuable get that incremental increase, > while others who are harmed less by an incremental decrease get that > decrease. > > I thought that Bob's suggestion was simply that the transport/network > layer provide a mechanism for charging based on the congestion caused. > That sort of mechanism *is* "solvable at the transport layer". If we charge based on congestion caused, that's a network layer issue, not transport. First, however, what does that mean? - charge for packets that could compete with others? that could count bytes (if byte-competing), or could count packets (if per-packet competing) - charge extra for packets that actually compete with others? i.e., ones that don't collide are free, but tag anything in the queue when something else gets dropped as "more expensive" when we do the tagging, does it depend on the amount of stuff in the queue? is it proportional to the number of bytes in each packet or the number of packets? - how do we handle packets that are rerouted to avoid congestion? does rerouting incur a penalty even if the new route doesn't incur congestion? There are many issues there; it's not cut-and-dry. Even if we figure that all out, there's a different issue that this is all back-end. We need a way to decide WHO gets the fee... So let's say my app causes a DNS request, then your app uses the cached copy. Does your app incur a fee because it would have caused packets to be injected, but didn't only because mine came first? does that mean my app gets a credit? Even for a single application, we may know which process to charge, but how do we know which user to charge? Again, we're back to biometrics... Overall, the problems here are much harder outside the transport layer than inside. A solution inside the transport layer solves only the most trivial variant, and leaves so many loose ends elsewhere it doesn't put a dent in the overall problem. 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/20070830/93b450a3/signature.bin From rbriscoe at jungle.bt.co.uk Thu Aug 30 08:28:52 2007 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Thu, 30 Aug 2007 16:28:52 +0100 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D65074.9060403@isi.edu> References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> Message-ID: <5.2.1.1.2.20070830160549.03eba678@pop3.jungle.bt.co.uk> Joe, At 06:07 30/08/2007, Joe Touch wrote: >Bob, > >Bob Briscoe wrote: > > e2e-interest folks, > > > > This product is being very aggressively marketed: > > > > It opens 10 HTTP/TCP connections to accelerate video downloads - >... > > > > Amazingly, these guys are approaching ISPs to re-sell this product > >There have been other companies predicated on similar model - e.g., >packeteer. The IETF doesn't do compliance verification, and doesn't >issue seals of approval. > >... > > If you're tempted to poke fun at all these people because they clearly > > don't understand, I actually think we should be chastened ourselves. Why > > shouldn't app-layer people expect the transport layer to correctly > > handle fairness? > >The issue isn't how many flows are fair. It's whether users can get >around such notions by spawning processes, opening multiple sockets, etc. > >The transport layer is per-connection fair. If you want per user or per >parent process fair, you need user/process IDs (which isn't what we >have). That's not a protocol issue per se; it creeps deeply into the OS. This possibly sounds like a misinterpretation of the example I gave in my (very belated) reply (8 Aug) to your tsvwg email on a similar subject. I explained that the solution I propose doesn't rely on identifiers at all. It reveals info about congestion being caused downstream in the headers passing between any two economic entities (whether user and provider or network to neighbouring network). That matches the pairwise bilateral contracts people have. I only brought up the multi-user OS example in that email because I know you're particularly interested in virtualisation. And, even then, I wasn't saying there's a problem doing what I propose in an OS - it's dead easy to do secure accounting across different users on all multi-user OSs I know of. >It also begs the question of what fairness is - and whether you'll need >biometrics to enforce this all the way to layers 8, 9, 10, 11, etc. in >the stack ;-) If you want per-login fairness, or per port group, or per >process group, you can enforce this through RFC2140-style aggregation. > >It seems like you're bothered by two problems: > > 1) the IETF doesn't enforce its standards in > products No - I have no illusions in that direction. My beef is that I'm having trouble getting the IETF to accept that it should do work to produce accountability/fairness protocols in the first place. I merely pointed to RFC2616 HTTP/1.1 decreeing one shouldn't do this, to point out that's really all the IETF has got on fairness (if one looks at TCP in the wider context of being able to open w of them). > 2) TCP fairness doesn't flow up through the OS to > a unit you prefer (e.g., a user) > >Neither one is solvable at the transport layer. Well, I've solved it - with a solution straddling the network layer and the transport layer plus policy control hooks for the app-layer or human-layer to control it - both provider and user. Cheers Bob >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 pganti at gmail.com Thu Aug 30 08:42:21 2007 From: pganti at gmail.com (Paddy Ganti) Date: Thu, 30 Aug 2007 11:42:21 -0400 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <501750dd7521cc2411c5d68f23a1d202@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> <46D66FE3.70701@tlc.polito.it> <501750dd7521cc2411c5d68f23a1d202@mac.com> Message-ID: <2ff1f08a0708300842v2d817c0w3283b10a486fcb1c@mail.gmail.com> Yes. I have seen that because WSCALE is just a representation and can be done in many ways (32 K with no scale is the same as 4K with scaling factor 3 but ultimately you are expressing the same number). On 8/30/07, rick jones wrote: > > Is window scaling something one would expect to see negotiated even > when the window was going to be less than 65535? > > rick jones > there is no rest for the wicked, yet the virtuous have no pillows > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070830/1f2e7149/attachment.html From touch at ISI.EDU Thu Aug 30 08:57:43 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 30 Aug 2007 08:57:43 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> <46D6E139.1050202@isi.edu> Message-ID: <46D6E8F7.3020504@isi.edu> Lachlan Andrew wrote: > Greetings Joe, > > On 30/08/2007, Joe Touch wrote: >> Lachlan Andrew wrote: >>> I thought that Bob's suggestion was simply that the transport/network >>> layer provide a mechanism for charging based on the congestion caused. >>> That sort of mechanism *is* "solvable at the transport layer". >> If we charge based on congestion caused, that's a network layer issue, >> not transport. > > True, the charging is network layer, but letting the application know > how much it is being charged so that it can change its rate is > transport layer, isn't it? It's transport layer if you're charging the app based on what the app sends to the transport. Unfortunately, the network can be just as congested by a retransmission as a first try, so this is network pricing. Although the transport and application may _react_ to it, it is generated (and thus the problem exists) at the network layer. >> First, however, what does that mean? >> >> There are many issues there; it's not cut-and-dry. > > Agreed. The question is whether the IETF should be working to address > those issues, or ignoring them. I've stated before - the IETF isn't the IRTF; some of this is research (i.e., what are the dimensions of the solution). Some of it is also a combination of policy and pricing - neither of which are IETF purvue either. The IETF is a good place to standardize a technical solution once we know what we're solving. At this point, "we need to do something" is insufficient rationale to proceed (and, as others have noted, it's not clear we _need_ to do anything). >> A solution inside the transport layer solves only the most >> trivial variant, and leaves so many loose ends elsewhere it doesn't put >> a dent in the overall problem. > > Can't the same be said for enforcing flow-rate fairness? Excellent point. You'll note that we do nothing to enforce that. The goal is that the network congestion feedback is proportional the number of streams - there's no rule that prevents opening multiple streams (as was noted) or merging them either. The whole thing works mostly because the degenerate case - a stream per packet - is prohibitive. > If that does > more than put a dent in the overall problem, then congestion charging > can make a bigger dent. If flow-rate fairness *doesn't* put more than > a dent in the overall problem, should we forget about "TCP > friendliness"? We don't enforce that either. We encourage that as a general principle, and assume (as above) that so long as the number of TCP streams is roughly proportional to the number of users, things will work fine. They don't work if the number of flows grows with the load; if we get to a point where that actually happens, then maybe we'll need to do somthing. 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/20070830/6d42d897/signature.bin From moore at cs.utk.edu Thu Aug 30 09:16:39 2007 From: moore at cs.utk.edu (Keith Moore) Date: Thu, 30 Aug 2007 12:16:39 -0400 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> Message-ID: <46D6ED67.1040608@cs.utk.edu> [this is a resend...I think the list filtered my mail first time around.] It seems to me that if "fairness" is defined by how well hosts limit the number of concurrent flows then there's a problem with the definition. >From an application's perspective, there are valid reasons for having multiple flows between two endpoints, which don't involve trying to get more bandwidth than is available to other hosts. Ideally there would be little difference in the aggregate bandwidth of 10 flows between two endpoints versus a single flow between those two endpoints. The thing to do is to work on making that so, not by pessimizing multiple flows so that they work as badly as a single flow, but by improving congestion control so that it does a better job of adapting to network conditions while ignoring transient packet losses unrelated to network congestion. And really, hosts/stacks/apps that do a better job of accurately detecting the difference between network congestion and transient packet losses ought to get more bandwidth for their trouble. Otherwise there's a disincentive to implement better algorithms. Keith Bob Briscoe wrote: > e2e-interest folks, > > This product is being very aggressively marketed: > > It opens 10 HTTP/TCP connections to accelerate video downloads - > essentially using the well-known broken feature of TCP (see the I-D > below) to enable one user to compete more aggressively for the same > bandwidth against other users. But it flies below the limit of 10 > concurrent half open connections added to Windows XP SP2 - claimed to > be added to slow down worms but also limiting p2p filesharing clients. > > Amazingly, these guys are approaching ISPs to re-sell this product - > so their customers will just be competing more aggressively with each > other and largely end up back where they started. It's worth reading > the Business Week article linked off the above page to see just how > convincingly this is being marketed - They fooled the technology > assessment people in at least one large ISP (mentioning no names). > > If you're tempted to poke fun at all these people because they clearly > don't understand, I actually think we should be chastened ourselves. > Why shouldn't app-layer people expect the transport layer to correctly > handle fairness? > > To quote the Internet Draft "Flow Rate Fairness: Dismantling a Religion" > > "...flow rate fairness isn't even capable of reasoning about questions > like, "How many flows is it fair to start between two endpoints? ... > ...there will certainly be no solution until the networking community > gets its head out of the sand and understands how unrealistic its view > is; and how important this issue is--a conflict between the vested > interests of real businesses and real people." > > King Cnut commanded the tide not to wash over him sitting on his > throne on the English beach, but at least when the experiment failed > he humbly accepted he was subject to greater powers, never wearing his > crown again. I'm worrying away at the IETF to work on a proper > solution to the TCP-fairness problem, rather than merely issuing the > decree that RFC2616 HTTP/1.1 clients should observe a 2 connection > limit to each server. > > > Bob > > > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > From detlef.bosau at web.de Thu Aug 30 09:36:49 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 30 Aug 2007 18:36:49 +0200 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <501750dd7521cc2411c5d68f23a1d202@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> <46D66FE3.70701@tlc.polito.it> <501750dd7521cc2411c5d68f23a1d202@mac.com> Message-ID: <46D6F221.3070102@web.de> rick jones wrote: > Is window scaling something one would expect to see negotiated even > when the window was going to be less than 65535? > At least to me, this wouldn?t make great sense. However, it would do no real harm. The window would be negotiated with a more coarse granularity, that?s it. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From detlef.bosau at web.de Thu Aug 30 09:49:10 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 30 Aug 2007 18:49:10 +0200 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <5.2.1.1.2.20070830142121.03fa7b00@pop3.jungle.bt.co.uk> References: <46D5B665.6090800@reed.com> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D5B665.6090800@reed.com> <5.2.1.1.2.20070830142121.03fa7b00@pop3.jungle.bt.co.uk> Message-ID: <46D6F506.7010007@web.de> Bob Briscoe wrote: >> > > 1/ This isn't just an issue between a user and her local ISP. Shifting > the focus from your personal DSL use (which is probably to an > over-provisioned academic campus at the other end), a typical > filesharing user is just as likely to be hitting a bottleneck in > another ISP's backhaul (or bottlenecks in both local and remote > backhauls). > > Even if her bottleneck is remote, I'd still like her to be able to > behave like w TCPs, but we need a simple accountability framework that > allows her own ISP to choke her if she causes excessive congestion, > whether the bottleneck is local or remote (which, as you know, is what > I've proposed). Isn?t this exactly, what CC does? If congestion causes harm, i.e. dropped packets, these drops will choke the connection. > > 2/ If everyone was trying to fill their access link with TCPs (or > MulTCP) continuously, the bottlenecks would nearly always NOT be their > own lines, no matter how carefully they spread out the traffic. This > is in fact close to the current situation - even without everyone > participating in p2p filesharing, bottlenecks have already moved out > of the lines into the backhaul. > IIRC, this is one of the Todos, Sally Floyd mentions on her open questions list: Where is the bottleneck? However, stupid me, to my understanding any congestion drop simply throttles the connection. And that?s exactly what we want to do. To my understanding, your point is mainly the target function, you want to optimize, and the fairness criterion. And a pure e2e approach is limited here because the individual socket does not see the big picture of your network, neither your prefered fairness criterion or target function. In some respect, this is similar to the Ethernet capture effect (which was found by Keshav IIRC?). Without any central- / point- /... coordination function / admission control / ressource control, you will most likely find more or less strange cases which cause "surprising" results. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From rbriscoe at jungle.bt.co.uk Thu Aug 30 10:59:17 2007 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Thu, 30 Aug 2007 18:59:17 +0100 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D6E8F7.3020504@isi.edu> References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> <46D6E139.1050202@isi.edu> Message-ID: <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> Joe, At 16:57 30/08/2007, Joe Touch wrote: >Lachlan Andrew wrote: > > Greetings Joe, > > > > On 30/08/2007, Joe Touch wrote: > >> Lachlan Andrew wrote: > >>> I thought that Bob's suggestion was simply that the transport/network > >>> layer provide a mechanism for charging based on the congestion caused. > >>> That sort of mechanism *is* "solvable at the transport layer". > >> If we charge based on congestion caused, that's a network layer issue, > >> not transport. > > > > True, the charging is network layer, but letting the application know > > how much it is being charged so that it can change its rate is > > transport layer, isn't it? > >It's transport layer if you're charging the app based on what the app >sends to the transport. Unfortunately, the network can be just as >congested by a retransmission as a first try, so this is network >pricing. Although the transport and application may _react_ to it, it is >generated (and thus the problem exists) at the network layer. Here's where the transport layer comes in: Policing. Even tho it's "in the network", policing is a transport layer function. We have proposed a bulk per-user policer based on measuring downstream congestion volume (basically a big token bucket of downstream congestion tokens for all flows at once). Despite being bulk across flows, this policer incentivises each flow's end-point transport to take care to manage congestion between themselves within the envelope of the bulk policer. But just because the policer is bulk, doesn't mean it's not transport. The subtle point here is that I haven't actually proposed charging for congestion. Strictly I've proposed how to reveal a generally useful metric at the network layer - downstream congestion volume. Certainly that /could/ be charged for, but that wasn't my motivation... at least not for end-users (because there's loads of evidence users don't like unpredictable pricing etc etc). Instead, we wanted to reveal a metric in network layer headers that would allow inline transport mechanism (policing) to be applied to it, not just out of band (charging, penalties etc). (Hence the need for a metric about the expectation of downstream congestion so it could be policed at the ingress before the packet entered the internetwork.) However, between networks I was motivated by congestion charging or any similar use of the metric (e.g. incorporation in inter-domain SLAs with penalties for exceeding thresholds etc). Strictly, that's application-layer (in the management-plane if that's how you see the world) on top of a network-layer metric. > >> First, however, what does that mean? > >> > >> There are many issues there; it's not cut-and-dry. > > > > Agreed. The question is whether the IETF should be working to address > > those issues, or ignoring them. > >I've stated before - the IETF isn't the IRTF; some of this is research >(i.e., what are the dimensions of the solution). Some of it is also a >combination of policy and pricing - neither of which are IETF purvue either. Of course I'm not expecting the IETF to do the policy, but I am expecting it to provide the protocol that can have policy applied to it. That's very much IETF land. >The IETF is a good place to standardize a technical solution once we >know what we're solving. At this point, "we need to do something" is >insufficient rationale to proceed "We need to do something" is a rather dismissive characterisation of a fully spec'd protocol proposal: I can't win either way. When I put re-ECN to the IETF, everyone didn't understand why it was needed. Now I've explained why it's needed, people complain the IETF doesn't get involved in economics and policy. I'm not asking the IETF to get involved in economics and policy, I'm asking for a bit in a header. The wider industry does the policy. But the IETF needs to state the requirements it understands it is trying to meet. >(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... However, this one has an engineering solution. Of course, the network engineering continues to _work_ with any particular sharing of resources, but that doesn't mean it's 'working' in an economic sense. Consider this: folks at the IETF can expend weeks on whether a certain sentence about the minutiae of a certain protocol field will be a MUST or a SHOULD. But apparently we don't need to spend any time at all on fixing the whole of resource allocation and accountability. > >> A solution inside the transport layer solves only the most > >> trivial variant, and leaves so many loose ends elsewhere it doesn't put > >> a dent in the overall problem. > > > > Can't the same be said for enforcing flow-rate fairness? > >Excellent point. You'll note that we do nothing to enforce that. The >goal is that the network congestion feedback is proportional the number >of streams - there's no rule that prevents opening multiple streams (as >was noted) or merging them either. The whole thing works mostly because >the degenerate case - a stream per packet - is prohibitive. > > > If that does > > more than put a dent in the overall problem, then congestion charging > > can make a bigger dent. If flow-rate fairness *doesn't* put more than > > a dent in the overall problem, should we forget about "TCP > > friendliness"? > >We don't enforce that either. We encourage that as a general principle, >and assume (as above) that so long as the number of TCP streams is >roughly proportional to the number of users, things will work fine. Server farms would get a couple of flows? I think you might mean "roughly proportional to the amount different users are paying for their access". But then, why constrain ourselves so that usage has to be approx proportional to access link capacity? It's much more economically efficient to separate the two: - access capacity is only about peak bit rate - different users have extremely different demands for how much they use their capacity >They >don't work if the number of flows grows with the load; if we get to a >point where that actually happens, then maybe we'll need to do somthing. Indeed, we have got to that point. And what about if the duration of the numerous flows from single users are also hundreds of times longer than those from others (who are paying the same)? Indeed, we have got to that point too. See for instance any graph on distribution of usage between different residential users. E.g. Figs 12 & 13 in Kenjiro Cho's paper on p2p usage in Japan in SGICOMM'06. But anyway, why is it that the IETF can happily expend time on volumes of engineering trivia, but an economic efficiency problem is given a bar hundreds of times higher before the IETF should stir itself into action? If there was a 54% inefficiency in a protocol, the IETF would be in there trying to fix it. But if it's 54% economic inefficiency it's not important? Bob >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 detlef.bosau at web.de Thu Aug 30 11:20:33 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 30 Aug 2007 20:20:33 +0200 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <5.2.1.1.2.20070830160549.03eba678@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070830160549.03eba678@pop3.jungle.bt.co.uk> Message-ID: <46D70A71.2050302@web.de> Bob Briscoe wrote: >> > > This possibly sounds like a misinterpretation of the example I gave in > my (very belated) reply (8 Aug) to your tsvwg email on a similar subject. > > I explained that the solution I propose doesn't rely on identifiers at > all. It reveals info about congestion being caused downstream in the > headers passing between any two economic entities (whether user and > provider or network to neighbouring network). That matches the > pairwise bilateral contracts people have. > Do they? Always? And if so, why don?t you use the Congestion Manager (IIRC Seshan et al.?) or similar techniques in those situations? -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From rbriscoe at jungle.bt.co.uk Thu Aug 30 11:13:39 2007 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Thu, 30 Aug 2007 19:13:39 +0100 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D6F506.7010007@web.de> References: <5.2.1.1.2.20070830142121.03fa7b00@pop3.jungle.bt.co.uk> <46D5B665.6090800@reed.com> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D5B665.6090800@reed.com> <5.2.1.1.2.20070830142121.03fa7b00@pop3.jungle.bt.co.uk> Message-ID: <5.2.1.1.2.20070830190344.041c1cb0@pop3.jungle.bt.co.uk> Detlef, Yes, congestion control deals with congestion anywhere on the path which is correct. And your ISP should be able to limit you based on total volume of congestion you cause anywhere on the paths you are using (acting on behalf of the other networks). But at present, your ISP only knows about congestion in its own network. The proposal I've made allows it to know about congestion on the e2e path.... And it allows yuor ISP to know about how much congestion is upstream and how much downstream of any point. So other networks can use this metric in SLAs to make it want to act on their behalf. All using 1 bit in the IP header along with the ECN field, but without changing any existing network elements. Probably best to read the proposal I've made. Choose a paper from with a description that best matches your interest. Bob At 17:49 30/08/2007, Detlef Bosau wrote: >Bob Briscoe wrote: >> >>1/ This isn't just an issue between a user and her local ISP. Shifting >>the focus from your personal DSL use (which is probably to an >>over-provisioned academic campus at the other end), a typical filesharing >>user is just as likely to be hitting a bottleneck in another ISP's >>backhaul (or bottlenecks in both local and remote backhauls). >> >>Even if her bottleneck is remote, I'd still like her to be able to behave >>like w TCPs, but we need a simple accountability framework that allows >>her own ISP to choke her if she causes excessive congestion, whether the >>bottleneck is local or remote (which, as you know, is what I've proposed). >Isn?t this exactly, what CC does? If congestion causes harm, i.e. dropped >packets, these drops will choke the connection. > >> >>2/ If everyone was trying to fill their access link with TCPs (or MulTCP) >>continuously, the bottlenecks would nearly always NOT be their own lines, >>no matter how carefully they spread out the traffic. This is in fact >>close to the current situation - even without everyone participating in >>p2p filesharing, bottlenecks have already moved out of the lines into the >>backhaul. > >IIRC, this is one of the Todos, Sally Floyd mentions on her open questions >list: Where is the bottleneck? > >However, stupid me, to my understanding any congestion drop simply >throttles the connection. And that?s exactly what we want to do. > >To my understanding, your point is mainly the target function, you want to >optimize, and the fairness criterion. > >And a pure e2e approach is limited here because the individual socket does >not see the big picture of your network, neither your prefered fairness >criterion or target function. > >In some respect, this is similar to the Ethernet capture effect (which was >found by Keshav IIRC?). >Without any central- / point- /... coordination function / admission >control / ressource control, you will most likely find more or less >strange cases which cause "surprising" results. > >Detlef > >-- >Detlef Bosau Mail: detlef.bosau at web.de >Galileistrasse 30 Web: http://www.detlef-bosau.de >70565 Stuttgart Skype: detlef.bosau >Mobile: +49 172 681 9937 > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From rbriscoe at jungle.bt.co.uk Thu Aug 30 16:05:16 2007 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Fri, 31 Aug 2007 00:05:16 +0100 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D70A71.2050302@web.de> References: <5.2.1.1.2.20070830160549.03eba678@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070830160549.03eba678@pop3.jungle.bt.co.uk> Message-ID: <5.2.1.1.2.20070830234406.02a6b088@pop3.jungle.bt.co.uk> Detlef, At 19:20 30/08/2007, Detlef Bosau wrote: >Bob Briscoe wrote: >> >>This possibly sounds like a misinterpretation of the example I gave in my >>(very belated) reply (8 Aug) to your tsvwg email on a similar subject. >> >>I explained that the solution I propose doesn't rely on identifiers at >>all. It reveals info about congestion being caused downstream in the >>headers passing between any two economic entities (whether user and >>provider or network to neighbouring network). That matches the pairwise >>bilateral contracts people have. > >Do they? > >Always? Give an example where they don't? Trilateral (or worse) contracts are rarely if ever entered into by any party with any desire to apportion blame for failings. Note that multiple bilateral contracts with different parties for components of the same service are still all bilateral. >And if so, why don?t you use the Congestion Manager (IIRC Seshan et al.?) >or similar techniques in those situations? I assume by "those situations" you mean where an end-user has mulitple connections being policed in bulk by her provider. Indeed, a superficially CM-like object would become v relevant to manage the tradeoffs between different connections. But it wouldn't actually be doing the same thing as the CM. The CM was only across connections to the same remote endpoint (I believe), to ensure one connection benefited from knowledge other connections had gleaned about the same path (although endpoints are never sure two connections share the same path because of the prevalence of equal cost multipath routing). The thing that would be needed across all a user's connections in my case would be best described as a policy mediator. It would have to track the remaining allowance the policer contained and ensure that each connection was weighted to get the most out of this policed access over time (taking into account how each app might have weighted its own connections). It wouldn't need to be monitoring paths like the CM does. Bob >-- >Detlef Bosau Mail: detlef.bosau at web.de >Galileistrasse 30 Web: http://www.detlef-bosau.de >70565 Stuttgart Skype: detlef.bosau >Mobile: +49 172 681 9937 > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From lars.eggert at nokia.com Thu Aug 30 19:08:10 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Fri, 31 Aug 2007 11:08:10 +0900 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <1188454695.3723.23.camel@pc105-c703.uibk.ac.at> 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> Message-ID: <0202239B-D3C8-4AC6-8CEE-B97F79475B2F@nokia.com> On 2007-8-30, at 15:18, ext Michael Welzl wrote: > Does anybody know if there's a generally known, agreed upon reason > for not using Window Scaling? Google tells me that some broken > routers can't handle it... but, interestingly, Wikipedia (via > google :-) ) tells me that, since kernel version 2.6.8, the option > is enabled in Linux by default, and that it's used (by default? don't > know) in Vista... so what, are we already heading for trouble? Microsoft presented their findings related to window scaling (and several other TCP extensions) at the IETF TSVAREA meeting in Prague. See http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld3.htm and the two following slides. Summary: Window scaling is enabled in Vista, but limited to a factor of 2. PPT slides are here: http://www3.ietf.org/proceedings/07mar/slides/ tsvarea-3/tsvarea-3.ppt Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070831/42494488/smime.bin From touch at ISI.EDU Fri Aug 31 00:00:08 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 31 Aug 2007 00:00:08 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> References: <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: <46D7BC78.6030106@isi.edu> Bob (et al), There are completely separate things at play here: - a mechanism to gate traffic into the net transport, app, or otherwise - a mechanism to penalize use that causes congestion that needs to go proportionally back to the source Whether to use TCP or something else for the former, the two are separate. Gating functions are "per-something" fair, and you need to flow that tag all the way down from its source (e.g., the user, the process, etc.). Once you have that, it's the gating mechanism isn't important. I.e., AFAICT, to make "flow rate fairness" work, you need something outside the transport layer to determine how to group things that are penalized as a group. If you do that, you don't need FRF's new transport mechanism necessarily. ... >> The IETF is a good place to standardize a technical solution once we >> know what we're solving. At this point, "we need to do something" is >> insufficient rationale to proceed > > "We need to do something" is a rather dismissive characterisation of a > fully spec'd protocol proposal: > "we need to do something" isn't a sufficient motivation. It's irrelevant what the "something" you need to do is; the deficit is in the motivation. > I can't win either way. When I put re-ECN to the IETF, everyone didn't > understand why it was needed. Now I've explained why it's needed, people > complain the IETF doesn't get involved in economics and policy. I'm not > asking the IETF to get involved in economics and policy, I'm asking for > a bit in a header. The wider industry does the policy. But the IETF > needs to state the requirements it understands it is trying to meet. The point appears to be that the bit in the header is the least of the issues; without the broader mechanisms at the policy level that flow up to the app/user, the bit isn't sufficient. With that broader mechanism, the bit may not be necessary. >> (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. On a final note: > Consider this: folks at the IETF can expend weeks on whether a certain > sentence about the minutiae of a certain protocol field will be a MUST > or a SHOULD. But apparently we don't need to spend any time at all on > fixing the whole of resource allocation and accountability. IMO, a specific proposal at the transport layer doesn't solve the whole of resource allocation and accountability either. The transport layer isn't the crux of that problem - it's all the other layers for which we don't agree how to proceed yet. 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/20070831/f7df3fba/signature.bin From michael.welzl at uibk.ac.at Fri Aug 31 01:59:34 2007 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Fri, 31 Aug 2007 10:59:34 +0200 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <0202239B-D3C8-4AC6-8CEE-B97F79475B2F@nokia.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> Message-ID: <1188550774.3711.97.camel@pc105-c703.uibk.ac.at> On Fri, 2007-08-31 at 11:08 +0900, Lars Eggert wrote: > On 2007-8-30, at 15:18, ext Michael Welzl wrote: > > Does anybody know if there's a generally known, agreed upon reason > > for not using Window Scaling? Google tells me that some broken > > routers can't handle it... but, interestingly, Wikipedia (via > > google :-) ) tells me that, since kernel version 2.6.8, the option > > is enabled in Linux by default, and that it's used (by default? don't > > know) in Vista... so what, are we already heading for trouble? > > Microsoft presented their findings related to window scaling (and > several other TCP extensions) at the IETF TSVAREA meeting in Prague. > See http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld3.htm > and the two following slides. Summary: Window scaling is enabled in > Vista, but limited to a factor of 2. > > PPT slides are here: http://www3.ietf.org/proceedings/07mar/slides/ > tsvarea-3/tsvarea-3.ppt Thanks, that's very interesting! (and thanks to David Ros too, who also pointed me to these slides in a private email) So ... the reasons they give are bugs, bugs, bugs. I guess this means that we are facing a world where working on congestion control is rather pointless because: 1) either your personal bottleneck is the limit (and all you care about is that your flows fairly share it, at least within reasonable boundaries), or 2) (in Japan, as Jon said, or maybe our future networks or some other special cases) the receiver window is the limit. The reason for 2) is the lack of (proper) use of window scaling, which is due to bugs in firewalls, routers etc. That's pathetic. What can we do about it? Stop worrying about CUBIC vs HTCP vs FAST vs WHATEVERTCP, and shut down ICCRG? Maybe we should dedicate our time to sending emails to the people responsible for these bugs instead of doing research on congestion control. Wow... I'm normally an optimistic person, but that perspective truly depresses me. Cheers, Michael From moore at cs.utk.edu Fri Aug 31 04:31:51 2007 From: moore at cs.utk.edu (Keith Moore) Date: Fri, 31 Aug 2007 07:31:51 -0400 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <1188550774.3711.97.camel@pc105-c703.uibk.ac.at> 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> Message-ID: <46D7FC27.8030106@cs.utk.edu> >> PPT slides are here: http://www3.ietf.org/proceedings/07mar/slides/ >> tsvarea-3/tsvarea-3.ppt >> > > Thanks, that's very interesting! (and thanks to David Ros too, > who also pointed me to these slides in a private email) > > So ... the reasons they give are bugs, bugs, bugs. > not just bugs, but bugs in devices that violate the e2e and layering model because they are components of the network that mess with protocol elements that are supposed to be opaque to the network. related problems include: that their (dys)functions are not easily observable by the parties affected by them (i.e. they can't easily determine what device is screwing up their applications), and similarly, there's no good way for the parties who are responsible for installing such devices to learn that the devices are screwing with applications. it is arguable that there need to be some guidelines for implementors of such devices. but IETF has always had a difficult time making recommendations for how to violate their protocols in such a way as to minimize harm. (e.g. "if you must do this evil thing, do it this way rather than this other way"). from an IRTF perspective, maybe it would be useful for someone to collect information about failures caused by devices of this sort, analyze the reasons for these failures, and determine whether there are ways for such devices to do what they intend to do without causing unintended failures. also it would be useful to see whether there are ways for failures caused by such devices to become more visible/accountable to endpoints, or for those failures to become more visible to the maintainers for such devices. I don't think that this means that work on congestion control etc. is hopeless - I think it means that vendors need to learn how to implement intermediaries that rarely cause failures that aren't intended as a matter of policy, and also how to arrange things that when such failures do occur that the endpoints can recover from them. From michael.welzl at uibk.ac.at Fri Aug 31 04:46:45 2007 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Fri, 31 Aug 2007 13:46:45 +0200 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D7FC27.8030106@cs.utk.edu> 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> <46D7FC27.8030106@cs.utk.edu> Message-ID: <1188560805.3711.123.camel@pc105-c703.uibk.ac.at> > from an IRTF perspective, maybe it would be useful for someone to > collect information about failures caused by devices of this sort, > analyze the reasons for these failures, and determine whether there are > ways for such devices to do what they intend to do without causing > unintended failures. also it would be useful to see whether there are > ways for failures caused by such devices to become more > visible/accountable to endpoints, or for those failures to become more > visible to the maintainers for such devices. That's a great recommendation, and a constructive way forward! Thanks! > I don't think that this means that work on congestion control etc. is > hopeless - I think it means that vendors need to learn how to implement > intermediaries that rarely cause failures that aren't intended as a > matter of policy, and also how to arrange things that when such failures > do occur that the endpoints can recover from them. Right.... thanks again for your wise words! Cheers, Michael From touch at ISI.EDU Fri Aug 31 05:08:46 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 31 Aug 2007 05:08:46 -0700 Subject: [e2e] note regarding possibly lost posts Message-ID: <46D804CE.9090305@isi.edu> Hi, all, The end2end-interest list experienced a software malfunction that may have lost some posts that would be "held for approval". The error was caused by an interaction between versions of Mailman and Python software, and has been corrected. You can verify whether a post has been successful by checking our on-line logs at: http://www.postel.org/pipermail/end2end-interest/ If not, please repost. Thanks, and sorry for the inconvenience, Joe (as list admin) -------------- 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/20070831/98bb2ce3/signature.bin From dpreed at reed.com Fri Aug 31 05:33:09 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 31 Aug 2007 08:33:09 -0400 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <1188550774.3711.97.camel@pc105-c703.uibk.ac.at> 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> Message-ID: <46D80A85.6080707@reed.com> It's fascinating to me that Window Scaling (an end-to-end option) would be screwed by bugs in *routers*. If literally true about network layer routers, what that means is that the whole design of the Internet is now beyond modification, since the modularity that modification depends on cannot be presumed. So I'm even more depressed than Michael. But I'd suggest that there's a third option, one I've advocated before. Use the basic strategy that gave us the Internet again, on top of today's broken Internet. Build a new, properly modularized, fully interoperable network layered on top of today's broken Internet. One would think there were enough stakeholders in doing this that a consortium of like-minded people could get critical mass across the "users" (end device makers, applicaiton providers, ...). They nust need to agree to support each other like Odysseus was supported when he was tied to the mast, blindfolded etc. to avoid the Sirens. The Sirens in this case are the Ciscos and the transport providers who say - don't go away from our "locked-in" unchangeable current products and services that run raw IP through hard-microcoded switches and pipes and TOEs, etc. Don't go away because although you can't make the Internet better, WE can make it faster. If you listen to the Sirens, you get a really great dragster experience, but cars that can maneuver, adapt to new environments - why would you want to evolve pure perfection? The Internet is indeed the Best of All Possible Worlds. Michael Welzl wrote: > On Fri, 2007-08-31 at 11:08 +0900, Lars Eggert wrote: > >> On 2007-8-30, at 15:18, ext Michael Welzl wrote: >> >>> Does anybody know if there's a generally known, agreed upon reason >>> for not using Window Scaling? Google tells me that some broken >>> routers can't handle it... but, interestingly, Wikipedia (via >>> google :-) ) tells me that, since kernel version 2.6.8, the option >>> is enabled in Linux by default, and that it's used (by default? don't >>> know) in Vista... so what, are we already heading for trouble? >>> >> Microsoft presented their findings related to window scaling (and >> several other TCP extensions) at the IETF TSVAREA meeting in Prague. >> See http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld3.htm >> and the two following slides. Summary: Window scaling is enabled in >> Vista, but limited to a factor of 2. >> >> PPT slides are here: http://www3.ietf.org/proceedings/07mar/slides/ >> tsvarea-3/tsvarea-3.ppt >> > > Thanks, that's very interesting! (and thanks to David Ros too, > who also pointed me to these slides in a private email) > > So ... the reasons they give are bugs, bugs, bugs. > > I guess this means that we are facing a world where working > on congestion control is rather pointless because: > 1) either your personal bottleneck is the limit (and all > you care about is that your flows fairly share it, > at least within reasonable boundaries), or > 2) (in Japan, as Jon said, or maybe our future networks > or some other special cases) the receiver window is the > limit. > > The reason for 2) is the lack of (proper) use of window > scaling, which is due to bugs in firewalls, routers etc. > > That's pathetic. What can we do about it? Stop worrying about > CUBIC vs HTCP vs FAST vs WHATEVERTCP, and shut down ICCRG? > Maybe we should dedicate our time to sending emails to the > people responsible for these bugs instead of doing research > on congestion control. > > Wow... I'm normally an optimistic person, but that perspective > truly depresses me. > > Cheers, > Michael > > > > From david.borman at windriver.com Fri Aug 31 06:11:10 2007 From: david.borman at windriver.com (David Borman) Date: Fri, 31 Aug 2007 08:11:10 -0500 Subject: [e2e] [SPAM] opening multiple TCP connections getting popular In-Reply-To: <46D6F221.3070102@web.de> 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> <46D66FE3.70701@tlc.polito.it> <501750dd7521cc2411c5d68f23a1d202@mac.com> <46D6F221.3070102@web.de> Message-ID: <6D187A83-09F6-4670-8C2D-D124D3AF72F4@windriver.com> Outside of other information, I've always used a default window scaling factor of 4, because that gives you the potential for a 1GB window and the granularity of the window is only 16 bytes. If you don't negotiate window scaling up front, you are stuck with a 64K maximum window for the duration of the connection. Besides, windows have always been updated on a coarse granularity, due to Silly Window Syndrome avoidance. -David Borman On Aug 30, 2007, at 11:36 AM, Detlef Bosau wrote: > rick jones wrote: >> Is window scaling something one would expect to see negotiated >> even when the window was going to be less than 65535? >> > > At least to me, this wouldn?t make great sense. However, it would > do no real harm. The window would be negotiated with a more coarse > granularity, that?s it. > > Detlef > > > -- > Detlef Bosau Mail: detlef.bosau at web.de > Galileistrasse 30 Web: http://www.detlef- > bosau.de > 70565 Stuttgart Skype: detlef.bosau > Mobile: +49 172 681 9937 > > From mathis at psc.edu Fri Aug 31 07:38:38 2007 From: mathis at psc.edu (Matt Mathis) Date: Fri, 31 Aug 2007 10:38:38 -0400 (EDT) Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <1188550774.3711.97.camel@pc105-c703.uibk.ac.at> 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> Message-ID: I believe that default window scales for Windows Vista and the Linux mainline source are 7 and 6 respectively, except for IE, which sets it down as indicated in the slides. This is large enough to support 1 Gb/s on moderate paths (10 of ms) or 100 Mb/s on global scale paths. It remains to be seen if the early adopters can apply enough pressure to get enough of the bugs corrected, before the masses force more conservative configurations. Hint: use large window scales, and report problems, NOW. Unfortunately the most insidious bugs are home NAT/security boxes that pass the WSCALE option w/o parsing it, and then toss segments that seem to be out of window, because the unscaled window is less than 1500 Bytes. This bug is insidious because these particular boxes were marketed to non-clued home users, who have no hope of figuring out why they can not connect to sites attempting to actually fill their high speed links. I actually think making the browser use small WSCALE is an excellent migration strategy because then the clueless users retain the ability to browse help and download diagnostic tools.... I assume it will be phased out at some point. I wish I had seen the talk in Pague. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Fri, 31 Aug 2007, Michael Welzl wrote: > On Fri, 2007-08-31 at 11:08 +0900, Lars Eggert wrote: > > On 2007-8-30, at 15:18, ext Michael Welzl wrote: > > > Does anybody know if there's a generally known, agreed upon reason > > > for not using Window Scaling? Google tells me that some broken > > > routers can't handle it... but, interestingly, Wikipedia (via > > > google :-) ) tells me that, since kernel version 2.6.8, the option > > > is enabled in Linux by default, and that it's used (by default? don't > > > know) in Vista... so what, are we already heading for trouble? > > > > Microsoft presented their findings related to window scaling (and > > several other TCP extensions) at the IETF TSVAREA meeting in Prague. > > See http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld3.htm > > and the two following slides. Summary: Window scaling is enabled in > > Vista, but limited to a factor of 2. > > > > PPT slides are here: http://www3.ietf.org/proceedings/07mar/slides/ > > tsvarea-3/tsvarea-3.ppt > > Thanks, that's very interesting! (and thanks to David Ros too, > who also pointed me to these slides in a private email) > > So ... the reasons they give are bugs, bugs, bugs. > > I guess this means that we are facing a world where working > on congestion control is rather pointless because: > 1) either your personal bottleneck is the limit (and all > you care about is that your flows fairly share it, > at least within reasonable boundaries), or > 2) (in Japan, as Jon said, or maybe our future networks > or some other special cases) the receiver window is the > limit. > > The reason for 2) is the lack of (proper) use of window > scaling, which is due to bugs in firewalls, routers etc. > > That's pathetic. What can we do about it? Stop worrying about > CUBIC vs HTCP vs FAST vs WHATEVERTCP, and shut down ICCRG? > Maybe we should dedicate our time to sending emails to the > people responsible for these bugs instead of doing research > on congestion control. > > Wow... I'm normally an optimistic person, but that perspective > truly depresses me. > > Cheers, > Michael > > From perfgeek at mac.com Fri Aug 31 08:07:06 2007 From: perfgeek at mac.com (rick jones) Date: Fri, 31 Aug 2007 08:07:06 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D80A85.6080707@reed.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> Message-ID: <7e12cc153d26c4072bc1bf0d5d91a939@mac.com> 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. Of course that is just speculation on my part; email to the presentation authors (found on slide 1) would probably be a good way to find-out for certain. It would also be a good way to find-out if the bugs found were reported to their respective vendors. rick jones Wisdom teeth are impacted, people are affected by the effects of events From dpreed at reed.com Fri Aug 31 08:20:43 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 31 Aug 2007 11:20:43 -0400 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: <46D831CB.2010008@reed.com> 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. > Indeed, it may well be that. Nonetheless my points hold true. Also about the "Sirens" including major router vendors. I still recall my face-to-face interaction many years ago on a panel with Sr. Cisco marketing VP who was claiming that NAT was an Internet Standard when NAT boxes were coming out. I told her that it was *not*, that Internet Standards were very few, and that NAT was an RFC because it was considered as an option to the IPv6 choice, and was a *discarded* option, with known limitations. She essentially flamed me back, said that Cisco defined the Internet, and I didn't know what I was talking about, and anyway "NAT" was a Good Thing. From Anil.Agarwal at viasat.com Fri Aug 31 09:12:14 2007 From: Anil.Agarwal at viasat.com (Agarwal, Anil) Date: Fri, 31 Aug 2007 12:12:14 -0400 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <0202239B-D3C8-4AC6-8CEE-B97F79475B2F@nokia.com> Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0658082DE@VGAEXCH01.hq.corp.viasat.com> Lars wrote: > > On 2007-8-30, at 15:18, ext Michael Welzl wrote: > > Does anybody know if there's a generally known, agreed upon > reason for > > not using Window Scaling? Google tells me that some broken routers > > can't handle it... but, interestingly, Wikipedia (via google :-) ) > > tells me that, since kernel version 2.6.8, the option is enabled in > > Linux by default, and that it's used (by default? don't > > know) in Vista... so what, are we already heading for trouble? > > Microsoft presented their findings related to window scaling > (and several other TCP extensions) at the IETF TSVAREA > meeting in Prague. > See http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld3.htm > and the two following slides. Summary: Window scaling is > enabled in Vista, but limited to a factor of 2. > 1. What are the default and maximum receive and transmit window size values of Linux 2.6.x, Windows and Vista? If they are less than 64 kbytes, then enabling window scaling does not accomplish much, except for applications that explicitly configure large maximum window sizes both at the transmitter and the receiver. 2. Assuming that all routers, firewalls, etc. get fixed (LoL) and can handle TCP packets with window scaling correctly, what would we suggest the default and maximum TCP window values be? Is the "Internet" robust enough to handle a maximum TCP window size of, say, 10 Mbytes for every TCP connection? Will existing TCP congestion control mechanisms (RFC2581) and existing router implementations and configurations (tail drop, RED?, ECN?, buffer sizes, etc.) suffice (ignoring issues of fairness for the time being, with apologies to Bob Briscoe)? Regards, Anil Anil Agarwal ViaSat Inc. 20511 Seneca Meadows Parkway, Suite 200 Germantown, MD 20876 Anil.Agarwal at viasat.com 240-686-4404 ViaSat Brings your Network to Life From detlef.bosau at web.de Fri Aug 31 09:58:48 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 31 Aug 2007 18:58:48 +0200 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D831CB.2010008@reed.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> <46D831CB.2010008@reed.com> Message-ID: <46D848C8.5030000@web.de> David P. Reed wrote: > > She essentially flamed me back, said that Cisco defined the Internet, > and I didn't know what I was talking about, and anyway "NAT" was a > Good Thing. Excuse me but she must be wrong there. Some years ago (I think about the Y2K disaster which never really happend) some german TV features claimed that Bill Gates defined the Internet.... (no, _I_ did _not_ so claim, don?t blame me for that....) -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From huitema at windows.microsoft.com Fri Aug 31 09:50:20 2007 From: huitema at windows.microsoft.com (Christian Huitema) Date: Fri, 31 Aug 2007 09:50:20 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D831CB.2010008@reed.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> <46D831CB.2010008@reed.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06405968893@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> > > 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. > > > Indeed, it may well be that. Nonetheless my points hold true. Also > about the "Sirens" including major router vendors. Consider the Internet as an evolving ecosystem. The members of that ecosystem are engaged in an evolutionary process. It is influenced by external factors, mostly the evolution of electronics following Moore's law, and the evolution of regulations following globalization and various influences. The evolution is constrained by the installed base, as new systems can only flourish if they successfully adapt to that base. At the same time, each new system pushes the evolution forward. That is how you end up with NAT and Skype, web services and peer-to-peer, various forms of co-evolution, etc. At some point, the past developments preclude the future evolution. That may well be happening already for TCP. The knowledge of TCP is engrained in many systems that have "adapted" to it. These systems "know" a form of TCP as it was used in the past 10 years, and react poorly to deviations. So it may well be that we cannot evolve TCP anymore, at least on IPv4. We may have a chance on IPv6, because the "routers" do not support IPv6 yet, and would need to adapt to whatever is the prevalent form of IPv6/TCP when they come on the market. But I would not hold my breath for too long. In that context, using multiple TCP connections is a logical response from the "software" side of the ecosystem. It is indeed what BitTorrent has been doing for some time. The other plausible response would be to develop a new transport. Of course, since "routers" will block any IP payload type that they don't understand, we probably will need to first deploy the new transport on top of UDP, and wait until sufficient adoption to present a new payload type as an "optimization". -- Christian Huitema From faber at ISI.EDU Fri Aug 31 10:33:52 2007 From: faber at ISI.EDU (Ted Faber) Date: Fri, 31 Aug 2007 10:33:52 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D848C8.5030000@web.de> References: <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> <46D831CB.2010008@reed.com> <46D848C8.5030000@web.de> Message-ID: <20070831173352.GB1540@hut.isi.edu> On Fri, Aug 31, 2007 at 06:58:48PM +0200, Detlef Bosau wrote: > David P. Reed wrote: > > > >She essentially flamed me back, said that Cisco defined the Internet, > >and I didn't know what I was talking about, and anyway "NAT" was a > >Good Thing. > > Excuse me but she must be wrong there. > > Some years ago (I think about the Y2K disaster which never really > happend) some german TV features claimed that Bill Gates defined the > Internet.... (no, _I_ did _not_ so claim, don?t blame me for that....) Actually it was Hitler. Worth a shot. http://catb.org/esr/jargon/html/G/Godwins-Law.html Can we collectively please avoid a thread about the various folks who contribute to, contributed to, or want to take credit for the Internet? Or about whether NAT tastes great or is less filling? (Yes there are technical discussions of interest to be had about address translation; few of them start from a moral position.) -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070831/7e2acb91/attachment.bin From matta at cs.bu.edu Fri Aug 31 13:34:07 2007 From: matta at cs.bu.edu (Abraham Matta) Date: Fri, 31 Aug 2007 16:34:07 -0400 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D7BC78.6030106@isi.edu> Message-ID: <0511C607B17F804EBE96FFECD1FD9859011FFA81@cs-exs2.cs-nt.bu.edu> > The transport layer isn't the crux of that problem - > it's all the other layers for which we don't agree > how to proceed yet. > > Joe Good point. I know of an upcoming book "Patterns of Protocols: Rethinking Network Architecture" by JOHN DAY (Publisher: Pearson) that offers some ideas on what a "layer" is and should do, which draws on the IPC OS model and has an interesting historical perspective on how we neglected fundamental problems like multihoming, etc. for long. I believe the book should come out soon this fall. ibrahim From dhc2 at dcrocker.net Fri Aug 31 14:37:25 2007 From: dhc2 at dcrocker.net (Dave Crocker) Date: Fri, 31 Aug 2007 14:37:25 -0700 Subject: [e2e] host-level aggregated congestion control citations Message-ID: <46D88A15.8040007@dcrocker.net> Folks, I am looking for a couple of citations, if there are any. Once upon a time, TCP did congestion control strictly on a per-connection behavior. I seem to recall that there was later work on aggregating congestion information, to get better behavior across concurrent connections between the same host-pair. If this is in current use, I'd like to review the mechanism(s). Yes? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mfisk at lanl.gov Fri Aug 31 14:43:59 2007 From: mfisk at lanl.gov (Mike Fisk) Date: Fri, 31 Aug 2007 15:43:59 -0600 (MDT) Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B0658082DE@VGAEXCH01.hq.corp.viasat.com> References: <0B0A20D0B3ECD742AA2514C8DDA3B0658082DE@VGAEXCH01.hq.corp.viasa t.com> Message-ID: On Fri, 31 Aug 2007, Agarwal, Anil wrote: > 1. What are the default and maximum receive and transmit window size > values of Linux 2.6.x, Windows and Vista? If they are less than 64 > kbytes, then enabling window scaling does not accomplish much, except > for applications that explicitly configure large maximum window sizes > both at the transmitter and the receiver. As of 2.6.7 and 2.4.27, Linux uses receive-size auto-tuning of buffer sizes based on what we implemented in 2001[1]. The receive window starts small (but with a wscale based on the max receive window setting) and is essentially kept at twice the current measured delay-bandwidth product, in order to not constrain the sender's cwnd growth. For Linux 2.6.19, the default receive window max is 1M, so the requested wscale is 5. The inital window advertisement is 64620. If you change the max to 2^27, then the initial advertisement is a wscale of 12, but the initial window advertisement is still 64240. Route caching of previous connecton windows can limit the inital receive window to smaller values. [1] "Dynamic Right-Sizing in TCP", M. Fisk, W. Feng, Proceedings of LACSI Symposium 2001, October 2001. http://public.lanl.gov/mfisk/papers/tcpwindow-lacsi.pdf From padhye at microsoft.com Fri Aug 31 15:23:15 2007 From: padhye at microsoft.com (Jitu Padhye) Date: Fri, 31 Aug 2007 15:23:15 -0700 Subject: [e2e] host-level aggregated congestion control citations In-Reply-To: <46D88A15.8040007@dcrocker.net> References: <46D88A15.8040007@dcrocker.net> Message-ID: One candidate is the congestion manager idea proposed by Hari Balakrishnan and his students at MIT. http://nms.lcs.mit.edu/cm/ I don't know whether there are any commercial systems/products that use the idea. - Jitu -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Dave Crocker Sent: Friday, August 31, 2007 2:37 PM To: end2end-interest at postel.org Subject: [e2e] host-level aggregated congestion control citations Folks, I am looking for a couple of citations, if there are any. Once upon a time, TCP did congestion control strictly on a per-connection behavior. I seem to recall that there was later work on aggregating congestion information, to get better behavior across concurrent connections between the same host-pair. If this is in current use, I'd like to review the mechanism(s). Yes? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From awo at ieee.org Fri Aug 31 16:06:47 2007 From: awo at ieee.org (Adam Wolisz) Date: Fri, 31 Aug 2007 16:06:47 -0700 Subject: [e2e] host-level aggregated congestion control citations In-Reply-To: <46D88A15.8040007@dcrocker.net> References: <46D88A15.8040007@dcrocker.net> Message-ID: <46D89F07.3010408@ieee.org> Dave, My student Michael Savoric has done quite a bit of research in this area, His PhD thesis "Improving COngestion Control in IP-based Networks by information sharing is available under http://edocs.tu-berlin.de/diss/2004/savoric_michael.pdf while quicker impression about parts of the work can be obtained by looking into Michael Savoric, Holger Karl, Morten Schl?ger, Tobias Poschwatta, and Adam Wolisz , "Analysis and performance evaluation of the EFCM common congestion controller for TCP connections", Computer Networks, vol. 49, no. 2, pp. 269-294, October 2005. Best Adam Wolisz Technische Universit?t Berlin Dave Crocker wrote: > Folks, > > I am looking for a couple of citations, if there are any. > > Once upon a time, TCP did congestion control strictly on a > per-connection behavior. I seem to recall that there was later work > on aggregating congestion information, to get better behavior across > concurrent connections between the same host-pair. > > If this is in current use, I'd like to review the mechanism(s). > > Yes? > > Thanks. > > d/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070831/9ff1b146/attachment.html From touch at ISI.EDU Fri Aug 31 16:12:00 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 31 Aug 2007 16:12:00 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: References: <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> <46D7BC78.6030106@isi.edu> Message-ID: <46D8A040.3010908@isi.edu> Hi, Andrew, Lachlan Andrew wrote: > Greetings Joe, > > On 31/08/2007, Joe Touch wrote: >> '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. > > Per connection, relative to RTT, relative to packet size, relative to > number of points of congestion. Is it also "relative to corruption > rate" or is that not part of the definition? Yup - sorry, I tried to include everything. > Yes, it is agreed upon, but I'd venture to suggest that it is mainly > agreed upon by (a) those few who played a role in developing the > algorithm which implements it (at low BDP etc), and (b) those trying > to gain the support of those original designers. It's implicitly agreed upon because it works well enough in practice. Even those who developed it didn't sign a compact on it. And some of its properties were discovered along the way. Those we didn't think worked we fixed as we went. But there's no consensus that it's working so horribly bad it needs a major overhaul either. > Per-flow max-min is much more "agreed upon" in the research community > as an *objective*, as distinct from the outcome of a particular > algorithm (which was a very useful emergency bandaid). I haven't done > a survey, but I'm confident that if you asked the average user, they > would be more in favour of max-min fairness than TCP-friendly > fairness. max-min fairness still needs to be tied to a user-level policy. How do you decide what a flow is? If a flow is a socket pair (src/dst addr, src/dst port), then (and here's been the point): flow-fairness doesn't solve "opening multiple TCP connections getting popular" [as a cheat] > You mentioned that the IETF's role isn't to do research. How about a > commitment to be *open* to research into a concept of fairness which > is more systematic and less historically-driven? The current > impression that I get from the research community is that the IETF > will on principle block any proposal which implements a "better" > form of fairness (i.e. one with a theoretical justification and more > in line with a layman's notion of fairness, such as user-pays). Bob's > experience seems to bear that out... This isn't another "blocking any form of fairness" reply. The problem with this thread overall is that the new solution is argued as solving multiple TCP connections as a cheat. The parts required to make flow-fairness work around that cheat appear to equally defeat the cheat for TCP -- the part that ties users to flows and makes sure their behavior is enforced based on network feedback. The IETF doesn't enjoy overhauling a currently sufficient system with a new one when it doesn't solve the problem. **the problem discussed in this thread** hasn't been shown to be solved by flow-fairness. > What exactly do you mean by a fairness definition "working"? The > internet still "works", who knows if that is just because of > "receiver window fairness" or "small P2P user-base fairness", or > "overprovisioning fairness" rather than "per flow fairness" :) It works until it breaks. "Breaks" is open to debate, and can be somewhat subjective. And if any of the above are true, then they work fine. But note that few of the other items say "throw out everything else for this solution". 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/20070831/864d1aca/signature.bin From touch at ISI.EDU Fri Aug 31 16:14:32 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 31 Aug 2007 16:14:32 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <0511C607B17F804EBE96FFECD1FD9859011FFA81@cs-exs2.cs-nt.bu.edu> References: <0511C607B17F804EBE96FFECD1FD9859011FFA81@cs-exs2.cs-nt.bu.edu> Message-ID: <46D8A0D8.3010009@isi.edu> Abraham Matta wrote: >> The transport layer isn't the crux of that problem - >> it's all the other layers for which we don't agree >> how to proceed yet. >> >> Joe > > Good point. I know of an upcoming book "Patterns of Protocols: > Rethinking Network Architecture" by JOHN DAY (Publisher: Pearson) that > offers some ideas on what a "layer" is and should do, which draws on the > IPC OS model and has an interesting historical perspective on how we > neglected fundamental problems like multihoming, etc. for long. I > believe the book should come out soon this fall. FWIW, we have some investigations along the general line of "what is a layer" overall too: http://www.isi.edu/rna But "what is a layer" isn't the point I was trying to make. Even if we stick to the 7-layer cake, the question of fairness needs to include how flows at each layer are aggregated, and what a 'group' is. I explored this a little in RFC2140, but not to the extent that it needs to be addressed here before a true solution can be applied. 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/20070831/f114588e/signature.bin From touch at ISI.EDU Fri Aug 31 17:43:39 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 31 Aug 2007 17:43:39 -0700 Subject: [e2e] host-level aggregated congestion control citations In-Reply-To: <46D88A15.8040007@dcrocker.net> References: <46D88A15.8040007@dcrocker.net> Message-ID: <46D8B5BB.6040008@isi.edu> Hi, Dave, Dave Crocker wrote: > Folks, > > I am looking for a couple of citations, if there are any. > > Once upon a time, TCP did congestion control strictly on a > per-connection behavior. I seem to recall that there was later work on > aggregating congestion information, to get better behavior across > concurrent connections between the same host-pair. The first work that did share some info was T/TCP, In 1997, RFC2140 described exactly the above. A few years later, the Congestion Manager (Sigcomm, RFC2134) presented a mechanism outside TCP that integrates the information across many protocol types, including UDP if desired. > If this is in current use, I'd like to review the mechanism(s). I believe bits of RFC2140 are in Linux, but don't know if they're currently enabled: http://www.cs.helsinki.fi/research/iwtcp/kernel-patch/ 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/20070831/e00150b1/signature-0001.bin From touch at ISI.EDU Fri Aug 31 18:45:56 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 31 Aug 2007 18:45:56 -0700 Subject: [e2e] host-level aggregated congestion control citations In-Reply-To: <46D8B5BB.6040008@isi.edu> References: <46D88A15.8040007@dcrocker.net> <46D8B5BB.6040008@isi.edu> Message-ID: <46D8C454.6040604@isi.edu> My apologies to Michael and Adam for not including them in my list, FWIW. Joe Joe Touch wrote: > Hi, Dave, > > Dave Crocker wrote: >> Folks, >> >> I am looking for a couple of citations, if there are any. >> >> Once upon a time, TCP did congestion control strictly on a >> per-connection behavior. I seem to recall that there was later work on >> aggregating congestion information, to get better behavior across >> concurrent connections between the same host-pair. > > The first work that did share some info was T/TCP, > > In 1997, RFC2140 described exactly the above. > > A few years later, the Congestion Manager (Sigcomm, RFC2134) presented a > mechanism outside TCP that integrates the information across many > protocol types, including UDP if desired. > >> If this is in current use, I'd like to review the mechanism(s). > > I believe bits of RFC2140 are in Linux, but don't know if they're > currently enabled: > http://www.cs.helsinki.fi/research/iwtcp/kernel-patch/ > > Joe -------------- 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/20070831/5174a268/signature.bin From lachlan.andrew at gmail.com Fri Aug 31 08:29:12 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 31 Aug 2007 08:29:12 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D7BC78.6030106@isi.edu> References: <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> <46D7BC78.6030106@isi.edu> Message-ID: Greetings Joe, On 31/08/2007, Joe Touch wrote: > > '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. Per connection, relative to RTT, relative to packet size, relative to number of points of congestion. Is it also "relative to corruption rate" or is that not part of the definition? Yes, it is agreed upon, but I'd venture to suggest that it is mainly agreed upon by (a) those few who played a role in developing the algorithm which implements it (at low BDP etc), and (b) those trying to gain the support of those original designers. Per-flow max-min is much more "agreed upon" in the research community as an *objective*, as distinct from the outcome of a particular algorithm (which was a very useful emergency bandaid). I haven't done a survey, but I'm confident that if you asked the average user, they would be more in favour of max-min fairness than TCP-friendly fairness. You mentioned that the IETF's role isn't to do research. How about a commitment to be *open* to research into a concept of fairness which is more systematic and less historically-driven? The current impression that I get from the research community is that the IETF will on principle block any proposal which implements a "better" form of fairness (i.e. one with a theoretical justification and more in line with a layman's notion of fairness, such as user-pays). Bob's experience seems to bear that out... What exactly do you mean by a fairness definition "working"? The internet still "works", who knows if that is just because of "receiver window fairness" or "small P2P user-base fairness", or "overprovisioning fairness" rather than "per flow fairness" :) 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 From dga+e2e at cs.cmu.edu Fri Aug 31 20:13:35 2007 From: dga+e2e at cs.cmu.edu (David Andersen) Date: Fri, 31 Aug 2007 23:13:35 -0400 Subject: [e2e] host-level aggregated congestion control citations In-Reply-To: References: <46D88A15.8040007@dcrocker.net> Message-ID: On Aug 31, 2007, at 6:23 PM, Jitu Padhye wrote: > One candidate is the congestion manager idea proposed by Hari > Balakrishnan and his students at MIT. > > http://nms.lcs.mit.edu/cm/ > > I don't know whether there are any commercial systems/products that > use the idea. Not to my knowledge. Hari and Srini wrote an RFC for it, as Joe noted (RFC 2134); we implemented it in Linux 2.2 and the source code remains freely available, but to my knowledge, that's about the last development that occurred on it. The hooks that we tied into in Linux have changed significantly since then. Linux's latest round of TCP-ness has a more modular framework that allows congestion control algorithms to be exchanged for each other in the kernel - this doesn't achieve the sharing benefits from the CM or the ability to have congestion-controlled UDP flows, but it gets some of the modularity benefits of the CM. Bryan Ford's paper at SIGCOMM this year on Structured Stream Transport (http://pdos.csail.mit.edu/uia/sst/) offers a "sub-stream" abstraction that permits congestion sharing between multiple flows, but I get the impression that it's intended mostly to do so between flows from the same application, and the current implementation is a per-application user-space library. If you have any questions about the CM, we'd be happy to answer them, and even happier to see someone interested in pushing on it further. It's been a couple years, but we can dust off our brains... -Dave > > - Jitu > > -----Original Message----- > From: end2end-interest-bounces at postel.org [mailto:end2end-interest- > bounces at postel.org] On Behalf Of Dave Crocker > Sent: Friday, August 31, 2007 2:37 PM > To: end2end-interest at postel.org > Subject: [e2e] host-level aggregated congestion control citations > > Folks, > > I am looking for a couple of citations, if there are any. > > Once upon a time, TCP did congestion control strictly on a per- > connection > behavior. I seem to recall that there was later work on aggregating > congestion information, to get better behavior across concurrent > connections > between the same host-pair. > > If this is in current use, I'd like to review the mechanism(s). > > Yes? > > Thanks. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070831/5912bbc2/PGP.bin From lachlan.andrew at gmail.com Fri Aug 31 08:29:12 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 31 Aug 2007 08:29:12 -0700 Subject: [e2e] opening multiple TCP connections getting popular In-Reply-To: <46D7BC78.6030106@isi.edu> References: <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> <46D7BC78.6030106@isi.edu> Message-ID: Greetings Joe, On 31/08/2007, Joe Touch wrote: > > '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. Per connection, relative to RTT, relative to packet size, relative to number of points of congestion. Is it also "relative to corruption rate" or is that not part of the definition? Yes, it is agreed upon, but I'd venture to suggest that it is mainly agreed upon by (a) those few who played a role in developing the algorithm which implements it (at low BDP etc), and (b) those trying to gain the support of those original designers. Per-flow max-min is much more "agreed upon" in the research community as an *objective*, as distinct from the outcome of a particular algorithm (which was a very useful emergency bandaid). I haven't done a survey, but I'm confident that if you asked the average user, they would be more in favour of max-min fairness than TCP-friendly fairness. You mentioned that the IETF's role isn't to do research. How about a commitment to be *open* to research into a concept of fairness which is more systematic and less historically-driven? The current impression that I get from the research community is that the IETF will on principle block any proposal which implements a "better" form of fairness (i.e. one with a theoretical justification and more in line with a layman's notion of fairness, such as user-pays). Bob's experience seems to bear that out... What exactly do you mean by a fairness definition "working"? The internet still "works", who knows if that is just because of "receiver window fairness" or "small P2P user-base fairness", or "overprovisioning fairness" rather than "per flow fairness" :) 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