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

111–120 of 167 posts

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

#111

Post by cryptonector »

cyberax wrote: post #50
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 copie…

Explicit congestion control notification could also have been done this way.

Retrofitting features like this into the middleboxen takes decades, and never finishes, so you either get them in on day zero or you never get them.

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

#112

Post by WorldMaker »

garbagecoder wrote: post #76
kortilla wrote: post #43

Earlier quoted context omitted.

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

A lot of the trade-offs that people like to complain about IPv6 were specifically made to "rip the (backwards compatibility hack) band-aid off" and help make sure that we won't be pining for "whatever comes next" anytime soon.

IPv6 could have been a lot more pragmatically backwards compatible, absolutely. It would have been much more doomed as a temporary solution in that case. The IPv6 we got was designed to be a more permanent solution, which makes it feel much less pragmatic. That's somewhat how trade-offs work.

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

#113

Post by gizmo686 »

pmarreck wrote: post #101
ajross wrote: post #90

Earlier quoted context omitted.

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…

The first 4 bits of both IPv4 and IPv6 packets are a version field.

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

#114

Post by agumonkey »

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.

Maybe there should be a margin factor, just like in architecture. Build it for 5x the load, then 10x that.

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

#115

Post by agumonkey »

hn_throawlles wrote: post #88
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…

> even the defense department doesn't need 4.3 billion of anything uhm. counterexample: they need more dollars than that

it's hard to make a bill communicate over copper wire though

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

#116

Post by FullyFunctional »

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…

"Having these addresses where we wouldn't even touch half of the bits for decades would have been unpopular with a lot of people, even if he would have been praised for being so forward thinking in the end."

Worse perhaps, people, algorithms, hardware, ... will all start to assume those bits are zero and start optimizing for that. We have seen this happen repeatedly throughout history (eg. Lisp pointers would stuff tags in the "spare" bits in addresses, making implementations non-portable).

These are all hard problems, but the lesson I take away is to

1. Always have a plan for evolving the design/protocol/API/...

2. Aim for a watertight design that supports 1. (Example: TLS 1.3 puts random stuff into reserved fields so nobody can assume they are zero).

3. Really stretch your imagination about future usages (assume 50+ years)

4. Have a ridiculously comprehensive test suite for both clients and servers

It seems clear that in terms of lifetimes, hardware gets used much longer than expected, software even more so (Y2K anyone), but protocols/formats/specs/... literally never dies

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

#117

Post by JohnFen »

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.

My answer to that is that there's no way to know in advance if 64 (or any other #) of bit is enough or not. Tech history is full of examples of arbitrary limits being defined thinking that there's no possible way anyone would need to exceed them, only to find that everyone needs to exceed them later on.

Is 64 bits enough? Maybe. Maybe not. But if you're wanting to future-proof, then setting an arbitrary limit is not the way to go.

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

#118

Post by em3rgent0rdr »

agumonkey wrote: post #114
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.

Maybe there should be a margin factor, just like in architecture. Build it for 5x the load, then 10x that.

Well ARPA already had a margin factror...they had about 256 computers that needed addresses, and left space for 2^24 times 256, or 4,294,967,296 computers.

The growth ended up to be exponential over time. So maybe a better margin would be expressed exponentially along the lines of "build it for 2^(doubling_constant * number_of_years) the load."

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

#120

Post by ikiris »

amoss wrote: post #31
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.

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

If there existed a magic wand to make longer addresses work with existing stuff sure, but since there didn't, you have all the exact same problems as ipv6 which is already basically the same thing as ipv4 anyway with 128 bit addressing, and some minor tweaks to how the "arp" works.

If you can articulate how this magic wand would work in practice we're all ears since you solved a worldwide problem, but I'm betting my salary that you can't.

Post reply on HN