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

81–90 of 186 posts

Re: It's Always TCP_NODELAY

#81

Post by skrebbel »

Nagle himself says (or said 10y ago) that the real culprit is delayed ACK: https://news.ycombinator.com/item?id=10608356

I’m no expert by any means, but this makes sense to me. Plus, I can’t come up with many modern workloads where delayed ACK would result in significant improvement. That said, I feel the same about Nagle’s algorithm - if most packets are big, it seems to me that both features solve problems that hardly exist anymore.

Wouldn't the modern http-dominated best practice be to turn both off?

Re: It's Always TCP_NODELAY

#82

Post by robinhouston »

skrebbel wrote: post #81

Nagle himself says (or said 10y ago) that the real culprit is delayed ACK: https://news.ycombinator.com/item?id=10608356 I’m no expert by any means, but this makes sense to me. Plus, I can’t come up with many modern workloads where delayed ACK would result in significant improvement. That said, I feel the same about Nagle’s algorithm - if most packets are big, it seems to me that both features solve problems that har…

The article does address that:

> Unfortunately, it’s not just delayed ACK2. Even without delayed ack and that stupid fixed timer, the behavior of Nagle’s algorithm probably isn’t what we want in distributed systems. A single in-datacenter RTT is typically around 500μs, then a couple of milliseconds between datacenters in the same region, and up to hundreds of milliseconds going around the globe. Given the vast amount of work a modern server can do in even a few hundred microseconds, delaying sending data for even one RTT isn’t clearly a win.

Re: It's Always TCP_NODELAY

#83

Post by spacechild1 »

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…

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

I never thought about that but I think you're absolutely right! In hindsight it's a glaring oversight to offer a stream API without the ability to flush the buffer.

Re: It's Always TCP_NODELAY

#84

Post by mort96 »

mikestorrent wrote: post #64
Hikikomori wrote: post #23

Earlier quoted context omitted.

Just to add, ethernet uses csma/cd, WiFi uses csma/ca. Upgraded our DC switches to new ones around 2014 and needed to keep a few old ones because the new ones didn't support 10Mbit half duplex.

What did you still need to connect with 10mbit half duplex in 2014? I had gigabit to the desktop for a relatively small company in 2007, by 2014 10mb was pretty dead unless you had something Really Interesting connected....

There's plenty of use cases for small things which don't need any sorts of speeds, where you might as well have used a 115200 baud serial connection but ethernet is more useful. Designing electronics for 10Mbit/s is infinitely easier and cheaper than designing electronics for 100Mbit/s, so if you don't need 100Mbit/s, why would you spend the extra effort and expense?

Re: It's Always TCP_NODELAY

#85

Post by wronex »

neomantra wrote: post #52
0xbadcafebee wrote: post #27

Earlier quoted context omitted.

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…

There is also ENet which is used in a lot of games (that is, battle tested for low latency applications.)

https://enet.bespin.org

Re: It's Always TCP_NODELAY

#86

Post by josefx »

FridgeSeal wrote: post #76
AnthonyMouse wrote: post #54

Earlier quoted context omitted.

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.

If nobody is maintaining them, do we really need them? In which case, does it really matter? If we need them, and they’re not being maintained, then maybe that’s the kind of “scream test” wake up we need for them to either be properly deprecated, or updated.

> If nobody is maintaining them, do we really need them?

Given how often issues can be traced back to open source projects barely scraping along? Yes and they are probably doing something important. Hell, if you create enough pointless busywork you can probably get a few more "helpfull" hackers into projects like xz.

Re: It's Always TCP_NODELAY

#87

Post by mort96 »

silisili wrote: post #68
AnthonyMouse wrote: post #54

Earlier quoted context omitted.

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.

> The programs that need it are mostly the ones nobody is maintaining Yes, as I mentioned, it should be kept around for this but off by default. Make it a sysctl param, done. > TCP_NODELAY can also make fingerprinting easier in various ways which is a reason to make it something you have to ask for Only because it's on by default for no real reason. I'm saying the default should be off.

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

> Only because it's on by default for no real reason. I'm saying the default should be off.

This is wrong.

I'm assuming here that you mean that Nagle's algorithm is on by default, i.e TCP_NODELAY is off by default. It seems you think the only extra fingerprinting info TCP_NODELAY gives you is the single bit "TCP_NODELAY is on vs off". But it's more than that.

In a world where every application's traffic goes through Nagle's algorithm, lots of applications will just be seen to transmit a packet every 300ms or whatever as their transmissions are buffered up by the kernel to be sent in large packets. In a world where Nagle's algorithm is off by default, those applications could have very different packet sizes and timings.

With something like Telnet or SSH, you might even be able to detect who exactly is typing at the keyboard by analyzing their key press rhythm!

To be clear, this is not an argument in favor of Nagle's algorithm being on by default. I'm relatively neutral on that matter.

Re: It's Always TCP_NODELAY

#88

Post by mort96 »

FridgeSeal wrote: post #76
AnthonyMouse wrote: post #54

Earlier quoted context omitted.

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.

If nobody is maintaining them, do we really need them? In which case, does it really matter? If we need them, and they’re not being maintained, then maybe that’s the kind of “scream test” wake up we need for them to either be properly deprecated, or updated.

How much ongoing development effort do you think goes into, say, something like a gzip encoder?

Re: It's Always TCP_NODELAY

#89

Post by linohh »

mikestorrent wrote: post #64
Hikikomori wrote: post #23

Earlier quoted context omitted.

Just to add, ethernet uses csma/cd, WiFi uses csma/ca. Upgraded our DC switches to new ones around 2014 and needed to keep a few old ones because the new ones didn't support 10Mbit half duplex.

What did you still need to connect with 10mbit half duplex in 2014? I had gigabit to the desktop for a relatively small company in 2007, by 2014 10mb was pretty dead unless you had something Really Interesting connected....

Technical debt goes hard, I had a discussion with a facilities guy why they never got around to ditch the last remnants of token ring in an office park. Fortunately in 2020 they had plenty of time to rip that stuff out without disturbing facility operation. Building automation, security and so on often lives way longer than you'd dare planning.

Re: It's Always TCP_NODELAY

#90

Post by mort96 »

calineczka wrote: post #63
derriz wrote: post #47

Earlier quoted context omitted.

Yeah, I’ve always felt that the stream API is a leaky abstraction for providing access to networking. I understand the attraction of making network I/O look like local file access given the philosophy of UNIX. The API should have been message oriented from the start. This would avoid having the network stack try to compensate for the behavior of the application layer. Then Nagel’s or something like it would just be a…

> message oriented Very well said. I think there is enormous complexity in many layers because we don't have that building block easily available.

It's the main reason why I use websockets for a whole lot of things. I don't wanna build my own message chunking layer on top of TCP every time.
Post reply on HN