tag:blogger.com,1999:blog-11300808.post2138172111681265307..comments2024-03-18T00:47:50.425-07:00Comments on The official Google Code blog: Let's make TCP fasterMike Marchakhttp://www.blogger.com/profile/08067736591419106914noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-11300808.post-82815359975887247902012-03-01T18:37:09.729-08:002012-03-01T18:37:09.729-08:00I don't think these changes were meant for wid...I don't think these changes were meant for widespread consumer use on low-bandwidth connections, but rather to reduce the latency of the network traffic within their datacenters on high-bandwidth connections. TCP's congestion control mechanisms currently don't scale well to high-bandwidth connections, the recovery time takes too long after triple duplicate ACKs.Paul Eubankshttps://www.blogger.com/profile/02108268687552519364noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-45475630660631305352012-02-10T12:19:45.386-08:002012-02-10T12:19:45.386-08:00i agree that most of the items listed in this arti...i agree that most of the items listed in this article are the pains in the neck for todays TCP implementations. that said, TCP optimization is a bigger problem than merely tweaking the parameters. we, www.appexnetworks.com, have been working for years on that. besides the points listed here, there are issues such as how to improve the accuracy in detecting a packet loss from, say, reordering; how to filter out bogus signals from crappy real-world TCP implementations (you'd be surprised to see how some TCP reacts, esp thru the filter of some 'intelligent' firewalls). and most importantly, you dont want to contribute to the chances of congestion, on both directions, even if your traffic is mostly unidirectional. and there are more.<br /><br />we've done most of it, though not all of it. for linux and windows, if you'd like to try, you are welcome to get it from our download site.Hao Zhuanghttps://www.blogger.com/profile/06824526531420369264noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-51444934130928986802012-01-27T15:35:30.415-08:002012-01-27T15:35:30.415-08:00there are reason ms hardcode now!cause in the past...there are reason ms hardcode now!cause in the past silly people like google and a lot of other messed with standard without the whole picture!the web sadly isnt just google server or microsoft if it was trust me microsoft would have adopted way better solution but compromise had to be made so overall web was smooth,instead google should ask for variable.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11300808.post-16380389867612109222012-01-26T21:59:59.056-08:002012-01-26T21:59:59.056-08:00Where's the RFC? :)Where's the RFC? :)mercurialmadnessmanhttps://www.blogger.com/profile/16172804497067409583noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-7013602480077057852012-01-26T04:17:12.386-08:002012-01-26T04:17:12.386-08:00before this you must working on new independent st...before this you must working on new independent structure of the network ,we refuse to another sopa or pipa or other censorship like megaupzdig1https://www.blogger.com/profile/11287245408624521705noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-84420131144929224832012-01-26T03:20:57.853-08:002012-01-26T03:20:57.853-08:00Yuchung, I've seen similar behavior in wireles...Yuchung, I've seen similar behavior in wireless adhoc networks, where the impact of bigger window sizes is a much better improvement than here.<br /><br />As for the timeout reduction, I would argue that the 21st century is not about big centralized systems but decentralization. And I'm not so sure that increasing the timeout in mesh networks is in fact such a good idea.teabagsumhttps://www.blogger.com/profile/03609190846706265414noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-35906907788114746632012-01-25T19:17:01.376-08:002012-01-25T19:17:01.376-08:00"An RTT of 3 seconds was appropriate a couple..."An RTT of 3 seconds was appropriate a couple of decades ago, but today’s Internet requires a much smaller timeout"<br /><br />bad advice. what if my clients are using slow internet connection? perhaps, from 3rd world country through mobile operator, even excellent ISP can have some problems sometimes, or may be user is downloading something heavy, etc... what will they think about my service? It is not so critical to choose 3 sec instead of 1 sec, but it will be a better service.Quuxhttps://www.blogger.com/profile/17660712795987520706noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-13611718685275220212012-01-25T19:10:28.003-08:002012-01-25T19:10:28.003-08:00It is better on long connections. But on quick - i...It is better on long connections. But on quick - is not.Quuxhttps://www.blogger.com/profile/17660712795987520706noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-26347665030750331302012-01-25T10:01:00.467-08:002012-01-25T10:01:00.467-08:00Page 14 of this page says Fast Open is in kernel 2...Page 14 of this page says Fast Open is in kernel 2.6.34 : http://conferences.sigcomm.org/co-next/2011/slides/Radhakrishnan-TCP_Fast_Open.pdf<br /><br />Is it the same "Fast Open" ?...I think it is...Anonymoushttps://www.blogger.com/profile/01576815863663019779noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-82161647700616769382012-01-25T03:54:02.823-08:002012-01-25T03:54:02.823-08:00LOL.. you guys should've seen UDT's perfor...LOL.. you guys should've seen UDT's performance.<br /><br />Go chk it out; its on sourceforge :)sky770https://www.blogger.com/profile/10557739718454604334noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-56994606206223914652012-01-25T00:34:06.953-08:002012-01-25T00:34:06.953-08:00Are there any guidelines for working with WebSocke...Are there any guidelines for working with WebSockets? What should I use when working with Google Protocol Buffers - HTTP, SPDY, HTTP+WebSocket, TCP? I'm talking about massively multiplayer online game.AutoRevithttps://www.blogger.com/profile/08516474811982634893noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-10202464412941392252012-01-24T23:43:35.362-08:002012-01-24T23:43:35.362-08:00If the last three packets get lost, the only way t...If the last three packets get lost, the only way to recover is via an RTO. We do find that a significant portion of the retransmissions from short HTTP responses are due to RTOs (as opposed to fast recovery). We are working on solutions to address the issue of long latency due to timeouts in short flows.Nandita Dukkipatihttps://www.blogger.com/profile/13857996384221048861noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-79107088618737392972012-01-24T23:20:07.435-08:002012-01-24T23:20:07.435-08:00Great question. We do take into account the impact...Great question. We do take into account the impact of our changes to TCP on users with low access bandwidth, such as dial-up. A couple of examples: In the IW10 work we explicitly analyzed the large-scale experiment results for dial-up and mobile users. This is in addition to also doing more controlled testbed experiments to reproduce what we were observing in our cluster wide experiments. A second and more recent example, is the experiments with proportional rate reduction (PRR) in India datacenters where bandwidth is typically on lower end.Nandita Dukkipatihttps://www.blogger.com/profile/13857996384221048861noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-31956390580686966922012-01-24T18:03:30.819-08:002012-01-24T18:03:30.819-08:00Wouldn't it be wiser to implement this as a se...Wouldn't it be wiser to implement this as a separate protocol with a distinct IP Protocol Number value? You could call it Google Transport Protocol rather than TCP.<br /><br />There are a lot of TCP stacks out there, some of them in embedded systems. If even one of them is badly written all kinds of unpleasant havoc could occur if that stack interacts with your new version of TCP.<br /><br />The main reason I suggest this is that you can't just update the stack in an embedded application. It's frequently burned into ROM.cearnerhttps://www.blogger.com/profile/10655096227632136966noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-64990196569693130022012-01-24T17:29:06.517-08:002012-01-24T17:29:06.517-08:00Yep, all very true. Google also sponsors SCTP res...Yep, all very true. Google also sponsors SCTP research. All of our changes (or similar algorithms) can be ported to SCTP when the need arises.Matt Mathishttps://www.blogger.com/profile/18424053585638774517noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-63620551176587970512012-01-24T17:27:44.674-08:002012-01-24T17:27:44.674-08:00Early Retransmit did not help as much as we expect...Early Retransmit did not help as much as we expected. See the PRR paper for details. Given the relative complexity of the changes and the limited gain, other TCP improvements were higher priority.Matt Mathishttps://www.blogger.com/profile/18424053585638774517noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-52489801417664709142012-01-24T15:25:00.852-08:002012-01-24T15:25:00.852-08:00Multipath TCP is on our radar. Google has in fact ...Multipath TCP is on our radar. Google has in fact sponsored some of the projects through Google Research grant.ychenghttps://www.blogger.com/profile/11208449354218476820noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-77910932580844225792012-01-24T15:21:47.484-08:002012-01-24T15:21:47.484-08:00Linux kernel versions of the changes were applied:...Linux kernel versions of the changes were applied:<br /><br />1. Initial Congestion Window of 10 packets: 2.6.39-rc1<br />2. Initial Retransmission Timeout of 1sec: 3.1-rc1<br />3. Proportional Rate Reduction: 3.2-rc1<br />4. Fast Open: not yet. It's the most complicated change. We are still testing the patches internally and will upstream when it's ready.ychenghttps://www.blogger.com/profile/11208449354218476820noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-8803263305196358222012-01-24T15:20:10.487-08:002012-01-24T15:20:10.487-08:00Thats thinking outside the box....(I concur)Thats thinking outside the box....(I concur)Lucianhttps://www.blogger.com/profile/16992017316065042361noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-19477274403776873012012-01-24T15:17:05.887-08:002012-01-24T15:17:05.887-08:00Actually the core developer of SPDY, Mike Belshe, ...Actually the core developer of SPDY, Mike Belshe, is the major driver to our TCP changes. See his comments about TCP/SPDY at: <br />1. http://www.ietf.org/proceedings/80/slides/tsvarea-0.pdf<br />2. http://www.ietf.org/mail-archive/web/tcpm/current/msg06121.htmlychenghttps://www.blogger.com/profile/11208449354218476820noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-81590418089519493882012-01-24T14:33:20.442-08:002012-01-24T14:33:20.442-08:00you can't do that in windows 7. the article is...you can't do that in windows 7. the article is about "Server Configuration" which where administrators can reduce the execution time or even add database configuration settings, read about web.conig and asp.net :)Mahmoudhttps://www.blogger.com/profile/09732805248597464494noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-32306148219191240162012-01-24T14:30:22.424-08:002012-01-24T14:30:22.424-08:00well,I would love to add that (using None Post bac...well,I would love to add that (using None Post back strategies) can indeed reduces the amount the page takes to be served to the client, for example... using a server side code, will hold the page till the server side code is fully compiled... which may cause time out or even a deadlock in the database may happen!!! in this case you have no business reducing the page execution time out to 1 second... <br /><br />instead... <br />1-Enhance your database performance and always rebuild and reorganize your indexes.<br />2-Always Maintain your code so the execution time is shorter/faster.<br />3-Cash your pages.<br />4-Use AJAX :) <br />that will indeed maximize your webpage performance and will keep your users happy.... that's how I do it anyway.Mahmoudhttps://www.blogger.com/profile/09732805248597464494noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-31074954079963872882012-01-24T13:52:26.488-08:002012-01-24T13:52:26.488-08:00Why don't you actually work on SCTP? With its ...Why don't you actually work on SCTP? With its ability to carry multiple independent substreams, multiple HTTP could be issued with a single connection.j.enghttps://www.blogger.com/profile/09615346206411435754noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-36246635320585367202012-01-24T10:44:45.045-08:002012-01-24T10:44:45.045-08:00and how can i change these values of " Increa...and how can i change these values of " Increase TCP initial congestion window to 10 (IW10)" and "Reduce the initial timeout from 3 seconds to 1 second" on Windows 7?cyber8607https://www.blogger.com/profile/10799044147958100645noreply@blogger.comtag:blogger.com,1999:blog-11300808.post-90130547418782627432012-01-24T08:28:18.027-08:002012-01-24T08:28:18.027-08:00Did you guys look at losses in the last 3 packets ...Did you guys look at losses in the last 3 packets that can't be recovered from using SACK? IMO that is a big reason why HTTP sessions hang.Iljitsch van Beijnumhttps://www.blogger.com/profile/15023231386169577401noreply@blogger.com