I just finished reading a series of blogs by Jim Getty. The first of this series is http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/
To summarise, TCP, as we know, relies on packet loss to detect network congestion. But as memory prices have decreased, network buffers have increased, so that in many situations there can be more than a second of data queued before a packet is dropped. This is the cause of out latency problems.
He further suggests that this what kicked of the network neutrality debate. The design of XP and the fact that browsers followed the rules and limited the number of connections they used meant bittorrent was the first protocol that regularly saturated links.
Worth a read. now a question: how do we control the size of network buffers in our FreeBSD routers? How about ppp connections? How about pf queues? His mitigation methods are limiting your queues and bandwidth so that your link is the one dropping packets.
To summarise, TCP, as we know, relies on packet loss to detect network congestion. But as memory prices have decreased, network buffers have increased, so that in many situations there can be more than a second of data queued before a packet is dropped. This is the cause of out latency problems.
He further suggests that this what kicked of the network neutrality debate. The design of XP and the fact that browsers followed the rules and limited the number of connections they used meant bittorrent was the first protocol that regularly saturated links.
Worth a read. now a question: how do we control the size of network buffers in our FreeBSD routers? How about ppp connections? How about pf queues? His mitigation methods are limiting your queues and bandwidth so that your link is the one dropping packets.
