On 5 Feb, 2012, at 2:24 am, George B. wrote: > I have yet another question to ask: On a system where the vast > majority of traffic is receive traffic, what can it really do to > mitigate congestion? I send a click, I get a stream. There doesn't > seem to be a lot I can do from my side to manage congestion in the > remote server's transmit side of the link if I am an overall receiver > of traffic. > > If I am sending a bunch of traffic, sure, I can do a lot with queue > management and early detection. But if I am receiving, it pretty much > just is what is and I have to play the stream that I am served.
There are two good things you can do. 1) Pressure your ISP to implement managed queueing and ECN at the head-end device, eg. DSLAM or cell-tower, and preferably at other vulnerable points in their network too. 2) Implement TCP *receive* window management. This prevents the TCP algorithm on the sending side from attempting to find the size of the queues in the network. Search the list archives for "Blackpool" to see my take on this technique in the form of a kernel patch. More sophisticated algorithms are doubtless possible. - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
