On 2014–04–17, at 9:37 AM, William Chan (陈智昌) <willchan@chromium.org> wrote: > TCP flow control often stalls applications. Especially when networks strip out window scaling (this definitely happens, but I unfortunately have no public data to share here). And then there's the historical issue with Linux receive windows being too small by default: https://www.belshe.com/2010/11/19/linux-client-tcp-stack-slower-than-windows/. That’s gonna make it slow, not stalled. I gather that the condition of present concern is when a client accidentally allows the window of a particular stream to go to zero, due to intentionally failing to send receipts as a throttle control. The client screwed up the accounting and gets confused. However it can also occur upstream by an intermediary that fails to anticipate all the corner cases of such client-initiated throttling to prevent its intermediate windows from glitching to zero. (At least, I anticipate this, I haven’t yet worked through a blow-by-blow example.) The solution is not to use flow control for relative throttling but priority instead. Don’t play with fire!
Received on Thursday, 17 April 2014 01:48:51 UTC