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

91–100 of 167 posts

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

#91

Post by throw0101b »

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…

> 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.

TCP and IP used to be one thing, and they split off TCP in what we now call Layer 4 (where UDP, and others, also exist). So they did think ahead in separating things to a certain extent.

The fact that we have a whole bunch of middle-boxes that don't allow DCCP, SCTP, etc, is hardly the fault of Cerf et al.

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

#92

Post by pclmulqdq »

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…

It sounds fine from a theoretical standpoint to use a pure byte stream rather than reliable messaging, which is what most applications actually want. However, messaging protocols can run byte streams at 0 overhead (you still need a message sequence number/tag, and this field turns into the same thing as the TCP seq num for a byte stream), while byte streams need some overhead to turn into messaging protocols, since there is otherwise no protocol-level delimiter between messages.

This seems like nearly nothing, but when you think about the lost compute power and network bandwidth throughout the history of TCP to this distinction, it's actually a very significant chunk of power, CO2, and wasted human life. Not to mention the lost human life that comes from HOL blocking.

The byte stream abstraction idea, I think, was a suspect decision at the time (born out of a desire to look exactly like a serial teletype port despite the fact that it's the wrong abstraction layer to use for that), and clearly wrong for a transport layer today. Almost everything built on top of TCP re-introduces messaging semantics.

Also, IP never had a message checksum, only a header checksum. The checksumming is at the TCP layer and it is still alive.

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

#93

Post by convolvatron »

elihu wrote: post #21
m348e912 wrote: post #3

Earlier quoted context omitted.

For the time 32bit was more than adequate, not to mention routers only had so much memory and processing power.

Funny enough, one of the arguments for longer key lengths now is to save memory. With IPV4 the way it is now, the address space is very fragmented so you need a lot of router table entries. More available address space means more contiguous address blocks and therefore fewer router table entries. That wasn't an issue back when IPv4 was being defined though.

The issue here isn’t the size of the address, but the way it’s allocated and managed. Since the provider block routing scheme was carried forward while cloth - realistically the most were going to get is a deprecation of the really tiny blocks - ‘the swamp’.

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

#94

Post by zymhan »

imtringued wrote: post #74
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…

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. arbitrar…

> WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection

It doesn't seem like you've actually moved away from using TCP.

Maybe it's just too low of a layer for your needs?

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

#95

Post by jerf »

imtringued wrote: post #74
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…

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. arbitrar…

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

In the context of 2023, this is a defensible position. I can quibble, but it's defensible.

However, are you sure you want a 1974 take on a "message based protocol"? Trust me, you're not getting SCTP out of that, in a world where having two streams instead of just one is a noticeable resource impact. Heck, even by the 1990s there were still a lot of really bad things coming out of the world of "message based protocols".

You wouldn't be here in 2023 with a message-based TCP. You'd be here in 2023 with some other protocol having become the foundation of the Internet, and it wouldn't be "message based" either. There's no option where someone in 1974 is building with the nearly 50 years of experience that haven't happened yet, and I'm not going to grade TCP on that basis personally.

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

#96

Post by tptacek »

bawolff wrote: post #12

> Before public-key cryptography came around, key distribution was a really messy manual process,” Cerf says. “It was awful, and it didn’t scale. So that’s why I didn’t try to push that into the Internet. I dont really think this is a mistake. Its not like there are great options even now for end2end security on the transport layer (like we have vpns but they mostly require having preshared secrets). It would have be…

Look at the first round of IPSEC work --- a decade and a half or so later, in the late 1990s --- to see what a disaster native cryptography would have been for IPv4.

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

#97

Post by tptacek »

1letterunixname wrote: post #85

I don't see all of the criticisms for security, but there are some fair points. 0. Gating mechanisms should live at lower and higher levels in the stack. We have 801.1x for wifi/port security and TLS between client and server. 1. DHCPv4 (and conflation with BOOTP) is messy and doesn't have a trust model. There ought to be a mechanism to validate that the DHCP server authentic, its data is valid, and it's supposed to…

Or, DNS doesn't need any security model at all, because the rest of the stack is designed to assume it's not secure, which is a model that has worked for the last 30 years.

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

#98

Post by cesarb »

amoss wrote: post #64
XorNot wrote: post #36

Earlier quoted context omitted.

No, it wouldn't have been. Where are you going to put that extra byte? How is an intermediate box going to know what to do with it? How is a routing ASIC going to handle it? This is thinking which appeals to people who don't understand the problem because it feels like a compromise, but you can't negotiate with silicon . If it expects a 4 byte address payload, then that's all it will ever handle. Adding more bytes is…

Nah, hardware people just don't negotiate hard enough. Add a one-byte option into the header, give it an unassigned value (e.g. 6) and assume that any box that does not understand it will pass it through unchanged. Use it as the most significant byte of the address, and obsolete all routing equipment that doesn't understand it from the backbone so that they can be used to handle routing in one of the new 32-bit super…

> Add a one-byte option into the header, give it an unassigned value (e.g. 6) and assume that any box that does not understand it will pass it through unchanged.

As many have found out, unfortunately "any box that does not understand it will pass it through unchanged" is frequently false. What often happens is that a box which does not understand it silently drops the whole packet, under the mistaken impression that it's an attempt to invade the network.

> Use it as the most significant byte of the address, and obsolete all routing equipment that doesn't understand it from the backbone

You'd have to not only obsolete all routing equipment, but also all end hosts. Consider what happens when host A, which does not understand the option, receives a packet from host B, which has an address which requires the option; the reply packets from host A will never reach host B, since host A doesn't know it has to add the option.

These "just add another byte" solutions are often proposed in these discussions, and look deceptively simple at a first glance, but fall apart once you start looking at it in detail.

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

#99

Post by couchand »

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

need?

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

#100

Post by manv1 »

1974 was a long time ago. 32 bits was a big number. The 8080 had 8 bit words and ran at 2Mhz.

For people today, it's hard to understand how expensive everything was back then. 1K of RAM in 1974 cost about $307 dollars. Yeah, you're not going to be putting that into your router. So those extra bits have a super-high hard dollar cost.

We're lucky he didn't go to 16 bits.

Post reply on HN