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

101–110 of 167 posts

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

#101

Post by pmarreck »

ajross wrote: post #90
chrisfosterelli wrote: post #79

Earlier quoted context omitted.

On the flip side, how many times do we hear about projects that failed because the dev team was stuck building things that were never needed or never used? It's hard to see the future.

That's it. The causality analysis in the grandparent is exactly backwards. We don't live in a world of "productized prototypes" because people are too lazy to do things right. We live in the world of prototypes because prototypes are the only products that reach market . Even where beautiful works of engineering exist, then tend to be beaten to the punch by the competing prototype anyway. You don't treat this by whin…

Right. In that vein, it wasn't the 32 bit limitation that was the real problem. It was the inescapable 32 bit limitation built into the design that was the problem. They could have spent a few bits to version the packet format, for example, which would have at least provided an escape hatch. Or heck, a single bit: Value of 0, known original format. Value of 1, unknown format (or known future format, to be parsed by some future IP packet decoder, but which errors out old decoders).

And they repeated the same mistake with the IPv6 design by not making it an evolution of or backwards-compatible with IPv4.

Literally neither of these was built with scalability in mind.

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

#104

Post by zackmorris »

It's easy to poke holes in any protocol, so I usually just stick to conceptual flaws (oversights that are obvious to someone who hasn't seen the implementation). These are the biggest for me:

* TCP should have been a layer above UDP, not beside it. Or UDP and the urgent/out-of-band option in TCP should have been equivalent. This would prevent the blocking of UDP in corporate networks and countries trying to stop P2P networks.

* Both the network address and checksum should have been variable-length.

* NAT should not exist, because variable-length addresses would have negated most of its usefulness (other than for censorship).

* TCP should have been designed for networks with high latency (minutes/hours/days) to be ready for use in space. Optimistic delivery (is this the word?) should have been used instead of handshakes, but this might have required encryption from the start, to prevent sending sensitive information to the wrong recipient before it's verified.

* Address negotiation should have been built-in, so that peers IDs stay connected if the network changes, regardless of their IP addresses. TCP is a connected protocol (unlike UDP which is connectionless) so this was never really considered, but connected protocols simply don't work on the mobile web without yak shaving or embedding the stream in a tunnel that handles reconnection.

These issues are all severe enough that we probably shouldn't be using TCP directly. I know that they would haunt me had I designed it. It would be nice if the web provided a WebSocket that wasn't terrible, that handled everything mentioned above. Also I wonder if we scrapped all NAT workarounds, what it would take to provide something mathematically equivalent to direct connections, perhaps with homomorphic encryption, through open matchmaking servers kind of like Tor exit nodes.

Edit: I forget to add why these discussions are important. There's a tendency today to drink the Kool-Aid and assume that standards are perfect, when in reality they are often highly-opinionated, which creates a heavy burden on people who think differently. Flawed standards are a form of injustice.

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

#105

Post by pmarreck »

kjs3 wrote: post #83
amoss wrote: post #28

Earlier quoted context omitted.

Tabs in makefiles is another classic.

Except tabs in makefiles only require ones to acknowledge 'makefiles use tabs and here are the rules'. It's otherwise only something for pedants to obsess over. IPV4 address contention has a bit more real-world impact.

No one and I mean NO ONE had any clue how widely deployed IPv4 would end up being. It went literally beyond everyone's wildest expectations who was alive at the time of its inception.

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

#106

Post by pmarreck »

mixmastamyk wrote: post #82
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…

Never have gotten a good answer to this, “why is 64 bits not enough?” Here, why not an option? It’s astronomically larger than 32, not double.

Heck, just adding another byte to it to make it 2^40 would have given us 1,099,511,627,776 or 1 trillion+ possible addresses.

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

#107

Post by harha_ »

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…

This is also how I see it, even though I've only done relatively simple work with plain old TCP. It's just a stream of bytes, you then interpret it however your protocol on top of TCP requires.

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

#108

Post by cryptonector »

> “I didn’t pay enough attention to security.”

In the late 70s / early 80s there was a ton that the public didn't yet know about cryptography. Few, if any private citizens could have gotten security remotely right at that point. Remember, Diffie-Hellman was invented in 1976, and RSA in 1977, and PKI came some years after that, and DES was also from 1976/1977. As well the public's understanding of the need to do authenticated encryption came later, and the industry didn't really start catching on until the 90s, and AEAD cipher modes didn't really become a thing till the 00s, and didn't start to get used widely for another decade, and so on and on.

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

#109

Post by cryptonector »

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…

CNLP had variable-length addresses. I wonder what the world would look like with variable-length addresses.

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

#110

Post by wastedpotential »

somat wrote: post #89
hughesjj wrote: post #49

Earlier quoted context omitted.

Isn't it like literally a data structure issue though? Like you have to route on prefixes? Like how else would you know where to go? Ip routing is kind of like a tree (not a graph) in the ip regards, how would you get around it? I admittedly don't know as much as I'd like about network, hence why I'm posing this question ;-) If theres a way to efficiently model hierarchical domains for stuff like DNS/IP i'd love to k…

The way it is done is to have an invisible layer underneath (mpls perhaps) that can do the routing. However the correct ip way to do it would to have tcp(layer 4) decoupled from ip(layer 3) such that an ip address could change while maintaining the tcp stream. unfortunately this was not done, tcp has too many layer violations and is firmly interlocked with ip. I don't know much about the state of the art, does http o…

Yes. Packets contain a connection identifier, so the connection can continue were it left off when the client switches ip.
Post reply on HN