On 3/24/21 5:24 PM, Phillip Hallam-Baker wrote:
As an implementation decision I think that made sense at the time. The relationship between various costs has changed a lot since then.My guess is by then QUIC will be ready to take over TCP, so after that day, TCP/IP no more but long live QUIC/IP
That won't ever happen because the mistake in TCP/IP was to imagine that transport is a kernel level concern.
Certainly agree with the last part. I don't know why the entire spectrum of Internet applications should run over a single transport protocol, and the over-reliance on cleartext TCP to date has created a fertile ground for middleboxes to screw things up in various ways.Transport started moving to the application stack when SSL happened. And QUIC is only the logical endpoint. But contrary to expectations here, the logic that there can only be one TCP does not apply to QUIC. Once you move Transport up to application, it is going to be game on and QUIC is going to be the first of many.
And this is a good thing. TCP responds poorly to HTTP needs because it is optimized for file transfer. QUIC is optimized for Web browsing. QUIC is not optimized for every Internet application because not everything is Web browsing and not every Internet application is a Web browser. That wasn't the goal in 1992 and it certainly isn't the goal now that Web browsers are entering middle age with a rather nasty case of 'spread'.
Not sure I agree that TCP was optimized for file transfer - certainly a transport that's optimized for file transfer doesn't need to ensure strict ordering of all messages sent from one peer to another as long as they get reassembled in correct order when the file is written. Otherwise, I agree.
Keith
