-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
I recently found this article from google research. It is related to your question. An Argument for Increasing TCP's Initial Congestion Window Abstract (http://research.google.com/pubs/pub36640.html) TCP flows start with an initial congestion window of at most four segments or approximately 4KB of data. Because most Web transactions are short-lived, the initial congestion window is a critical TCP parameter in determining how quickly flows can finish. While the global network access speeds increased dramatically on average in the past decade, the standard value of TCP?s initial congestion window has remained unchanged. In this paper, we propose to increase TCP?s initial congestion window to at least ten segments (about 15KB). Through large-scale Internet experiments, we quantify the latency benefits and costs of using a larger window, as functions of network bandwidth, round-trip time (RTT), bandwidthdelay product (BDP), and nature of applications. We show that the average latency of HTTP responses improved by approximately 10% with the largest benefits being demonstrated in high RTT and BDP networks. The latency of low bandwidth networks also improved by a significant amount in our experiments. The average retransmission rate increased by a modest 0.5%, with most of the increase coming from applications that effectively circumvent TCP?s slow start algorithm by using multiple concurrent connections. Based on the results from our experiments, we believe the initial congestion window should be at least ten segments and the same be investigated for standardization by the IETF. The article: http://research.google.com/pubs/archive/36640.pdf artur Am 02.03.2011 17:54, schrieb Matthew Toseland: > We have two conflicting goals: > > 1. We want quick responses, especially for realtime requests, but in general, > at the layer of requests, inserts, sending messages etc. > > 2. We want TCP-like behaviour that is tolerant of packet loss, and works with > firewalls. > > It turns out that in some common cases these are mutually incompatible, > pointing in opposite directions. > > There are a fair number of places where we use a 10 second timeout. For > instance, when we send an Accepted to a CHK inserter, it should reply within > 10 seconds with a DataInsert. > > The problem is: > - The RFCs for TCP specify that retransmit timeouts start at ~ 2 seconds and > increase up to ~ 120 seconds. Note that before we implemented this (RFC 2988) > we had massive amounts of retransmission. > - We send keepalives every 7-14 seconds (was 14-28 seconds) and timeout a > connection if we receive no packets in 35 seconds (was 60 seconds). > > Network congestion and temporary glitches can cause severe latency. Severe > latency is incompatible with quick responses. For instance, my connection > seems to get 15 second pauses during which no packets are received from a > given peer; this could be a problem with my ISP or my router, but if I get it > it's likely a lot of other people get it too. We need to deal with this > properly, but how? > > Most places we now implement a two stage timeout. If we get a response within > a short period then we proceed; if we don't, we wait (off-thread, while the > main thread reroutes) for a longer period. If we still don't get a response > something is seriously wrong so we disconnect. Lately problems seem to mostly > come up in the few places that don't do this so arguably the default strategy > is to implement two stage timeout in those places. But it's a bit of a mess, > maybe there is a better solution? > > Another option would be to have a much shorter connection timeout (which > would require we send keepalives much more often), or a much longer timeout > in many of these cases. > > Thoughts? > Specifically asking for input from nextgens because of his experience with > low level networking in general and Ian because of his experience with > Dijjer, and because he originally pushed for short timeouts. > > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://freenetproject.org/cgi-bin/mailman/listinfo/devl -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNbq0pAAoJEMCbH/uYbXaW7T0H/R5bzZr5Iq6tZ0xnoO0OkGt6 X0HvAoP0rWl/aTXszu8EOcGeLGDb+vs2kTow3Jx7NhIBqy9gAVcJt7fqAPMyz6qg 1hjtaXfOKE6+/N1jZVOokO8Oy74gdTdkGuOf/AnH06VIS5uSF7GlnflHpeSc+WcI P71x1issLiXSAlYWi5GyYChvEPwx2NgaZ1AJlJXZxydwpkUTfwSw9NMITO/AHUAB jcqenEnvznukHWt2Ck1trt9qLrDkyFSf7NeiLu0nlAMoOfUPY+MwdHOtAiZAuZhk 2yMoEE54FD1mqM5rsMSi/1ZJVQ7PlY8tGyNgKnDRwb2hUKEpyB39T7IyStOBUIY= =Ld6I -----END PGP SIGNATURE-----
