Troubleshooting the hidden dangers of TCP’s Nagle algorithm and delayed acknowledgement

As we all know, TCP/IP is a great protocol suite.  However, there are times when it can become the bottleneck.  This is especially true if you use TCP/IP for real time transactions where small data sizes are the norm (think financial institutions).  In this session, I’ll show you why Nagle algorithm and delayed acknowledgement was developed.  But more importantly, I’ll highlight the unintended consequences when the two features interact – badly – with each other.  After watching this session, you will be able to spot the hidden dangers of using TCP/IP for real time transactions.   Enjoy, and as always, I would really appreciate your feedback and suggestions. Here is the video:

And as always, any and all feedback and suggestion are welcome.  Thank you and Enjoy!

Hansang Bae

16 thoughts on “Troubleshooting the hidden dangers of TCP’s Nagle algorithm and delayed acknowledgement

  1. Hansang Bae

    @credible58, thank you! If you have any ideas for future sessions, by all means, please let me know.

  2. Jasper Bongertz

    Nice presentation, Hansang, as usual. The only thing that I might have added to the slides would haven been an animation of what would be different without the push flags.

  3. Hansang Bae

    Ah, good point. I removed some popup hints, quizzes etc. because youtube doesn’t support it. That would have been a good one, especially since I talk about it on the PPT. BTW, I just spent an hour anonymizing an upcoming CIFS troubleshooting scenario. What a pain that was! :)

  4. Andrew

    Great presentation, you gave a very clear explanation of the rules on the message sequence chart that made understanding the actual packet trace easy. I also like that you made the packet trace available.

    I’m left with one question though, why does packet #7 in the trace get to go immediately? This packet is only 226 bytes long so isn’t an MSS and there is unacknowledged data in flight (the bytes in #4, #5 and #6) so even though the Push bit is set in #7 my read of the Nagle rules on your slide #4 is that the only way #7 can be sent is if the Nagle override timeout expired? Yet the time between packet #7 and #6 is 16us which means the override timer cannot have expired. I’m presumably missing something though?

  5. Hansang Bae

    Andrew,
    Give me a day or two. I’m on the road and will be back this weekend. I will reply when I’m back in the office. thanks

  6. Hansang Bae

    Andrew,
    I’m glad you picked up on it. There are other small nuances in this trace that I didn’t get into . I didn’t delve into them just yet because this was more of an intro. 20/20 hindsight, I think it might have been better to tackle the bread and butter “nagle/delayed-ack” case first. But I’m very happy that you picked up on the fact that 10.10.10.10 probably has Nagle turned off. Another user Aaron also contacted me about packet #7! So I’m very happy that you guys are picking up on the small nuances of protocol analysis!

    There are other oddities in the trace, and I may come back to it after a few more sessions.

  7. Hansang Bae

    Hai,
    Thanks. Please feel free to download the presentation and pcap files and use it to your heart’s content! I see your presentation was much more thorough, was it for a class you were teaching? I can’t read it (if it was Korean, I could! :) ) but I see enough TCP related acronyms to get the feel of it.

    Thanks,

    Hansang

  8. krishnayeddula

    Superb Video. It does nothing but enhances the Zeal to learn. That bus example was simple yet powerful.

    Hansang,
    People are thirsty here.Some more please.

  9. Hansang Bae

    @krishnayeddula, @Cyril, @Beulah, @Money..
    Thank you. Another video will be coming out shortly. I’m glad that my passion for protocol analysis is coming through! :)

Comments are closed.