Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vint Cerf on mistakes he made in TCP/IP

spectrum.ieee.org

Post reply on HN
Print view View original

61–70 of 167 posts

Re: Vint Cerf on mistakes he made in TCP/IP

#61

Post by rinka_singh »

checkyoursudo wrote: post #7
em3rgent0rdr wrote: post #5

Cerf: "I'm serious, the decision to put a 32-bit address space on there was the result of a year's battle among a bunch of engineers who couldn't make up their minds about 32, 128 or variable length. And after a year of fighting I said -- I'm now at ARPA, I'm running the program, I'm paying for this stuff and using American tax dollars -- and I wanted some progress because we didn't know if this is going to work. So…

This is a good lesson. I've done a lot of pilot studies, prototypes, proof-of-concept experiments. It is scary^1 how many times "let's just get this tested and see if it even works" turns into "welp, that worked and we don't have time or funding to do another one, so that's the final version." The constraint is often time. Gotta get a product out, or run an follow-on experiment that depended on the first, or submit a…

:-P ChatGPT?

Re: Vint Cerf on mistakes he made in TCP/IP

#62

Post by justinclift »

Dalewyn wrote: post #10
checkyoursudo wrote: post #7

Earlier quoted context omitted.

This is a good lesson. I've done a lot of pilot studies, prototypes, proof-of-concept experiments. It is scary^1 how many times "let's just get this tested and see if it even works" turns into "welp, that worked and we don't have time or funding to do another one, so that's the final version." The constraint is often time. Gotta get a product out, or run an follow-on experiment that depended on the first, or submit a…

An old Russian proverb goes: There is nothing more permanent than a temporary solution.

Yeah, I've heard the same thing in several contexts before too. Without any mention of nationality. :)

Re: Vint Cerf on mistakes he made in TCP/IP

#63

Post by ly3xqhl8g9 »

samwillis wrote: post #59
ly3xqhl8g9 wrote: post #47

Earlier quoted context omitted.

In some ideal world IP values vary between 0 and 999 and you just add a new block if you run out of them, `999.999.999.999` would be the last standard IP, simply add another `.000` block and you get some more billions IPs. Having letters in IPv6 feels wrong, at that point why not just have words, reinvent DNS at a lower level. You are already living on Cherry Picked Street, number 15, let your computer have the IP `c…

So basically just "what three words" but for IP. Just don't let a VC backed company own the address space and then encourage public/government organisation to adopt it!

Funny idea, wanted to write some quip on why it's bad, given the inherent polysemy, but someone already did it [1].

[1] "What’s wrong with what3words?", Chapter 3, "offends.people.easily", covers it, https://www.youtube.com/watch?v=SqK0ciE0rto

Re: Vint Cerf on mistakes he made in TCP/IP

#64

Post by amoss »

XorNot wrote: post #36
amoss wrote: post #31

Earlier quoted context omitted.

People hate kludges and backward compatibility, but IPv4.1 with 5-byte addresses would have been the dominant standard by now.

No, it wouldn't have been. Where are you going to put that extra byte? How is an intermediate box going to know what to do with it? How is a routing ASIC going to handle it? This is thinking which appeals to people who don't understand the problem because it feels like a compromise, but you can't negotiate with silicon . If it expects a 4 byte address payload, then that's all it will ever handle. Adding more bytes is…

Nah, hardware people just don't negotiate hard enough.

Add a one-byte option into the header, give it an unassigned value (e.g. 6) and assume that any box that does not understand it will pass it through unchanged. Use it as the most significant byte of the address, and obsolete all routing equipment that doesn't understand it from the backbone so that they can be used to handle routing in one of the new 32-bit super-A class networks.

Sure it's ugly as hell, but it is just backward compatible enough to work.

Re: Vint Cerf on mistakes he made in TCP/IP

#65

Post by em-bee »

em3rgent0rdr wrote: post #5

Cerf: "I'm serious, the decision to put a 32-bit address space on there was the result of a year's battle among a bunch of engineers who couldn't make up their minds about 32, 128 or variable length. And after a year of fighting I said -- I'm now at ARPA, I'm running the program, I'm paying for this stuff and using American tax dollars -- and I wanted some progress because we didn't know if this is going to work. So…

Klingon software is not released. Klingon software escapes, leaving a bloody trail of design engineers and quality assurance testers in its wake.

Re: Vint Cerf on mistakes he made in TCP/IP

#66

Post by XorNot »

amoss wrote: post #64
XorNot wrote: post #36

Earlier quoted context omitted.

No, it wouldn't have been. Where are you going to put that extra byte? How is an intermediate box going to know what to do with it? How is a routing ASIC going to handle it? This is thinking which appeals to people who don't understand the problem because it feels like a compromise, but you can't negotiate with silicon . If it expects a 4 byte address payload, then that's all it will ever handle. Adding more bytes is…

Nah, hardware people just don't negotiate hard enough. Add a one-byte option into the header, give it an unassigned value (e.g. 6) and assume that any box that does not understand it will pass it through unchanged. Use it as the most significant byte of the address, and obsolete all routing equipment that doesn't understand it from the backbone so that they can be used to handle routing in one of the new 32-bit super…

"just upgrade every backbone router to handle it" - you've just recreated the same problem.

Routers don't run packet addresses through software, they run then through silicon ASICs which know the address is 32 bits, that's it.

Your solution is literally how Cisco implemented IPv6 on a bunch of it's switches: the IPv6 routing path goes through the firmware and is slow as hell compared to the pure ASIC IPv4 handling. It didn't catch on because it was terrible at any scale (we were building Hadoop clusters, 100+ big data nodes with constrained throughout is money down the drain).

Re: Vint Cerf on mistakes he made in TCP/IP

#67

Post by bauruine »

ly3xqhl8g9 wrote: post #47
bushbaba wrote: post #11

Earlier quoted context omitted.

I really wish we just did ipv4 on 64 but addresses. IPv6 is nearly a totally different paradigm, and has lead to adoption pain. Biggest being usability taking a back seat. People are being forced into using ipv6 not cause they want to, but from ip space exhaustion.

In some ideal world IP values vary between 0 and 999 and you just add a new block if you run out of them, `999.999.999.999` would be the last standard IP, simply add another `.000` block and you get some more billions IPs. Having letters in IPv6 feels wrong, at that point why not just have words, reinvent DNS at a lower level. You are already living on Cherry Picked Street, number 15, let your computer have the IP `c…

An IPv4 address on the wire is just a 32 Bit integer in big endian. The quad-dotted notation is the most common for IPv4 but you could also use hex or decimal. There was an article on HN just recently about that. I can't find it right now but try ping 0x7F000001 to get an idea. You don't even need a new protocol you could implement something like what three words or your 999.999.999 naming scheme locally and use it on the internet right now! No need to replace any routers or have anyone else upgrade.

Re: Vint Cerf on mistakes he made in TCP/IP

#68

Post by IshKebab »

jandrese wrote: post #42
jiggawatts wrote: post #30

In my experience, the biggest issue with TCP is that it assumes that the traffic is a single continuous byte stream, whereas the majority of applications send messages . Vint mentioned the lack of encryption as a mistake, but even on private networks, the 16-bit TCP checksums are too weak to protect against bit-flips. Many orgs noticed that enforcing encryption reduces "random" crashes and errors, because it also enf…

IMHO TCP made the correct call here. TCP is a transport, not an application protocol. You are supposed to run your protocol over top of it, including things like blocking, substreams, etc... It's easy to add features to a simple transport, it's not so easy to work around features when you don't want them, plus they end up complicating the stack and become a possible source of bugs. Even "simple" TCP proved to be quit…

Sure that's how people are forced to use TCP, but for performance reasons that's not how they want to use it.

IMO something like SCTP would have been better. You generally want multiple independent streams (to avoid head of line blocking), message and stream transmission, and optional reliability on a per-stream/message basis.

This sort of thing is very very common in real time games (e.g. enet). Actually enet is built on UDP, but if you compile it to WASM then the Emscripten UDP implementation uses the WebRTC data channel which uses SCTP!

Re: Vint Cerf on mistakes he made in TCP/IP

#69

Post by amoss »

XorNot wrote: post #66
amoss wrote: post #64

Earlier quoted context omitted.

Nah, hardware people just don't negotiate hard enough. Add a one-byte option into the header, give it an unassigned value (e.g. 6) and assume that any box that does not understand it will pass it through unchanged. Use it as the most significant byte of the address, and obsolete all routing equipment that doesn't understand it from the backbone so that they can be used to handle routing in one of the new 32-bit super…

"just upgrade every backbone router to handle it" - you've just recreated the same problem. Routers don't run packet addresses through software, they run then through silicon ASICs which know the address is 32 bits, that's it. Your solution is literally how Cisco implemented IPv6 on a bunch of it's switches: the IPv6 routing path goes through the firmware and is slow as hell compared to the pure ASIC IPv4 handling. I…

So how many backbone routers are 20 years old?

Your claim was that any change to the ASIC was the same design cost. But really? A 40-bit routing table design, where there is a 32-bit fall-back to preserve the top 8-bits vs a 128-bit routing table design. Why would these be the same cost?

Re: Vint Cerf on mistakes he made in TCP/IP

#70

Post by suprjami »

bauruine wrote: post #67
ly3xqhl8g9 wrote: post #47

Earlier quoted context omitted.

In some ideal world IP values vary between 0 and 999 and you just add a new block if you run out of them, `999.999.999.999` would be the last standard IP, simply add another `.000` block and you get some more billions IPs. Having letters in IPv6 feels wrong, at that point why not just have words, reinvent DNS at a lower level. You are already living on Cherry Picked Street, number 15, let your computer have the IP `c…

An IPv4 address on the wire is just a 32 Bit integer in big endian. The quad-dotted notation is the most common for IPv4 but you could also use hex or decimal. There was an article on HN just recently about that. I can't find it right now but try ping 0x7F000001 to get an idea. You don't even need a new protocol you could implement something like what three words or your 999.999.999 naming scheme locally and use it o…

It's the human method of interacting with that integer which is the problem.

Nobody is going to start saying IPv4 addresses as hex, people aren't used to base 16. "Just set your gateway to co.a8.0.fe" said nobody ever.

A 128-bit dotted quad would be equally unwieldy. Again "The IPv6 local range is 252.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000/7" said nobody ever.

Honestly 128 bits was too much. They should have just done 64 and stuck to dotted quad and ARP. That would probably have got more acceptance than what we have now.

Post reply on HN