Hacker News Reader

Comment by saghm | Hacker News Reader

> remember, all of the following statements are false at least some of the time, but for some of these, perhaps not very often

> 5. There is a such thing as a TCP packet

> 6. There is no such thing as a TCP packet

I don't understand this at all. Either the concept of a TCP packet exists, or the concept does not exist. Even it's not being used in certain scenarios, I don't see how you can argue that "there's no such thing" any of the time. This might just be me misunderstanding whatever point they're trying to make, but I don't remember ever having such philosophical confusion from anything in any other "falsehoods programmers believe about..." article before.

View on HN

Pedantically: TCP has segments, IP has packets, and Ethernet has frames. They are one-to-one in simple cases, but not always.

https://networkengineering.stackexchange.com/questions/50083...

In particular, fragmentation by intermediate routers means that the server and receiver may disagree about the frame and packet boundaries. TCP is expected to make a "reliable" pipe-like service out of whatever happens, and the application layer doesn't have (shouldn't need?) visibility into that process.

Falsehoods programmers believe: TCP/IP can be coherently mapped to the OSI model.

Falsehoods programmers believe: the OSI model

Yep. https://dotat.at/@/2024-03-26-iso-osi-usw.html

Falsehoods programmers believe: the OSI model is useless

It's useful. It's not controlling.

Sure, it's misleading, needs a lot of "interpretation" doing a non-trivial amount of the lifting to make it map to anything in the real world, mismatches things that happen in the real world while leaving no room for other things that happen in the real world a lot, and will lead anyone who tries to use it to understand the real world deeply astray, but it isn't always wrong about absolutely everything so it has some non-zero "utility".

Fine. It's not wrong about absolutely everything all the time. It isn't bereft of all truth. It's just something that is of net negative value. I see no value in insisting on trying to "rescue" a net-negative value model of the world.

I suppose you could say ultimately I agree with you though. The OSI model isn't useless. It's worse than useless. You're better off trying to understand networking from basic first principles than through the lens it provides.

Analogies are rarely perfect, that's why they are analogies. The OSI model isn't intended to be perfect and yeah there are a lot of details that leak between layers, but is also expected, any non-trivial abstraction is always going to be leaky. That doesn't mean it useless or absent of value in discussion at appropriate levels.

It's not useless, just bad at it's job.

I mean in practice it's so broken, imprecise and messy to a point it's often more misleading then helpful and IMHO should have been replaced in teaching with something better well over a decade ago.

And to be clear I'm not saying it's bad because some small implementation details don't fit, it's bad in it's job of being a high level abstraction where you ignore many implementation details.

I think I've heard the term "packet" used to refer to the general category of thing that Ethernet frames, IP packets, and TCP segments are all examples of.

Colloquially, yes, they're all just packets unless I'm writing an RFC for the IETF.

If I recall correctly, the formal term for the all-encompassing category is the "datagram".

It's like who-vs-whom. Prescriptivists will try to tilt that windmill forever, descriptivists observe that most people just don't care.

Those are all packets.

This one feels like the list-maker is struggling to communicate with me rather than telling me a surprising truth. I can't tell whether it's meant to mean "a TCP segment won't always fit 1:1 into an IP packet (but in the real world they mostly do)", "TCP has segments instead of packets (but everyone knows what you mean when you say TCP packet)", or something else entirely.

Yeah, that's basically the takeaway I had (and I failed to summarize as concisely, ironically enough). It seemed like there was some insight there, but I had absolutely no clue what it was.

What it really means is: Packets have well-defined boundaries between sufficiently-adjacent nodes. They are not guaranteed to keep those boundaries end-to-end over arbitrary middleware.

I guess it’s talking about how the TCP data stream is segmented into IP packets. From the IP point of view, there are packets; from the application point of view there is a data stream; but it’s more complicated than that. Applications have some control over when TCP’s PSH flag is set, roughly speaking, at the end of each write(); and that in turn affects segmentation because small pushed writes cause small packets. But if the sender can’t send straight away then buffered data doesn’t preserve write() boundaries and will be sent with large packets.

I think we're talking about different things.

TCP is a protocol that most certainly has packets ("segments").

You are taking about a SOCK_STREAM-like programming interface, which can be used to create TCP connections.

If what was originally a packet is fragged, the TCP headers may (likely) not be in all the frags. So if you're looking with wireshark and you think you can filter with TCP flags good for you, 90% of the world feels that way.

I work with DNS a lot and when a protocol which is datagram-oriented is translated to a stream-oriented medium and somebody wants to potentially handle multiple requests in that stream because "efficiency"... it's so important... they need a way to distinguish those embedded datagrams: "we should do it they way they did in HTTP, with a Content-Length: header, yea THAT's the ticket!" I'm sure that's what they were thinking.

Then along come the 90% and when they try to process DNS requests in TCP streams it's "what's this two bytes in front of the request? I dunno, but I just skip over it" and I suppose it works well enough, because with frags they'll drop the tail of the requests because "corruption" anyways, and who on earth sends multiple requests in a single packet, amiright?

You may think I'm kidding, but here's some really clever (really!) eBPF code: https://gist.github.com/oghie/b4e3accf1f87afcb939f884723e2b4...

If you want more on this topic: http://consulting.m3047.net/dubai-letters/dnstap-vs-pcap.htm...

> 6. There is no such thing as a TCP packet

Because the software abstraction is a stream of bytes; and it's up to the application to decide where the "packets" begin and end.

For example, I might write to a TCP socket: 100 bytes, 50 bytes, and then 125 bytes.

BUT, the receiver could get: A single event with 275 bytes. Or it could get an event with 75 bytes and then an event with 200 bytes. Or it could get 11 events of 25 bytes.

> 5. There is a such thing as a TCP packet

This one I struggle with. I think the author is talking about connection set up, acking, and connection teardown.

If you have a look at the underlying network traffic, you'll see IP packets carrying TCP data, ie. The protocol field in the IP packet header will be set to TCP; this could be assimilated to a TCP packet.

Well, maybe...

It's a typical problem of this lists they don't always point to the underlying issue they want to list.

5.,6. are likely about how all kinds of things infer with your packages mainly merging/splitting but also potentially messing with them in other ways (and in general the package->frame mapping). So if you want to build anything which relies on TCP packages being a thing it likely will not work, at the same time you can't always ignore package size either (e.g. for flushing byte streams, higher level protocol chunking etc.). Through as long as you don't create transport protocols write a network stack or fine tune your TCP stack or similar you likely don't have to care about it. I mean you also probably shouldn't use TCP directly but something more high level in most situations (e.g. HTTP, gRPC, etc.).

5 and 6 are mutually exclusive. They don't make sense logically. And most of the list was never explained at all.

> They don't make sense logically

In practice such situations can arise in one of two cases:

1. some non-sense creeped in

2. logic is applied to a self-contradictory set of axioms and definitions.

(1) is not very interesting, but (2) happens frequently enough because people often do not try to formalize their definitions and axioms. As a consequence they are using some vague concepts and their statements are true in some cases but not in others.

With all that said, I can propose the way how this logical non-sense could be right. (NB. I don't know if it applies to TCP, I'm just thinking generally, and just as an example to all that abstract words above) The notion of "existence" of the mistaken programmer can be wrong. If we accept their definition of existence, then TCP packets doesn't exist, but they exist in some other sense.

Yes. If one applies correctly the rules of logic on inconsistent axioms, the conclusions will be inconsistent. If one incorrectly applies logic to inconsistent axioms, the conclusions may or may not be consistent. It happens IRL sometimes; "being right for the wrong reasons". That being said, I suspect the game of the author is to play with leaky abstractions. TCP is a stream-oriented protocol, but is implemented on top of frames etc.

The point is that a lot of stuff in Networking (and Computer Engineering in general) is very context dependent, and that you cannot be extremely opinionated about this stuff.

No context was ever provided.

They are not mutually exclusive statements, because they don't exist in isolation: they are both potentially true and false depending on the context of discussion.

But they assert whether or not something exists, as an absolute statement. Maybe TCP packets don't exist in a particular situation, but there is still such a thing as a TCP packet in that case.

This seems like it's either a linguistic or philosophical question; either I don't interpret the words "such a thing" in a way that the author meant it, or I have a divergent different philosophical worldview on the concept of "existence" from the author's own view.

Either way, this stuck out to me because usually these type of lists have very simple, understandable statements that just happen to surprise some people by not being true; in this case, the statements themselves are confusing, so I can't really say for certain whether I believe them or not because I don't even know what truth they're asserting to try to negate it.

> these type of lists have very simple, understandable statements

I would classify these statements as koans, and further observe that one of the defining characteristics of these lists is that they are wry. With that in mind the couplet is evidently presented in cheek to illustrate the need for context, since this is the pathway to resolve the overt contradiction without getting stuck in a rigid thinking trap.

Yeah, I agree with you here.

I think the thing most related to that that I see people thinking is that send(2) & recv(2) calls translate 1:1 with packets send/recv. I.e., that they don't understand that the interface TCP exposes to applications is a byte stream. Which then results in things like thinking recv(2) will receive a complete "message" for some definition of message in the application protocol (i.e., the mistake belief that fragmentation won't happen).

If I had to guess, it would be an assumption that TCP was edge to edge with no translation in the middle.

My guess is that this is talking about systems in the middle of the network, changing (for example) their sizes by combining and splitting packets to fit through various transits.

It's about your abstraction level and the kinds of problem you are ignoring. It's true at the same time that you can't ignore the problems of stream communication nor the problems of package-based communication.

Perhaps it could be rescued by rephrasing them as "is always" versus "is never"?

This doesn't really change my reading of those statements; the issue to me is that "there is such a thing as X" sounds to me like an existential proposition, i.e. "X exists". The idea that an abstract descriptive concept only sometimes exists doesn't really make sense to me; it sounds like saying that addition only "sometimes" exists because there are equations that only use division and not addition.

It exists but more as a TCP stream, which is broadcast as packets...

Unicast. Unless we are talking about wifi... Which gets to very similar context based mess.

My only guess how this could make sense is if there is some ambiguity in the definition of a TCP packet.

It sounds like TCP is totally fucked and useless. It needs to be depreciated immediately and replaced with something better and more intuitive from a programming perspective. Maybe someone at Apple or Google is working on it lol.

Reply on news.ycombinator.com