Subject: Is nagle disabled?

From: Rob van der Putten <[email-masked]>
Date: Fri, 9 Sep 2016 15:59:04 +0200

Hi there

I'm experimenting with TCP to see how long it takes to send a small 
amount of data from A to B. One would expect a latency of a few hundred 
milliseconds, but it's a few hundred microseconds instead. It is as if 
Nagle's algorithm has been disabled.

Regards,
Rob

---

From: Stefan Monnier <[email-masked]>
Date: Fri, 09 Sep 2016 12:19:54 -0400

> I'm experimenting with TCP to see how long it takes to send a small amount
> of data from A to B. One would expect a latency of a few hundred

I suggest you re-read https://en.wikipedia.org/wiki/Nagle's_algorithm
Nagle only kicks in when there are un-acknowledged packets.  So on the
first packet, there is no delay.  There will be a delay on the *second*
packet if it's small and we haven't yet received confirmation that the
first packet was received.

        Stefan

---

From: Rob van der Putten <[email-masked]>
Date: Fri, 9 Sep 2016 19:57:45 +0200

Hi there

> first packet was received.

I thought I overlooked something. And this is it.
Thanks!

Regards,
Rob

---

From: Rob van der Putten <[email-masked]>
Date: Sat, 10 Sep 2016 13:28:50 +0200

Hi there

> I thought I overlooked something. And this is it.

So the question should have been 'Is delayed ack disabled'.
I have a hard finding decent information on the subject, so I did a bit 
of experimentation;
I send tiny bits of data (two bytes at a time) to a little echo  server. 
As it turns out, the use of delayed acks and therefore nagle, depends on 
the time between sending the bits of data and the RTT.

Regards,
Rob

---

From: Nicolas George <[email-masked]>
Date: Sat, 10 Sep 2016 13:37:17 +0200

Le quintidi 25 fructidor, an CCXXIV, Rob van der Putten a écrit :
> I have a hard finding decent information on the subject, so I did a bit of
> experimentation;
> I send tiny bits of data (two bytes at a time) to a little echo  server. As
> it turns out, the use of delayed acks and therefore nagle, depends on the
> time between sending the bits of data and the RTT.

I do not think you can really test delayed ACK with an echo server: the
principle of delayed ACK is to leave a little time to the application to
send a reply, because then the ACK can be bundled with the reply, saving a
packet.

With an echo server, the reply comes immediately, never letting the delay
for the ACK expire.

Regards,

-- 
  Nicolas George

---

From: Rob van der Putten <[email-masked]>
Date: Sat, 10 Sep 2016 13:53:57 +0200

Hi there

> With an echo server, the reply comes immediately, never letting the delay

I use netcat6. From man nc;
nc6 --continuous --exec cat -l -p <port>
So the data goes from nc to cat and then back to nc.

Timestamps (epoch.microseconds) are dumped to a file on transmission and 
to an other file on reception of the 'echo'. Further check with tcpdump. 
Experiment on LAN and experiment over DSL;
When the time between the bits of data is larger then the RTT, data is 
send at two bytes per TCP packet.

Regards,
Rob

---

From: Nicolas George <[email-masked]>
Date: Sat, 10 Sep 2016 14:02:01 +0200

Le quintidi 25 fructidor, an CCXXIV, Rob van der Putten a écrit :
> Timestamps (epoch.microseconds) are dumped to a file on transmission and to
> an other file on reception of the 'echo'. Further check with tcpdump.
> When the time between the bits of data is larger then the RTT, data is send
> at two bytes per TCP packet.

With that kind of test, the reply comes immediately, the ACK is bundled with
the reply, therefore making delayed ACK invisible.

The way you implemented the echo server, with several applications
communicating with each other, is irrelevant because it is all invisible to
the network stack.

If you want to observe delayed ACK, you need to use a kind of server where
the reply does not come immediately in the same TCP stream. A discard server
would be the simplest example.

Regards,

-- 
  Nicolas George