Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's Always TCP_NODELAY

brooker.co.za

Post reply on HN
Print view View original

51–60 of 186 posts

Re: It's Always TCP_NODELAY

#51

Post by AnthonyMouse »

anonymousiam wrote: post #41
gerdesj wrote: post #40

Earlier quoted context omitted.

I think you are confusing network layers and their functionality. "CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel." Ethernet really isn't ptp. You will have a switch at home (perhaps in your router) with more than two ports on it. At layer 1 or 2 how do you mediate your traffic, without CSMA? Take a single switch with n ports on it, wh…

It's P2P as far as the physical layer (L1) is concerned. Usually, full duplex requires two separate channels. The introduction of a hybrid on each end allows the use of the same channel at the same time. Some progress has been made in doing the same thing with radio links, but it's harder. Nagle's algorithm is somewhat intertwined with the backoff timer in the sense that it prevents transmitting a packet until some c…

> It's P2P as far as the physical layer (L1) is concerned.

Only in the sense that the L1 "peer" is the switch. As soon as the switch goes to forward the packet, if ports 2 and 3 are both sending to port 1 at 1Gbps and port 1 is a 1Gbps port, 2Gbps won't fit and something's got to give.

Re: It's Always TCP_NODELAY

#52

Post by neomantra »

0xbadcafebee wrote: post #27
hsn915 wrote: post #26

Wouldn't distributed systems benefit from using UDP instead of TCP?

Only if you're sending data you don't mind losing and getting out of order

This is true for simple UDP, but reliable transports are often built over UDP.

As with anything in computing, there are trade-offs between the approaches. One example is QUIC now widespread in browsers.

MoldUDP64 is used by various exchanges (that's NASDAQ's name, others do something close). It's a simple UDP protocol with sequence numbers; works great on quality networks with well-tuned receivers (or FPGAs). This is an old-school blog article about the earlier MoldUDP:

https://www.fragmentationneeded.net/2012/01/dispatches-from-...

Another is Aeron.io, which is a high-performance messaging system that includes a reliable unicast/multicast transport. There is so much cool stuff in this project and it is useful to study. I saw this deep-dive into the Aeron reliable multicast protocol live and it is quite good, albeit behind a sign-up.

https://aeron.io/other/handling-data-loss-with-aeron/

Re: It's Always TCP_NODELAY

#53

Post by paulsutter »

anonymousiam wrote: post #4

The Nagle algorithm was created back in the day of multi-point networking. Multiple hosts were all tied to the same communications (Ethernet) channel, so they would use CSMA ( https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_... ) to avoid collisions. CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel. (Each host can have any nu…

False. It really was just intended to coalesce packets.

I’ll be nice and not attack the feature. But making that the default is one of the biggest mistakes in the history of networking (second only to TCP’s boneheaded congestion control that was designed imagining 56kbit links)

Re: It's Always TCP_NODELAY

#54

Post by AnthonyMouse »

silisili wrote: post #32
immibis wrote: post #24

Earlier quoted context omitted.

Nagle is quite sensible when your application isn't taking any care to create sensibly-sized packets, and isn't so sensitive to latency. It avoids creating stupidly small packets unless your network is fast enough to handle them.

At this point, this is an application level problem and not something the kernel should be silently doing for you IMO. An option for legacy systems or known problematic hosts fine, but off by default and probably not a per SOCKOPT. Every modern language has buffers in their stdlib. Anyone writing character at a time to the wire lazily or unintentionally should fix their application.

The programs that need it are mostly the ones nobody is maintaining.

TCP_NODELAY can also make fingerprinting easier in various ways which is a reason to make it something you have to ask for.

Re: It's Always TCP_NODELAY

#55

Post by mikepurvis »

AnthonyMouse wrote: post #51
anonymousiam wrote: post #41

Earlier quoted context omitted.

It's P2P as far as the physical layer (L1) is concerned. Usually, full duplex requires two separate channels. The introduction of a hybrid on each end allows the use of the same channel at the same time. Some progress has been made in doing the same thing with radio links, but it's harder. Nagle's algorithm is somewhat intertwined with the backoff timer in the sense that it prevents transmitting a packet until some c…

> It's P2P as far as the physical layer (L1) is concerned. Only in the sense that the L1 "peer" is the switch. As soon as the switch goes to forward the packet, if ports 2 and 3 are both sending to port 1 at 1Gbps and port 1 is a 1Gbps port, 2Gbps won't fit and something's got to give.

Right but the switch has internal buffers and ability to queue those packets or apply backpressure. Resolving at that level is a very different matter from an electrical collision at L1.

Re: It's Always TCP_NODELAY

#56

Post by x2rj »

loeg wrote: post #44
x2rj wrote: post #20

I've always thought a problem with Nagel's algorithm is, that the socket API does not (really) have a function to flush the buffers and send everything out instantly, so you can use that after messages that require a timely answer. For stuff where no answer is required, Nagel's algorithm works very well for me, but many TCP channels are mixed use these days. They send messages that expect a fast answer and other that…

TCP_CORK?

Sadly linux only (and apparently some BSDs). Would love to have more (and more generalized) tcp socket modes like that.

Re: It's Always TCP_NODELAY

#57

Post by AnthonyMouse »

mikepurvis wrote: post #55
AnthonyMouse wrote: post #51

Earlier quoted context omitted.

> It's P2P as far as the physical layer (L1) is concerned. Only in the sense that the L1 "peer" is the switch. As soon as the switch goes to forward the packet, if ports 2 and 3 are both sending to port 1 at 1Gbps and port 1 is a 1Gbps port, 2Gbps won't fit and something's got to give.

Right but the switch has internal buffers and ability to queue those packets or apply backpressure. Resolving at that level is a very different matter from an electrical collision at L1.

Not as far as TCP is concerned it isn't. You sent the network a packet and it had to throw it away because something else sent packets at the same time. It doesn't care whether the reason was an electrical collision or not. A buffer is just a funny looking wire.

Re: It's Always TCP_NODELAY

#58

Post by fulafel »

anonymousiam wrote: post #4

The Nagle algorithm was created back in the day of multi-point networking. Multiple hosts were all tied to the same communications (Ethernet) channel, so they would use CSMA ( https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_... ) to avoid collisions. CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel. (Each host can have any nu…

Are you theorizing a CSMA related motivation or benefit in the Nagle algorithm or is this a tangential anecdote of those times?

Re: It's Always TCP_NODELAY

#59

Post by toast0 »

saltcured wrote: post #46
gerdesj wrote: post #40

Earlier quoted context omitted.

I think you are confusing network layers and their functionality. "CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel." Ethernet really isn't ptp. You will have a switch at home (perhaps in your router) with more than two ports on it. At layer 1 or 2 how do you mediate your traffic, without CSMA? Take a single switch with n ports on it, wh…

In modern ethernet, there is also flow-control via the PAUSE frame. This is not for collisions at the media level, but you might think of it as preventing collisions at the buffer level. It allows the receiver to inform the sender to slow down, rather than just dropping frames when its buffers are full.

At least in networks I've used, it's better for buffers to overflow than to use PAUSE.

Too many switches will get a PAUSE frame from port X and send it to all the ports that send packets destined for port X. Then those ports stop sending all traffic for a while.

About the only useful thing is if you can see PAUSE counters from your switch, you can tell a host is unhealthy from the switch whereas inbound packet overflows on the host might not be monitored... or whatever is making the host slow to handle packets might also delay monitoring.

Re: It's Always TCP_NODELAY

#60

Post by pests »

sleepy_keita wrote: post #25
dllthomas wrote: post #13

Wildly, the Polish word "nagle" (pronounced differently) means "suddenly" or "all at once", which is just astonishingly apropos for what I'm almost certain is pure coincidence.

Yeah, it's named after the person who wrote the RFC - John Nagle. Wild coincidence! https://datatracker.ietf.org/doc/html/rfc896

hes on hn as "Animats"
Post reply on HN