I'm a bit confused that multiplexing over one TCP connection is somehow seen as a strength of this new protocol. OK. I see how muxing streams over a TCP session

I'm a bit confused that multiplexing over one TCP connection is somehow seen as a strength of this new protocol. OK. I see how muxing streams over a TCP session theoretically allows the TCP session to "fill" the available bandwidth for a longer period of time. But it also means that every stream in the session will suffer from a few packet drops (and the resultant "sputtering" slow starts over lossy physical media, ie. the mobile use-case). As for why flow control is being pushed into the app layer, the answer again comes down to multiplexing of multiple streams over one TCP connection (since without stream-level flow control, one slow end-point for a stream can potentially block the progress of every other stream in that session... see discussion here: https://groups.google.com/forum/#!topic/spdy-dev/g4PiZBTW-34 https://groups.google.com/forum/#!topic/spdy-dev/g4PiZBTW-34) I guess in the end, only real measurements with a mature implementation will answer the question. As it turned out with SPDY (1), the results of all this work might still not be enough to overcome the basic problems with TCP. (1) http://www.guypo.com/technical/not-as-spdy-as-you-thought/ http://www.guypo.com/technical/not-as-spdy-as-you-thought/