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

41–50 of 167 posts

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

#41

Post by jayd16 »

zubnix wrote: post #37
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…

Http 3.0 is UDP, ICA these days is also UDP.

Yes, but by necessity and only after http/2 attempted everything listed over TCP.

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

#42

Post by jandrese »

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 quite a challenge to implement back in the 90s, with many many buggy stacks out on the Internet.

By being just a stream of bytes you are free to do whatever you want with the protocol. Sure that may mean implementing your own form of blocking but that's better than being stuck in a protocol where you are forced to work around the message oriented features even though you are just streaming data.

The checksum does hail from an earlier era where 16 bit machines were commonplace and the total amount of data sent is minimal. Also, there is some assumption that the underlying transport is going to have its own checksums. You will note that IPv6 ditches the checksum entirely.

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

#43

Post by kortilla »

jandrese wrote: post #32
oh_sigh wrote: post #13

Earlier quoted context omitted.

Things also could have been a lot different if IPv6 was just IPv4 with 128 bit addresses.

I see this sentiment from time to time, but it doesn't make sense to me. Any way you do it you need to deploy new hardware, new firewall rules, new end user applications, etc... What parts of IPv6 are harder now than they would be with just a fat IPv4? Is it really so complicated now that you can't fragment packets on path? Is Neighbor Discovery Protocol really so much more difficult to understand than Address Resolu…

Administrators memorized IPs a lot. This is hard to under estimate and is frequently the disconnect I see when a SWE doesn’t understand why people could possibly complain about ipv6.

This is likely the #1 issue I hear from people in the field.

#2, for better or worse, NAT became peoples’ comfort blanket. It’s a boneheaded stateful firewall regardless of how long people can scream “NAT isn’t security”. By forcing people to take both changes at the same time, adoption was setup for failure. So many places in the US turned it off “because nothing I use is v6 only” and they weren’t quite sure if they were exposing their end hosts accidentally.

#3, link local addresses, guids, etc all assigned at the same time is a steep learning curve. Which will be used for which flows in the network? If my ISP changes my prefixes, do I know have to reconfigure all of my local network firewalls?

#4, prefix delegation, should each client behind my router get its own /64? My ISP only gives me 128 of them to hand out which is a problem for IOT. Guidance here is weak.

Burning all of the early adopters with the slaac vs dhcpv6 vs privacy extensions didn’t help either.

Nobody gives a shit about fragmentation. The upgrade UX was a disaster.

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

#44

Post by hughesjj »

helsinkiandrew wrote: post #39

> “I thought 32 bits ought to be enough for Internet addresses”. “I didn’t pay enough attention to security”. “I didn’t really appreciate the implications of the World Wide Web.” Most experiments, prototypes, and even full blown systems designed for the long term die well before 30-40 years and those extra addresses and features would ever be needed. Much more human effort is wasted prematurely 'future proofing' syst…

So many network admins still prefer to configure smaller networks with IPv4 instead of ipv6 due to simplicity, then just nat peer it out

Hell even AWS didn't start seriously supporting it until the mid 2010s... And heck I don't know if they support ipv6 across the board or not

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

#45

Post by klabb3 »

zubnix wrote: post #37
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…

Http 3.0 is UDP, ICA these days is also UDP.

Technically true, but parent’s point still stands (even if it should have said “on top of IP”).

Byte streams are not ideal to deal with for protocols. As soon as you have encryption, like tls, you have discrete messages anyway (records) and the stream is largely an illusion.

That said, I still like TCP as a compromise between simplicity and versatility. It’s been holding up incredibly well for a huge variety of use cases.

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

#47

Post by ly3xqhl8g9 »

bushbaba wrote: post #11
ksec wrote: post #2

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

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 `cherry.picked.15.1`.

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

#48

Post by klabb3 »

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…

> By being just a stream of bytes you are free to do whatever you want with the protocol.

Not entirely. Head-of-line blocking is an inherent problem with TCP so you can’t have real priority “streams” like you can with eg QUIC. Another “missing feature” is datagrams, ie simply opting out of the retransmission part of tcp.

That said, I still agree with the general statement.

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

#49

Post by hughesjj »

astrange wrote: post #27
merlyn wrote: post #16

Earlier quoted context omitted.

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.

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 know. Like, consistent hash rings maybe, but then we'd be reintroducing ring topologies...

Oh wait duh though. A cell tower is owned by a single company. Yeah that's prolly doable, the company can always buy beefier routers if they need the memory. And realistically speaking the virtual tree could be closely aligned to the physical one given how cell towers work.

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

#50

Post by cyberax »

captainkrtek wrote: post #20

#4: IP Fragmentation

To be precise, MTU.

The MTU should have been reified to the IP layer. And it would have been so easy!

When a system sends a packet, it sets the "forward MTU" field in the IP packet to be equal to the MTU of the outgoing link. Each router along the way inspects the packet and if its outgoing link has a lower MTU, it replaces the "forward MTU" with its own.

Once the packet reaches the destination, the target host copies the "forward MTU" field (which now has the lowest MTU seen along the path) to the "reflected MTU" and sets it on the next reply packet.

So the originating system can discover the limiting MTU by the time it gets the ACK packet.

Sigh. Instead, we have a Ruby Goldberg machine with fragmentation, ICMP and all the related unreliable crap that has forever cemented max MTU as 1500.

Post reply on HN