Re: TCP congestion control and large router buffers
On Tue, 14 Dec 2010, Sam Stickland wrote:
But there's no need for AQM, just smaller buffers would make a huge difference.
Well, yes, buffering packets more than let's say 30-50ms on a 1 meg link doesn't make much sense. But doing some basic AQM would make things even better (some packets would see 0 buffering instead of 30ms).
Surely buffers that can store seconds worth of data are simply too big?
FIFO with seconds worth of data is just silly, yes. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, 14 Dec 2010, Sam Stickland wrote:
But there's no need for AQM, just smaller buffers would make a huge difference.
Well, yes, buffering packets more than let's say 30-50ms on a 1 meg link doesn't make much sense. But doing some basic AQM would make things even better (some packets would see 0 buffering instead of 30ms).
Surely buffers that can store seconds worth of data are simply too big?
FIFO with seconds worth of data is just silly, yes.
-- Mikael Abrahamsson
Well, Jim Getty was reporting seeing "tens of seconds" of buffering (comments in the original LWN link to his first posting) which is just ludicrous. No TCP stack is going to respond properly to congestion with that sort of delay. Some form of AQM is probably a good thing as would be the wider use of ECN. Finding out that a buffer filled and a packet (or many packets) was dropped five seconds after the fact, isn't going to help anyone and you just end up whipsawing the window size (Lawrence Welk effect http://www.oeta.onenet.net/welk/PM/images/Lawrence.jpg ?). I would favor seeing more use of ECN so that a sender can be notified to back off when a buffer is approaching capacity but there is apparently still a lot of hardware out there that has problems with it. You need enough buffering to satisfy packets "in flight" for a connection on the other side of the planet but man, what he has been reporting is just insane and it would be no wonder performance can be crap.
On Tue, 14 Dec 2010, George Bonser wrote:
that sort of delay. Some form of AQM is probably a good thing as would be the wider use of ECN. Finding out that a buffer filled and a packet (or many packets) was dropped five seconds after the fact, isn't going
ECN pretty much needs WRED, and then people need to implement that first. The only routing platform I know to support it is 7200 and the other types of cpu routers from Cisco running fairly recent IOS (seems to have been introduced in 12.2T). http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftwrdecn.html
You need enough buffering to satisfy packets "in flight" for a connection on the other side of the planet but man, what he has been reporting is just insane and it would be no wonder performance can be crap.
Yeah, 30-60ms of buffering is what I have favoured so far. With L2 switches you don't get anywhere near that, but on the other side a few ms of buffering+tail drop has much less impact on interactive applications compared to seconds of buffering. -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (2)
-
George Bonser -
Mikael Abrahamsson