5 ms·

I wonder if he would have designed TCP/IP differently if he'd had the chance to have a second go of it. Maybe having multiple streams within a single connectio

by aooao 3mo ago

I wonder if he would have designed TCP/IP differently if he'd had the chance to have a second go of it. Maybe having multiple streams within a single connection, like QUIC does, would have been a better choice. Also being able to demarcate message boundaries within the protocol itself, perhaps, instead of it being a simple byte stream.

kristopolous 3mo ago
he's answered this question a few times. It's basically "how was I supposed to have any idea what the implications were?" He said something like "16 bit, 32 bit, 48 bit addressing, it felt all equally improbable. Why would there ever be 65,000 computers on this network?"
- johannes1234321 3mo ago
  > "... Why would there ever be 65,000 computers on this network?" This thinking can be seen in the allocation of network blocks. Mercedes Benz getting 53.0.0.0/8 is just a "we have more addresses than we ever need." If somebody had imagined "yeah, let's give an address to each of our vehicles" they would have realized the space running out.
fragmede 3mo ago
The computers of today are vastly more capable than the computers of the day when he came up with TCP/IP so if he were to have a second chance, knowing what he knows now, we'd have to calibrate it against the fact that computers in the 1970s simply weren't as capable as the beasts we have today.
greyface- 3mo ago
> if he'd had the chance to have a second go of it In a sense, he did. Take a look at RFC 4838.
Sesse__ 3mo ago
I was at a talk where he brought up exactly this (I also once did a talk alongside him, but that's a different story). He said there would be two changes: 1. It would have 128-bit addresses. 2. It would have end-to-end encryption (or was it authentication, I forget). IPv6 was supposed to fix both of these, with IPsec mandatory, but the latter demand sort of faded out into obscurity. We ended up basically solving encryption by pushing everything into TLS anyway, which I guess solved much of the same problems although at a very different layer.
- hyperman1 3mo ago
  Doing this brings you close to OSI, which famously failed by being overcomplicated. The current design was implementable by zillions of cheap humans running cheap hardware. I always wonder if the internet is thesurvivor of the networking cambrian explosion, with a slight roll of the dice making another candidate the winner.
  - cobbzilla 3mo ago
    You’re definitely right — the tech stack travels through time along what’s called a “path dependent” trajectory. https://en.wikipedia.org/wiki/Path_dependence https://en.wikipedia.org/wiki/Path_dependence
  - Sesse__ 3mo ago
    > The current design was implementable by zillions of cheap humans running cheap hardware. Yes and no. The current internet arguably does not work without a browser and a TLS stack anyway, neither of which is easily implementable (e.g. number of practically usable rendering engines is in the single digits). I mean, I can piece together an IP packet, too, but there's not that many usable services reachable that way.
    - pix128 3mo ago
      A bad application can still open unencrypted connections. Imagine a shoddily written game with a chat function.
  - dboreham 3mo ago
    As someone who was there at the time, OSI certainly didn't fail by being "overcomplicated". It failed because a) they charged money to read the standards documents and b) TCP/IP already had so much deployment momentum that nothing was going to supplant it (we see proof of this in the fact that IPv6 also didn't achieve that). Edit: also c) there was no requirement (unlike RFCs) to have an interoperable reference implementation available. So the implementations that were created mostly didn't interoperate.
alienchow 3mo ago
It would depend on whether the computers back then could handle that (along with all the crypto algorithms in their infancy) when A:\ and B:\ weren't even a thing.
- crackez 3mo ago
  Not like CP/CMS predates the Internet or anything... /s
justin66 3mo ago
There’s a whole body of work in the form of public statements and documents from Vint Cerf on that topic. You could explore Google for hours… https://spectrum.ieee.org/vint-cerf-mistakes https://spectrum.ieee.org/vint-cerf-mistakes

by aooao 3mo ago

kristopolous 3mo ago

he's answered this question a few times. It's basically "how was I supposed to have any idea what the implications were?" He said something like "16 bit, 32 bit, 48 bit addressing, it felt all equally improbable. Why would there ever be 65,000 computers on this network?"

johannes1234321 3mo ago
> "... Why would there ever be 65,000 computers on this network?" This thinking can be seen in the allocation of network blocks. Mercedes Benz getting 53.0.0.0/8 is just a "we have more addresses than we ever need." If somebody had imagined "yeah, let's give an address to each of our vehicles" they would have realized the space running out.

fragmede 3mo ago

The computers of today are vastly more capable than the computers of the day when he came up with TCP/IP so if he were to have a second chance, knowing what he knows now, we'd have to calibrate it against the fact that computers in the 1970s simply weren't as capable as the beasts we have today.

greyface- 3mo ago

> if he'd had the chance to have a second go of it In a sense, he did. Take a look at RFC 4838.

Sesse__ 3mo ago

I was at a talk where he brought up exactly this (I also once did a talk alongside him, but that's a different story). He said there would be two changes: 1. It would have 128-bit addresses. 2. It would have end-to-end encryption (or was it authentication, I forget). IPv6 was supposed to fix both of these, with IPsec mandatory, but the latter demand sort of faded out into obscurity. We ended up basically solving encryption by pushing everything into TLS anyway, which I guess solved much of the same problems although at a very different layer.

hyperman1 3mo ago
Doing this brings you close to OSI, which famously failed by being overcomplicated. The current design was implementable by zillions of cheap humans running cheap hardware. I always wonder if the internet is thesurvivor of the networking cambrian explosion, with a slight roll of the dice making another candidate the winner.
- cobbzilla 3mo ago
  You’re definitely right — the tech stack travels through time along what’s called a “path dependent” trajectory. https://en.wikipedia.org/wiki/Path_dependence https://en.wikipedia.org/wiki/Path_dependence
- Sesse__ 3mo ago
  > The current design was implementable by zillions of cheap humans running cheap hardware. Yes and no. The current internet arguably does not work without a browser and a TLS stack anyway, neither of which is easily implementable (e.g. number of practically usable rendering engines is in the single digits). I mean, I can piece together an IP packet, too, but there's not that many usable services reachable that way.
  - pix128 3mo ago
    A bad application can still open unencrypted connections. Imagine a shoddily written game with a chat function.
- dboreham 3mo ago
  As someone who was there at the time, OSI certainly didn't fail by being "overcomplicated". It failed because a) they charged money to read the standards documents and b) TCP/IP already had so much deployment momentum that nothing was going to supplant it (we see proof of this in the fact that IPv6 also didn't achieve that). Edit: also c) there was no requirement (unlike RFCs) to have an interoperable reference implementation available. So the implementations that were created mostly didn't interoperate.

alienchow 3mo ago

It would depend on whether the computers back then could handle that (along with all the crypto algorithms in their infancy) when A:\ and B:\ weren't even a thing.

crackez 3mo ago
Not like CP/CMS predates the Internet or anything... /s

justin66 3mo ago

There’s a whole body of work in the form of public statements and documents from Vint Cerf on that topic. You could explore Google for hours… https://spectrum.ieee.org/vint-cerf-mistakes https://spectrum.ieee.org/vint-cerf-mistakes