4 ms·

HTTP2 is a layering violation because it implements a new layer of multiplexing and flow control on top of the existing layer of multiplexing and flow control.

by magila 12y ago

HTTP2 is a layering violation because it implements a new layer of multiplexing and flow control on top of the existing layer of multiplexing and flow control. Rather than solving the problems with TCP they slapped a band-aid on top because that allowed them to get to market faster. In the short term it's a win for Google et al, but in the long term this sort of thing will turn the internet into (even more of) an unmanageable mess.

tptacek 12y ago
There's a huge cost to "solving problems with TCP": the existing protocol is intricately coupled between implementations (see: every attempt to improve TCP congestion control since Vegas) and so widely deployed as to be impossible to forklift out. Meanwhile: new protocols deployed alongside TCP aren't firewall-friendly. If there's a multiplexing problem to be solved on the Internet, it more-or-less must be solved above TCP, no matter what the "layering" guidelines are. Meanwhile: I'm still not clear on why these "layers" exist, or need to be dignified. The whole idea of a "layer" of complicated functionality is in tension with the End To End Argument: if there's a debate about how something should be implemented, that thing should be implemented as close to the endpoints and as close to the application as possible.
- magila 12y ago
  Sure, it would be a huge amount of work to fix/replace TCP. Google is one of the few companies with the resources to even attempt it, so it's disappointing that they aren't making it a priority. The really frustrating thing is that Google is already working on QUIC, which is probably the best approach with a realistic chance of success. It removes TCP from the stack and provides a general purpose transport layer rather than one which is tightly coupled to HTTP. Unfortunately Google decided to push SPDY with it's own kludged up transport rather than taking the time to do it right with SPDY over QUIC.

by magila 12y ago

tptacek 12y ago

There's a huge cost to "solving problems with TCP": the existing protocol is intricately coupled between implementations (see: every attempt to improve TCP congestion control since Vegas) and so widely deployed as to be impossible to forklift out. Meanwhile: new protocols deployed alongside TCP aren't firewall-friendly. If there's a multiplexing problem to be solved on the Internet, it more-or-less must be solved above TCP, no matter what the "layering" guidelines are. Meanwhile: I'm still not clear on why these "layers" exist, or need to be dignified. The whole idea of a "layer" of complicated functionality is in tension with the End To End Argument: if there's a debate about how something should be implemented, that thing should be implemented as close to the endpoints and as close to the application as possible.

magila 12y ago
Sure, it would be a huge amount of work to fix/replace TCP. Google is one of the few companies with the resources to even attempt it, so it's disappointing that they aren't making it a priority. The really frustrating thing is that Google is already working on QUIC, which is probably the best approach with a realistic chance of success. It removes TCP from the stack and provides a general purpose transport layer rather than one which is tightly coupled to HTTP. Unfortunately Google decided to push SPDY with it's own kludged up transport rather than taking the time to do it right with SPDY over QUIC.