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

71–80 of 167 posts

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

#71

Post by XorNot »

amoss wrote: post #69
XorNot wrote: post #66

Earlier quoted context omitted.

"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?

How much cost in labor, disruption and time do you think upgrading every backbone router would be?

When would you have done it? When the hardware was 5 years old? 10 years old? I've been on change operations where the hardware was over a decade old and our biggest concern was making sure we had replacement PSUs on hand since the thermal shock of a reboot might take them out.

This is the problem, you have absolutely no idea what anything costs or how it works - you're simply thinking "lifting those bits sounds heavy, what if we made them lighter?" as though a committee of engineers, designers and industry didn't spend a lot of time considering exactly that problem.

If you could add 1 byte in software and be done with it, it would have already happened.

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

#72

Post by amoss »

XorNot wrote: post #71
amoss wrote: post #69

Earlier quoted context omitted.

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?

How much cost in labor, disruption and time do you think upgrading every backbone router would be? When would you have done it? When the hardware was 5 years old? 10 years old? I've been on change operations where the hardware was over a decade old and our biggest concern was making sure we had replacement PSUs on hand since the thermal shock of a reboot might take them out. This is the problem, you have absolutely n…

Upgrading hardware is an ongoing process. You are proposing a single point of change without any reason for it to be handled that way.

You are arguing that all change has the same cost. I don't see your reasoning for this. A smaller change to a system has a lower cost in R&D, and a lower cost in manufacture.

Although it is probably true that the cost of updating all equipment dominates the cost of redesign, this is only an issue for a big bang update rather than a rolling upgrade.

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

#73

Post by foobarian »

klabb3 wrote: post #48
jandrese wrote: post #42

Earlier quoted context omitted.

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.

Didn't they build that weird "emergency packet" feature to skip to the head of line? IIRC it was never well supported in various system stacks..

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

#74

Post by imtringued »

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…

No they made the wrong decision and SCTP and QUIC fixed almost everything wrong with TCP.

I personally stopped using raw TCP because it is almost always the wrong solution. If I need a bare bones protocol where I want to send raw bytes I now always use websockets because they work exactly as they should.

Streaming is such a niche usecase that is only natural if you don't semantically interpret the data, i.e. arbitrary file transfers but the vast majority of the complexity isn't there.

> 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

No, in my experience, you will spend most of your time working around TCP warts.

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

#75

Post by 2devnull »

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.

Knowing this and being the person (or part of the team) to first implement a thing is the true thrill of programming. You, sometimes exclusively you, understand the weight and permanence of the minor decisions you make. This is why non-programmers often find programmers hard to understand, overly picky about minor details, strangely emotional about things they have a hard time verbalizing and so on.

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

#76

Post by garbagecoder »

kortilla wrote: post #43
jandrese wrote: post #32

Earlier quoted context omitted.

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 peop…

Just about every thread on HN has a debate between the optimal and why can't people just get it and the practical and why they can't get it to be optimal.

If you can't implement it easy enough for it to be optimal once in place, it's not optimal. Whatever the advantages of ipv6 are, it wasn't enough to suck everyone in. You have to consider your environment. And re-training sysadmins is part of it and just telling them "lol it's easy" isn't going to do much to get them there.

By the time we get fully switched over, I wonder if we won't be pining for whatever comes next.

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

#78

Post by imtringued »

jandrese wrote: post #33
kragen wrote: post #8

Earlier quoted context omitted.

the ipv4+tcpv4 header is minimally 320 bits long so i don't think so

Routers don't care about the TCP header though, they only care about the 20 bytes of IP header. The interfaces on the router also care about the 14 byte MAC header, but that's a separate step. That said I agree that the world likely would have sucked it up and just gone with the 64 bit addresses, but there would have been a whole lot of grumbling for decades about the memory use. It's hard to imagine these days, but…

We live in a NAT and CGNAT world. Routers do care about the TCP header.

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

#79

Post by chrisfosterelli »

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…

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.

Post reply on HN