101–110 of 227 posts
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.
A genuine innovator No matter what you think of Google
I may be biased since I interned at Google in 2013 and 2014, but Google in the 2000s and early 2010s felt downright magical as someone who wanted to pursue a career in systems software research. They made impressive technologies that still hold up today, like MapReduce, BigTable, and Spanner. They hired many legends of computer science and software engineering, such as Rob Pike and Jeff Dean. I’m concerned about the…
I interacted with many professors in OS research and other adjacent systems fields when touring grad schools and I heard or saw that some were extremely toxic or intense compared to other fields I saw. With OS at least, big tech companies seem to hold a lot of influence over research directions (eg. so much of it is specifically for AI datacenters, or for one company's AI datacenter problems), and I asked OS professors about this and got disheartened replies that there was nothing they could do because of the incentives in the field. I was quite disillusioned. I know that AI being a hot new topic makes leaves more stones unturned and might lead to more publishability, but it's still depressing.
Earlier quoted context omitted.
Please don’t post snarky or low-substance comments on HN. As another commenter has pointed out, Vint Cerf himself credits Gore as playing a significant role in enabling the Internet’s emergence. He didn’t claim to have “invented” it.
[flagged]
There's always some nincompoop who brings that up. Al Gore deserves credit for what he did as a senator and vice president. He helped to pass legislation that enabled the NSFNET backbone to grow and to permit commercial traffic to flow on the government-sponsored backbones in the US. Had he not done that, it's pretty likely that the commercial sector would not have seen an opportunity to create a commercial internet that all of us can enjoy, so he does deserve some credit for what he's done.
— Vint Cerf, Tracking the Internet into the 21st Century https://www.youtube.com/watch?v=Hf0rjtnwC9A>
Anyone know what he actually did at Google? Was it an active role, did he publish anything interesting? Or was it more of an Institute for Advanced Study kind of position?
Similar ish to an influencer
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.
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?"
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.
Anyone know what he actually did at Google? Was it an active role, did he publish anything interesting? Or was it more of an Institute for Advanced Study kind of position?
Earlier quoted context omitted.
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.
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 imple…
Or there is too much inertia for IPv8 to overcome to become a truly backwards compatible extension / superset of IPv4?
Part of the reasons for the slow adoption of IPv6 was that it was never designed to be backwards compatible unlike IPv8.
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.
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 encr…
The "solving" of encryption with TLS should not be celebrated.
Everything needs to go over TLS/HTTP-443 because of middleware boxes basically blocking everything else by default in many cases, and so application/protocol designs have to shoehorn / kludge everything into a round hole even if it's a square peg.
Certainly I'd want everything to have encryption at the higher layers (OSI 5-7), but having opportunistic encryption at IP (OSI 3) would also be great because snoopers could tell that two nodes are communicating but not how / what: RTSP? Torrent? Mindcraft? PvP2 game? If every node could (say) do an IKEv2 negotiation with every other node have IP-level traffic wrapped in IPsec that would help with traffic analysis.
I still remember back in 2005 when I just joined a company, a coworker was quipping Google is not a real elite company, because it doesn't even have a Turing Award winner. I showed him the news that Vint Cerf joined Google recently.
Now they have several Turing Award winners, and several Nobel Prize winners.
Earlier quoted context omitted.
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 imple…
In your opinion, do you think Internet Protocol Version 8 (IPv8) [1] stands a chance to fix the mistakes of IPv6 after more than 20 years now? Or there is too much inertia for IPv8 to overcome to become a truly backwards compatible extension / superset of IPv4? Part of the reasons for the slow adoption of IPv6 was that it was never designed to be backwards compatible unlike IPv8. 1: https://www.ietf.org/archive/id/dr…
IPv8 solves precisely zero of the problems that is causing a 'slow' roll out of IPv6 / replacement of IPv4:
"""
So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:
You have to change the version number.
You have to add new code to handle the new version.
Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So,
You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions:
(3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses between the old and new protocols.
[…]
Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The related "IPv4-Mapped IPv6 address" format is still valid and has a role in the POSIX socket API. Mappings of this kind also figured in the moderately successful coexistence technologies known as 6to4 [RFC3056, RFC3068] and Teredo [RFC4380], which have now been overtaken by events.
"""
* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...
* Interview with author of article: https://www.youtube.com/watch?v=W3jkZ1Ulz-s