| |||||||||||||
Bufferbloat: Dark Buffers in the Internet (ACM Queue)Bufferbloat: Dark Buffers in the Internet (ACM Queue)Posted Dec 7, 2011 13:26 UTC (Wed) by marcH (subscriber, #57642)In reply to: Bufferbloat: Dark Buffers in the Internet (ACM Queue) by dlang Parent article: Bufferbloat: Dark Buffers in the Internet (ACM Queue)
> ... is breaking the TCP ack clocking mechansim
... which does not mean TCP will go mad and send even more packets and clog whatever queues even more. I would bet it is actually the opposite.
Anyway, I only had the "reasonable queue size @ bottleneck" case in mind in my previous post. In this "normal", non-bufferbloated case ACK-clocking works fine and there is no need for externally throttling TCP anywhere else than at the bottleneck's queue when it fills up.
*In theory* not just TCP but every other protocol should be a good citizen and follow TCP's lead in respect to congestion/throttling: http://en.wikipedia.org/wiki/Datagram_Congestion_Control_...
I would not be surprised if TCP is actually the worst guy for falling in and filling bufferbloat traps. There is some irony in that considering it is usually considered the best congestion citizen *in the lack of bufferbloat*.
(Log in to post comments)
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 7, 2011 16:39 UTC (Wed) by martinfick (subscriber, #4455) [Link]
> I would not be surprised if TCP is actually the worst guy for falling in and filling bufferbloat traps. There is some irony in that considering it is usually considered the best congestion citizen *in the lack of bufferbloat*
I had the same thought myself and was wondering if TCP needs to be fixed to take latency into account? From my lame understanding it seems to only care about throughput, isn't that why the bittorrent folks came up with their own UDP based solution? So, while I am all for fixing buffers wherever possible, shouldn't there be more discussion about fixing TCP?
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 7, 2011 22:58 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
actually, what is happening is that TCP (eventually) gets the acks for the packets that it sends, so it speeds up to try and send more traffic.
eventually the delay gets so large that it times out before the acks arrive and the speed collapses.
If you look at the graphs in Getty's paper, you will see exactly this sort of picket-fence for what he is calling 'goodput', which is the amount of traffic that is actually getting to the destination (with the rest of the available bandwidth being taken up by 'badput', which is packets that are going to be dropped by the time they get to the destination because they are either too old, or they are retransmissions of packets that are still in flight, and so will be duplicates by the time they get there)
|
|||||||||||||