Live data from Hacker News

Falsehoods programmers believe about TCP

lwn.net

11–20 of 247 posts

Re: Falsehoods programmers believe about TCP

#11
post #2

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

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.

Re: Falsehoods programmers believe about TCP

#12
It really is astounding to me how so many still do not understand that tcp is not a function call, or behaviors like slow start and congestion avoidance.

Recently a new rate limiter for TCP went by that was so terribly, terribly broken, and I cannot help but imagine that most of the containers of the world suffer from Bufferbloat in general.

Re: Falsehoods programmers believe about TCP

#13
post #12

It really is astounding to me how so many still do not understand that tcp is not a function call, or behaviors like slow start and congestion avoidance. Recently a new rate limiter for TCP went by that was so terribly, terribly broken, and I cannot help but imagine that most of the containers of the world suffer from Bufferbloat in general.

The rate limiter in question: https://github.com/cilium/cilium/issues/29083

Re: Falsehoods programmers believe about TCP

#15
post #10
post #2

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

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.

Re: Falsehoods programmers believe about TCP

#16
post #10
post #2

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

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

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.

Re: Falsehoods programmers believe about TCP

#17
post #9

I recall it blew my fiancée’s mind that I could unplug her ethernet cable, move it around an obstacle, plug it back in and all her connections were still alive. It’s designed to have bombs dropped on it.

What happens in that case? I'm going to speculate:

1. Remote keeps sending stuff to your unplugged connection

2. You plug your ethernet cable back in

3. Your computer's TCP acknowledges the last sequence number it received for each new sequence it receives from remote

4. Remote sees duplicate ACKs for same sequence number, interprets it as packet loss and resends the stuff

Re: Falsehoods programmers believe about TCP

#18
post #9

I recall it blew my fiancée’s mind that I could unplug her ethernet cable, move it around an obstacle, plug it back in and all her connections were still alive. It’s designed to have bombs dropped on it.

Depends on OS settings these days. Lots of OSes want to help and detect link down and reset all your connections. Kind of a pain when you just want to move a cable.

Re: Falsehoods programmers believe about TCP

#19
post #10
post #2

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

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

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.

Re: Falsehoods programmers believe about TCP

#20
post #9

I recall it blew my fiancée’s mind that I could unplug her ethernet cable, move it around an obstacle, plug it back in and all her connections were still alive. It’s designed to have bombs dropped on it.

What happens in that case? I'm going to speculate: 1. Remote keeps sending stuff to your unplugged connection 2. You plug your ethernet cable back in 3. Your computer's TCP acknowledges the last sequence number it received for each new sequence it receives from remote 4. Remote sees duplicate ACKs for same sequence number, interprets it as packet loss and resends the stuff

[deleted]
Post reply on HN