On 3/24/21 2:24 PM, Phillip
Hallam-Baker wrote:
On Wed, Mar 24, 2021 at 10:46 AM Behcet Sarikaya <sarikaya2012@xxxxxxxxx> wrote:
On Tue, Mar 23, 2021 at 4:19 PM Joe Touch <touch@xxxxxxxxxxxxxx> wrote:
> On Mar 23, 2021, at 2:05 PM, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>
>> On 3/23/21 3:57 PM, Spencer Dawkins at IETF wrote:
>>
>> I'd like to see some observance like this. Another related day that might serve was the TCP/IP Flag Day, when Arpanet stopped carrying NCP, on January 1, 1983.
>
> Maybe the public Internet can start filtering advertisements for IPv4 prefixes on the 40th anniversary of that date?
That’s one way to make sure the Internet doesn’t make it to 41.
+1
Also let's celebrate as Toerless suggests on January 1, 2023 as TCP/IP Flag Day.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.
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'.
IPsec certainly suffered this fate, though with filtering I'm not
sure if it would have the right security properties for tunnel
mode. Certainly had we used transport mode IPsec instead of SSL we
wouldn't be coming back 25 years later worried about the TCP
checksum.
Mike
