Dan Jaffe commented on May 25, 2009

Need to better explain Nagle & TCP delayed acknowledgments as it interacts with NRPC

Please review how Nagle's algorithm works and why in some cases you may need to disable it based on the systems TCP/IP stack (both interacting systems - Client or Servers).

In some cases the nature of the network topology and/or the traffic running concurrently over it may require disabling Nagle. And, lastly the type of data being transfered between the Domino servers and Notes clients in some cases may benefit disabling Nagle.

Link: { Link }

In most cases I have found correcting the network design or correcting the TCP/IP stack was better than turning Nigle off.

As NRPC has many different traffic types {small ACK packets as well as small data block and full data block packets} at any given time between servers or between client systems. Nagle is useful {as long as the physical network is healthy or not overly latent in its design}

What confuses people is NRPC is a RPC dialog (ping-pong) between the two systems. So, from that stand point one would NOT want Nagle enabled based on the nature of the dialog type. But, NRPC is more than a straight RPC dialog (i.e. TelNet), it also transfers very large data blobs intermixed within the RPC dialog. So, Nagle then becomes useful as the TCP buffers (not the application networking buffers) are better used in the data transfer.

The real problem is 'TCP delayed acknowledgments' feature within some systems TCP/IP stack Vs using Nagle. Review your systems TCP/IP stacks age & settings if you can update or disable 'TCP delayed acknowledgments' instead and also address any network design or network hardware problems.

Again, this is not a cut and dry problem/fix so each Domino network as it relates to the physical network needs to be looked at.

Dan Jaffe commented on May 25, 2009

Need to better explain Nagle & TCP delayed acknowledgments as it interacts with NRPC

Please review how Nagle's algorithm works and why in some cases you may need to disable it based on the systems TCP/IP stack (both interacting systems - Client or Servers).

In some cases the nature of the network topology and/or the traffic running concurrently over it may require disabling Nagle. And, lastly the type of data being transfered between the Domino servers and Notes clients in some cases may benefit disabling Nagle.

Link: { Link }

In most cases I have found correcting the network design or correcting the TCP/IP stack was better than turning Nigle off.

As NRPC has many different traffic types {small ACK packets as well as small data block and full data block packets} at any given time between servers or between client systems. Nagle is useful {as long as the physical network is healthy or not overly latent in its design}

What confuses people is NRPC is a RPC dialog (ping-pong) between the two systems. So, from that stand point one would NOT want Nagle enabled based on the nature of the dialog type. But, NRPC is more than a straight RPC dialog (i.e. TelNet), it also transfers very large data blobs intermixed within the RPC dialog. So, Nagle then becomes useful as the TCP buffers (not the application networking buffers) are better used in the data transfer.

The real problem is 'TCP delayed acknowledgments' feature within some systems TCP/IP stack Vs using Nagle. Review your systems TCP/IP stacks age & settings if you can update or disable 'TCP delayed acknowledgments' instead and also address any network design or network hardware problems.

Again, this is not a cut and dry problem/fix so each Domino network as it relates to the physical network needs to be looked at.

Michael Kobrowski commented on Mar 17, 2009

Proof reading?

Maybe a revision review/proofreading process including a professional writer would be helpful?

Collaboration? :)

Amy Hoerle commented on Jan 22, 2009

Recommendation for Prior to 8.5 is incorrect

The recommendation for servers prior to 8.5 should state that:

Prior to Domino 8.5, have DEBUG_PD_NAGLE_OFF=1 present in the notes.ini