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

21–30 of 167 posts

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

#21

Post by elihu »

m348e912 wrote: post #3
ksec wrote: post #2

Had TCP/IP been 64bit to begin with things would be a lot different.

For the time 32bit was more than adequate, not to mention routers only had so much memory and processing power.

Funny enough, one of the arguments for longer key lengths now is to save memory. With IPV4 the way it is now, the address space is very fragmented so you need a lot of router table entries. More available address space means more contiguous address blocks and therefore fewer router table entries.

That wasn't an issue back when IPv4 was being defined though.

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

#23

Post by _the_inflator »

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…

In hindsight. ;)

To me this sounds like the winner's bias: in hindsight.

It is hard to balance a prototype against a "works under all conditions no matter what they are" production-ready solution without growing into a hard to handle monster solution. On the other side I know off quite some overhyped apps, that rest on a overpowered machine, because the specs did not account for one thing: no one cares about the product.

Extensibility is the key to balance certain weaknesses in a spec.

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

#25

Post by jandrese »

makeitdouble wrote: post #19
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…

That's always the bind. - If it fails: welp, we were right to not spend months on this discussion. - If it wildly succeeds: welp, it's now too costly to change for so many users. Having a mild and steady usage growing curve is a blessing that's too often overlooked.

It's always frustrating and amusing to read an anecdote about a design flaw in something where the creator goes "Yeah, we discovered that X was a bad idea, but there were already almost 10 people using it so it was too late to change."

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

#26

Post by astrange »

clouddrover wrote: post #4

> “I didn’t really appreciate the implications of the World Wide Web.” That's not a mistake in TCP/IP.

QUIC doesn't run on TCP for this reason; it wants to avoid the head of line blocking issues.

The earlier attempts to replace it like SCTP didn't work out because too much middleware blocks it.

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

#27

Post by astrange »

merlyn wrote: post #16
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.

IPv4 today is a totally different paradigm than what IPv4 was in the 1980's and early 1990's. IPng (IPv6) was designed when the original paradigm existed, not what we have now-a-days. So, if we actually had been on track to do IPv6 in the decade it was defined, we could have gone a totally different way. Instead due to the rapid growth of the Internet in the mid 90's, IPv4 was morphed into something different and IPv…

IPv6 itself isn't the right thing for mobile internet either; people expect their IP address to not change when they migrate towers, meaning the entire approach to routing doesn't work.

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

#28

Post by amoss »

jandrese wrote: post #25
makeitdouble wrote: post #19

Earlier quoted context omitted.

That's always the bind. - If it fails: welp, we were right to not spend months on this discussion. - If it wildly succeeds: welp, it's now too costly to change for so many users. Having a mild and steady usage growing curve is a blessing that's too often overlooked.

It's always frustrating and amusing to read an anecdote about a design flaw in something where the creator goes "Yeah, we discovered that X was a bad idea, but there were already almost 10 people using it so it was too late to change."

Tabs in makefiles is another classic.

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

#29

Post by jandrese »

_8j50 wrote: post #15
ksec wrote: post #2

Had TCP/IP been 64bit to begin with things would be a lot different.

Or... hear me out: variable length, ideally with support for ascii or other encodings allowing human readable addresses ( no dns!) and routing done using top level addresses. "AAA.CA" becomes 4143.414141, routers will find the best route for 4143 and anycast ti 414141. , the apex AAA in this case would also be the ASN equivalent for bgp type routing and the TLD CA would also be the PKI certificate authority used to v…

The hard part is handling variable length addresses fast in hardware. Historically there has always been a sizeable speed penalty for making hardware deal with variable length anything.

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

#30

Post by jiggawatts »

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 enforces a strong checksum, typically 128 or 256 bit. However, even a 32-bit checksum would have sufficed for ordinary use.

Almost all "real" protocols built on top of TCP eventually end up reinventing the same wheels: message boundaries, logical sub-streams with priorities, and strong checksums or encryption. Examples include Citrix's ICA, HTTP 3.0, gRPC, etc...

Post reply on HN