From craig at aland.bbn.com Mon Jan 23 13:18:31 2012 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 23 Jan 2012 16:18:31 -0500 Subject: [e2e] Google seeks to tweak TCP Message-ID: <20120123211831.9518128E137@aland.bbn.com> Craig E-mail: craig at aland.bbn.com or craig at bbn.com ------- Forwarded Message Return-Path: privacy-bounces+craig=aland.bbn.com at vortex.com Delivery-Date: Mon Jan 23 13:58:48 2012 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on aland.bbn.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=4.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Original-To: craig at aland.bbn.com Delivered-To: craig at aland.bbn.com Received: from moe.vortex.com (moe.vortex.com [192.160.193.155]) by aland.bbn.com (Postfix) with ESMTP id 25B2D28E135 for ; Mon, 23 Jan 2012 13:58:48 -0500 (EST) Received: from chrome.vortex.com (chrome.vortex.com [67.119.61.37]) by neon.vortex.com (8.12.6/8.12.6) with ESMTP id q0NIi6P8030599 for ; Mon, 23 Jan 2012 10:44:06 -0800 (PST) Date: Mon, 23 Jan 2012 10:44:06 -0800 To: privacy-list at vortex.com Message-ID: <20120123184406.GG14662 at vortex.com> MIME-Version: 1.0 Content-Disposition: inline X-Loop-Check: From: PRIVACY Forum mailing list Subject: [ PRIVACY Forum ] Google: Let's Make TCP Faster X-BeenThere: privacy at vortex.com X-Mailman-Version: 2.1.6b2 Precedence: list Reply-To: PRIVACY Forum mailing list List-Id: PRIVACY Forum mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: privacy-bounces+craig=aland.bbn.com at vortex.com Errors-To: privacy-bounces+craig=aland.bbn.com at vortex.com Google: Let's Make TCP Faster http://j.mp/Af4pgb (Google Code Blog) "Transmission Control Protocol (TCP), the workhorse of the Internet, is designed to deliver all the Web's content and operate over a huge range of network types. To deliver content effectively, Web browsers typically open several dozen parallel TCP connections ahead of making actual requests. This strategy overcomes inherent TCP limitations but results in high latency in many situations and is not scalable. Our research shows that the key to reducing latency is saving round trips. We're experimenting with several improvements to TCP. Here's a summary of some of our recommendations to make TCP faster ..." - - - - --Lauren-- Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren = Co-Founder: People For Internet Responsibility: http://www.pfir.org = Founder: - Network Neutrality Squad: http://www.nnsquad.org = - Global Coalition for Transparent Internet Performance: http://www.gctip.= org - PRIVACY Forum: http://www.vortex.com = Member: ACM Committee on Computers and Public Policy Blog: http://lauren.vortex.com = Google+: http://vortex.com/g+lauren = Twitter: https://twitter.com/laurenweinstein = Tel: +1 (818) 225-2800 / Skype: vortex.com _______________________________________________ privacy mailing list http://lists.vortex.com/mailman/listinfo/privacy ------- End of Forwarded Message From scott.brim at gmail.com Mon Jan 23 14:40:48 2012 From: scott.brim at gmail.com (Scott Brim) Date: Mon, 23 Jan 2012 16:40:48 -0600 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <20120123211831.9518128E137@aland.bbn.com> References: <20120123211831.9518128E137@aland.bbn.com> Message-ID: Google has been using SPDY as a test environment for years. Is there anything here that is not in SPDY? From L.Wood at surrey.ac.uk Mon Jan 23 18:21:49 2012 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Tue, 24 Jan 2012 02:21:49 +0000 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <20120123211831.9518128E137@aland.bbn.com> References: <20120123211831.9518128E137@aland.bbn.com> Message-ID: Can it be argued that google is attacking the wrong layer? TCP was not 'designed to deliver the Web's content.' TCP predates the web and http by decades. The internet and TCP user base is rather larger than google's user base of web customers. TCP was indeed designed to operate over 'a huge range of network types', and decreasing TCP RTO while increasing initial windows decreases TCP's tolerance of the range of networks it can support. I look forward to seeing the knock-on effects of decreasing the initial TCP RTO to one second (e.g. interactions with Mobile IP). Improved and more widely deployed HTTP persistence and pipelining would help; Google's SPDY at least nods to that. Those are germane to web use, and thus to Google's customers. Tweaking (improving?) TCP, not so much. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of Craig Partridge [craig at aland.bbn.com] Sent: 23 January 2012 21:18 To: end2end-interest at postel.org Subject: [e2e] Google seeks to tweak TCP Craig E-mail: craig at aland.bbn.com or craig at bbn.com ------- Forwarded Message Return-Path: privacy-bounces+craig=aland.bbn.com at vortex.com Delivery-Date: Mon Jan 23 13:58:48 2012 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on aland.bbn.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=4.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Original-To: craig at aland.bbn.com Delivered-To: craig at aland.bbn.com Received: from moe.vortex.com (moe.vortex.com [192.160.193.155]) by aland.bbn.com (Postfix) with ESMTP id 25B2D28E135 for ; Mon, 23 Jan 2012 13:58:48 -0500 (EST) Received: from chrome.vortex.com (chrome.vortex.com [67.119.61.37]) by neon.vortex.com (8.12.6/8.12.6) with ESMTP id q0NIi6P8030599 for ; Mon, 23 Jan 2012 10:44:06 -0800 (PST) Date: Mon, 23 Jan 2012 10:44:06 -0800 To: privacy-list at vortex.com Message-ID: <20120123184406.GG14662 at vortex.com> MIME-Version: 1.0 Content-Disposition: inline X-Loop-Check: From: PRIVACY Forum mailing list Subject: [ PRIVACY Forum ] Google: Let's Make TCP Faster X-BeenThere: privacy at vortex.com X-Mailman-Version: 2.1.6b2 Precedence: list Reply-To: PRIVACY Forum mailing list List-Id: PRIVACY Forum mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: privacy-bounces+craig=aland.bbn.com at vortex.com Errors-To: privacy-bounces+craig=aland.bbn.com at vortex.com Google: Let's Make TCP Faster http://j.mp/Af4pgb (Google Code Blog) "Transmission Control Protocol (TCP), the workhorse of the Internet, is designed to deliver all the Web's content and operate over a huge range of network types. To deliver content effectively, Web browsers typically open several dozen parallel TCP connections ahead of making actual requests. This strategy overcomes inherent TCP limitations but results in high latency in many situations and is not scalable. Our research shows that the key to reducing latency is saving round trips. We're experimenting with several improvements to TCP. Here's a summary of some of our recommendations to make TCP faster ..." - - - - --Lauren-- Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren = Co-Founder: People For Internet Responsibility: http://www.pfir.org = Founder: - Network Neutrality Squad: http://www.nnsquad.org = - Global Coalition for Transparent Internet Performance: http://www.gctip.= org - PRIVACY Forum: http://www.vortex.com = Member: ACM Committee on Computers and Public Policy Blog: http://lauren.vortex.com = Google+: http://vortex.com/g+lauren = Twitter: https://twitter.com/laurenweinstein = Tel: +1 (818) 225-2800 / Skype: vortex.com _______________________________________________ privacy mailing list http://lists.vortex.com/mailman/listinfo/privacy ------- End of Forwarded Message From wes at mti-systems.com Mon Jan 23 18:44:11 2012 From: wes at mti-systems.com (Wesley Eddy) Date: Mon, 23 Jan 2012 21:44:11 -0500 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: References: <20120123211831.9518128E137@aland.bbn.com> Message-ID: <4F1E1AFB.6020609@mti-systems.com> On 1/23/2012 5:40 PM, Scott Brim wrote: > Google has been using SPDY as a test environment for years. Is there > anything here that is not in SPDY? > > SPDY is a layer above the TCP modifications discussed on that webpage. I think all of them should be fairly familiar to folks who have been following the IETF TCPM working group, where the Google engineers have been sharing and advancing these ideas for some time. -- Wes Eddy MTI Systems From sm at resistor.net Mon Jan 23 23:12:04 2012 From: sm at resistor.net (SM) Date: Mon, 23 Jan 2012 23:12:04 -0800 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: References: <20120123211831.9518128E137@aland.bbn.com> Message-ID: <6.2.5.6.2.20120123224809.0a3cfd78@resistor.net> At 18:21 23-01-2012, L.Wood at surrey.ac.uk wrote: >Can it be argued that google is attacking the wrong layer? I don't think so. There have been efforts at different layers. If X finds that change Y can shave a few milliseconds without negative consequences to its users, X will deploy the change. For example: http://research.google.com/pubs/pub36640.html http://developer.yahoo.com/blogs/ydn/posts/2011/11/flickrs-new-dynamic-content-acceleration/ Regards, -sm From Jon.Crowcroft at cl.cam.ac.uk Tue Jan 24 03:01:27 2012 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 24 Jan 2012 11:01:27 +0000 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: References: <20120123211831.9518128E137@aland.bbn.com> Message-ID: well, perhaps - sometimes, i just wish TCP would simply get out of the way... In missive , L.Wood at surrey.ac.uk typed: >>Can it be argued that google is attacking the wrong layer? >> >>TCP was not 'designed to deliver the Web's content.' TCP predates the web and http by decades. The internet and TCP user base is rather larger than google's user base of web customers. >> >>TCP was indeed designed to operate over 'a huge range of network types', and decreasing TCP RTO while increasing initial windows decreases TCP's tolerance of the range of networks it can support. >> I look forward to seeing the knock-on effects of decreasing the initial TCP RTO to one second (e.g. interactions with Mobile IP). >> >>Improved and more widely deployed HTTP persistence and pipelining would help; Google's SPDY at least nods to that. Those are germane to web use, and thus to Google's customers. Tweaking (improving?) TCP, not so much. >> >> >>Lloyd Wood >>http://sat-net.com/L.Wood/ >> >> >>________________________________________ >>From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of Craig Partridge [craig at aland.bbn.com] >>Sent: 23 January 2012 21:18 >>To: end2end-interest at postel.org >>Subject: [e2e] Google seeks to tweak TCP >> >>Craig >> >>E-mail: craig at aland.bbn.com or craig at bbn.com >> >>------- Forwarded Message >> >>Return-Path: privacy-bounces+craig=aland.bbn.com at vortex.com >>Delivery-Date: Mon Jan 23 13:58:48 2012 >>Return-Path: >>X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on aland.bbn.com >>X-Spam-Level: >>X-Spam-Status: No, score=-1.9 required=4.0 tests=BAYES_00,T_RP_MATCHES_RCVD >> autolearn=ham version=3.3.2 >>X-Original-To: craig at aland.bbn.com >>Delivered-To: craig at aland.bbn.com >>Received: from moe.vortex.com (moe.vortex.com [192.160.193.155]) >> by aland.bbn.com (Postfix) with ESMTP id 25B2D28E135 >> for ; Mon, 23 Jan 2012 13:58:48 -0500 (EST) >>Received: from chrome.vortex.com (chrome.vortex.com [67.119.61.37]) >> by neon.vortex.com (8.12.6/8.12.6) with ESMTP id q0NIi6P8030599 >> for ; Mon, 23 Jan 2012 10:44:06 -0800 (PST) >>Date: Mon, 23 Jan 2012 10:44:06 -0800 >>To: privacy-list at vortex.com >>Message-ID: <20120123184406.GG14662 at vortex.com> >>MIME-Version: 1.0 >>Content-Disposition: inline >>X-Loop-Check: >>From: PRIVACY Forum mailing list >>Subject: [ PRIVACY Forum ] Google: Let's Make TCP Faster >>X-BeenThere: privacy at vortex.com >>X-Mailman-Version: 2.1.6b2 >>Precedence: list >>Reply-To: PRIVACY Forum mailing list >>List-Id: PRIVACY Forum mailing list >>List-Unsubscribe: , >> >>List-Post: >>List-Help: >>List-Subscribe: , >> >>Content-Type: text/plain; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >>Sender: privacy-bounces+craig=aland.bbn.com at vortex.com >>Errors-To: privacy-bounces+craig=aland.bbn.com at vortex.com >> >> >> >>Google: Let's Make TCP Faster >> >>http://j.mp/Af4pgb (Google Code Blog) >> >> "Transmission Control Protocol (TCP), the workhorse of the Internet, is >> designed to deliver all the Web's content and operate over a huge >> range of network types. To deliver content effectively, Web browsers >> typically open several dozen parallel TCP connections ahead of making >> actual requests. This strategy overcomes inherent TCP limitations but >> results in high latency in many situations and is not scalable. Our >> research shows that the key to reducing latency is saving round trips. >> We're experimenting with several improvements to TCP. Here's a summary >> of some of our recommendations to make TCP faster ..." >> >> - - - >> >>- --Lauren-- >>Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren = >> >>Co-Founder: People For Internet Responsibility: http://www.pfir.org = >> >>Founder: >> - Network Neutrality Squad: http://www.nnsquad.org = >> >> - Global Coalition for Transparent Internet Performance: http://www.gctip.= >>org >> - PRIVACY Forum: http://www.vortex.com = >> >>Member: ACM Committee on Computers and Public Policy >>Blog: http://lauren.vortex.com = >> >>Google+: http://vortex.com/g+lauren = >> >>Twitter: https://twitter.com/laurenweinstein = >> >>Tel: +1 (818) 225-2800 / Skype: vortex.com >> >> >> >>_______________________________________________ >>privacy mailing list >>http://lists.vortex.com/mailman/listinfo/privacy >> >>------- End of Forwarded Message >> >> cheers jon From dhavey at yahoo.com Tue Jan 24 04:58:03 2012 From: dhavey at yahoo.com (Daniel Havey) Date: Tue, 24 Jan 2012 04:58:03 -0800 (PST) Subject: [e2e] Google seeks to tweak TCP In-Reply-To: Message-ID: <1327409883.43681.YahooMailClassic@web130106.mail.mud.yahoo.com> I have to agree with this. TCP is ugly for Application Layer FEC. ...Daniel --- On Tue, 1/24/12, Jon Crowcroft wrote: > From: Jon Crowcroft > Subject: Re: [e2e] Google seeks to tweak TCP > To: L.Wood at surrey.ac.uk > Cc: craig at aland.bbn.com, Jon.Crowcroft at cl.cam.ac.uk, end2end-interest at postel.org > Date: Tuesday, January 24, 2012, 3:01 AM > well, perhaps - sometimes, i just > wish TCP would simply get out of the way... > > In missive , > L.Wood at surrey.ac.uk > typed: > > >>Can it be argued that google is attacking the wrong > layer? > >> > >>TCP was not 'designed to deliver the Web's > content.' TCP predates the web and http by decades. The > internet and TCP user base is rather larger than google's > user base of web customers. > >> > >>TCP was indeed designed to operate over 'a huge > range of network types', and decreasing TCP RTO while > increasing initial windows decreases TCP's tolerance of the > range of networks it can support. > >> I look forward to seeing the knock-on effects of > decreasing the initial TCP RTO to one second (e.g. > interactions with Mobile IP). > >> > >>Improved and more widely deployed HTTP persistence > and pipelining would help; Google's SPDY at least nods to > that. Those are germane to web use, and thus to Google's > customers. Tweaking (improving?) TCP, not so much. > >> > >> > >>Lloyd Wood > >>http://sat-net.com/L.Wood/ > >> > >> > >>________________________________________ > >>From: end2end-interest-bounces at postel.org > [end2end-interest-bounces at postel.org] > On Behalf Of Craig Partridge [craig at aland.bbn.com] > >>Sent: 23 January 2012 21:18 > >>To: end2end-interest at postel.org > >>Subject: [e2e] Google seeks to tweak TCP > >> > >>Craig > >> > >>E-mail: craig at aland.bbn.com > or craig at bbn.com > >> > >>------- Forwarded Message > >> > >>Return-Path: privacy-bounces+craig=aland.bbn.com at vortex.com > >>Delivery-Date: Mon Jan 23 13:58:48 2012 > >>Return-Path: > >>X-Spam-Checker-Version: SpamAssassin 3.3.2 > (2011-06-06) on aland.bbn.com > >>X-Spam-Level: > >>X-Spam-Status: No, score=-1.9 required=4.0 > tests=BAYES_00,T_RP_MATCHES_RCVD > >>? ? ? ? autolearn=ham > version=3.3.2 > >>X-Original-To: craig at aland.bbn.com > >>Delivered-To: craig at aland.bbn.com > >>Received: from moe.vortex.com (moe.vortex.com > [192.160.193.155]) > >>? ? ? ? by aland.bbn.com > (Postfix) with ESMTP id 25B2D28E135 > >>? ? ? ? for ; > Mon, 23 Jan 2012 13:58:48 -0500 (EST) > >>Received: from chrome.vortex.com (chrome.vortex.com > [67.119.61.37]) > >>? ? ? ? by neon.vortex.com > (8.12.6/8.12.6) with ESMTP id q0NIi6P8030599 > >>? ? ? ? for > ; Mon, 23 Jan 2012 > 10:44:06 -0800 (PST) > >>Date: Mon, 23 Jan 2012 10:44:06 -0800 > >>To: privacy-list at vortex.com > >>Message-ID: <20120123184406.GG14662 at vortex.com> > >>MIME-Version: 1.0 > >>Content-Disposition: inline > >>X-Loop-Check: > >>From: PRIVACY Forum mailing list > >>Subject: [ PRIVACY Forum ]? Google: Let's Make > TCP Faster > >>X-BeenThere: privacy at vortex.com > >>X-Mailman-Version: 2.1.6b2 > >>Precedence: list > >>Reply-To: PRIVACY Forum mailing list > >>List-Id: PRIVACY Forum mailing list > > >>List-Unsubscribe: , > >>? ? ? ? > >>List-Post: > >>List-Help: > >>List-Subscribe: , > >>? ? ? ? > >>Content-Type: text/plain; charset="iso-8859-1" > >>Content-Transfer-Encoding: quoted-printable > >>Sender: privacy-bounces+craig=aland.bbn.com at vortex.com > >>Errors-To: privacy-bounces+craig=aland.bbn.com at vortex.com > >> > >> > >> > >>Google: Let's Make TCP Faster > >> > >>http://j.mp/Af4pgb (Google Code Blog) > >> > >>???"Transmission Control Protocol > (TCP), the workhorse of the Internet, is > >>? ? designed to deliver all the Web's > content and operate over a huge > >>? ? range of network types. To deliver > content effectively, Web browsers > >>? ? typically open several dozen parallel > TCP connections ahead of making > >>? ? actual requests. This strategy > overcomes inherent TCP limitations but > >>? ? results in high latency in many > situations and is not scalable.? Our > >>? ? research shows that the key to > reducing latency is saving round trips. > >>? ? We're experimenting with several > improvements to TCP. Here's a summary > >>? ? of some of our recommendations to > make TCP faster ..." > >> > >> - - - > >> > >>- --Lauren-- > >>Lauren Weinstein (lauren at vortex.com): > http://www.vortex.com/lauren = > >> > >>Co-Founder: People For Internet Responsibility: http://www.pfir.org = > >> > >>Founder: > >> - Network Neutrality Squad: http://www.nnsquad.org = > >> > >> - Global Coalition for Transparent Internet > Performance: http://www.gctip.= > >>org > >> - PRIVACY Forum: http://www.vortex.com = > >> > >>Member: ACM Committee on Computers and Public > Policy > >>Blog: http://lauren.vortex.com = > >> > >>Google+: http://vortex.com/g+lauren = > >> > >>Twitter: https://twitter.com/laurenweinstein = > >> > >>Tel: +1 (818) 225-2800 / Skype: vortex.com > >> > >> > >> > >>_______________________________________________ > >>privacy mailing list > >>http://lists.vortex.com/mailman/listinfo/privacy > >> > >>------- End of Forwarded Message > >> > >> > > cheers > > ???jon > > From mirja.kuehlewind at ikr.uni-stuttgart.de Tue Jan 31 08:22:34 2012 From: mirja.kuehlewind at ikr.uni-stuttgart.de (Mirja Kuehlewind) Date: Tue, 31 Jan 2012 17:22:34 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <4ED619FE.9090904@ifi.uio.no> References: <20111130121050.82277480c9hefp4w@mail.poliba.it> <4ED619FE.9090904@ifi.uio.no> Message-ID: <201201311722.34168.mirja.kuehlewind@ikr.uni-stuttgart.de> Hi everybody, I know I'm quite late to enter this discussion, but I would like to raise another question. I guess there was already a lot explanation on the e2e list saying (more or less) that Cubic is more aggressive but it is also able to react more quickly on network changes (mainly sudden increases in bandwidth). With e.g. TCP Reno the time between two loss events is increasing with the network capacity. So it might take a long time to actually detect that there is more bandwidth available in a network with large capacity. If we want to speed up this probing process we would need more frequent loss events causing a higher loss rate...? I guess one solution to this problem would be ECN. That means having a high probing rate but no losses. I'm wondering if there is any other solutions? Mirja On Wednesday 30 November 2011 12:56:46 Michael Welzl wrote: > This should really go to ICCRG, I'd say (added to recipients). May I ask > to continue this (interesting!) discussion there? > > On 11/30/11 12:10 PM, mascolo at poliba.it wrote: > > Dear all, > > > > we know that TCP BIC/Cubic is default in Linux and as a consequence > > 50% of servers employs TCP BIC/Cubic. > > > > Our measurements say that there could be reasons not to deploy TCP > > BIC/Cubic. These reasons are in our opinion rooted in its more > > aggressive probing phase. In particular, in common network conditions, > > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or > > TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno > > or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP > > NewReno or Westwood+. > > > > In other terms, it seems that its more aggressive probing increases > > both throughput and retransmissions but leaving unchanged the goodput. > > This is neutral for the users but negative for the network. > > > > I appreciate your views. > > > > Thanks for the attention and best regards, > > > > Saverio Mascolo > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > Iccrg mailing list > Iccrg at cs.ucl.ac.uk > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg -- ------------------------------------------------------------------- Dipl.-Ing. Mirja K?hlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind at ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de -------------------------------------------------------------------