| |||||||||||||
Network transmit queue limitsNetwork transmit queue limitsPosted Aug 13, 2011 7:36 UTC (Sat) by butlerm (subscriber, #13312)Parent article: Network transmit queue limits According to the linked article, the patch which was merged in 2.6.38 increases the initial receive window, not the initial congestion window. A patch increasing the initial congestion window would be the sort of thing the IETF would frown upon - without their blessing, of course.
(Log in to post comments)
Initial congestion window Posted Aug 13, 2011 14:18 UTC (Sat) by corbet (editor, #1) [Link] No, it's the initial congestion window; I'm not quite sure where this comes from. And yes it went through a long process with the IETF first.
In the wild Posted Aug 13, 2011 14:51 UTC (Sat) by dmarti (subscriber, #11625) [Link] If you're using Google or Microsoft web sites, you're probably also testing this: Google and Microsoft Cheat on Slow-Start. Should You?
Initial congestion window Posted Aug 14, 2011 0:11 UTC (Sun) by butlerm (subscriber, #13312) [Link] Sorry for creating any confusion. I see on git.kernel.org that both patches have made it in, which is good news. However, I believe that the increase to the initial congestion window is still a draft, not an RFC.
Network transmit queue limits Posted Aug 15, 2011 14:22 UTC (Mon) by nye (guest, #51576) [Link]
(Please excuse the naivety of this question)
I can't wrap my head around slow-start, probably because I don't think I understand the problem it's intended to solve.
What I'm wondering is: since the sender already has an upper bound for the min-RTT, why is the initial congestion window set to a fixed number rather than to "the number of segments that can be transmitted in the RTT" (or the receiver's advertised window if smaller)?
I guess this wouldn't work for high-latency congested links since the initial window is IIUC used as the *minimum* window to fall back to when congestion occurs, but why does that need to be the case? I suspect the answer to this question may be along the lines of "that's the point of slow-start", but it's not intuitive to me.
If anyone knows of any resources which explain this problem from "first principles" - ie. without requiring the reader to already have more than a passing familiarity with TCP - I'd appreciate a pointer.
Network transmit queue limits Posted Aug 16, 2011 22:19 UTC (Tue) by jch (guest, #51929) [Link]
> If anyone knows of any resources which explain this problem from "first principles"
I don't have my library handy, but I seem to recall that Tanenbaum discusses TCP congestion control at length. I'm sure you'll find something good in Stevens too.
> I can't wrap my head around slow-start, probably because I don't think I understand the problem it's intended to solve.
I'll make the bold claim that nobody fully understands the dynamics of TCP.
I wasn't there (so I'm probably wrong), but I believe that slow-start was designed as a fairly naive mechanism because it was not supposed to matter much in practice. TCP connections were supposed to be either long-lived bulk transfers (FTP, say), or interactive flows (telnet, or the conversational phase of SMTP). In the first case, slow-start only happens at the beginning of the transfer, which is a negligible part of the connection, while in the second case the size of the congestion window doesn't matter.
The trouble is with HTTP, which causes a lot of short-lived connections. Such a short-lived connection spends most or all of its life in slow-start. Hence the need for sharing state between different connections (which Linux does AFAIR) or tweaking the initial window.
> since the sender already has an upper bound for the min-RTT, why is the initial congestion window set to a fixed number rather than to "the number of segments that can be transmitted in the RTT"
Recall that the congestion window is there to limit congestion: it should decrease as congestion increases. With typical queueing techniques, the RTT increases with congestion, so what you are suggesting has the opposite of the desired dynamics.
Yeah, it's tricky. No, I don't claim to understand the trade-offs involved.
--jch
Network transmit queue limits Posted Aug 17, 2011 12:05 UTC (Wed) by nye (guest, #51576) [Link]
>I don't have my library handy, but I seem to recall that Tanenbaum discusses TCP congestion control at length. I'm sure you'll find something good in Stevens too.
Thanks for the reference. I don't know Stevens - I assume you're talking about TCP/IP illustrated? I notice there's a second edition due out later this year. Sadly not in paperback though; can't stand hardbacks so I'll probably give it a miss.
>> since the sender already has an upper bound for the min-RTT, why is the initial congestion window set to a fixed number rather than to "the number of segments that can be transmitted in the RTT"
> Recall that the congestion window is there to limit congestion: it should decrease as congestion increases. With typical queueing techniques, the RTT increases with congestion, so what you are suggesting has the opposite of the desired dynamics.
Sorry, I should have said "the number of segments that can be transmitted in the *minimum* RTT", and then only as the *initial* cwnd. The thinking being that it can't possibly have received an ACK yet, so the fact that it hasn't need not imply congestion. I haven't really thought through the implications of that in the case that the 3-way handshake is made under highly congested conditions though, giving a vastly inaccurate bound for the min-RTT
>I wasn't there (so I'm probably wrong), but I believe that slow-start was designed as a fairly naive mechanism because it was not supposed to matter much in practice. TCP connections were supposed to be either long-lived bulk transfers (FTP, say), or interactive flows
This is interesting, from the point of view of how we're predominantly using a protocol for something a little out of its design parameters.
(I was going to go off on a tangent here about using TCP/IP in circumstances which break its design assumptions, like bufferbloat and highly asymmetrical connections, but I need to think about it some more)
Network transmit queue limits Posted Aug 17, 2011 16:20 UTC (Wed) by butlerm (subscriber, #13312) [Link]
>I wasn't there (so I'm probably wrong), but I believe that slow-start was designed as a fairly naive mechanism because it was not supposed to matter much in practice
It is worth keeping in mind that slow start is not very slow - it is a doubling of the congestion window (and hence average transmit bandwidth) every round trip time. If you don't have something like slow start a new connection tends to immediately saturate every bottleneck link, causing large scale packet loss not only on the new connection, but all the others using the link as well.
That puts all the (congestion controlled) flows on the link into some sort of recovery mode, which is generally much slower than slow start is in the first place - a constant increase every RTT rather than a multiplicative one.
It works, the flows do sort themselves out, but it isn't very friendly, and usually doesn't even help the new connection. That is why they adopted "slow" start in the first place. It replaced previous practice of saturating the outbound link until some sort of loss indication was received. Running a gigabit per second flow into a ten megabit per second link doesn't work all that well.
|
|||||||||||||