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
Great video, Hansang.
@credible58, thank you! If you have any ideas for future sessions, by all means, please let me know.
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.
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! 🙂
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?
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
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.
Great session.
I wrote something about TCP Nagle algorithm and Delayed ACK before in Chinese.
http://wenku.baidu.com/view/fbfda71aa300a6c30c229f99.html
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
Hansang,
I am working at one company for technology consultant.
Writing it only as case because I often encountered them at work.
Thanks.
These retransmissions are killing me!
That’s pretty funny, K! 🙂 Sorry folks, that’s a little insider joke!
Very very knowledgeable video. thanks for all the efforts taken to create this good stuff!
It’s my pleasure jaspreet! Glad you found it useful.
thnx
Hansang
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.
@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! 🙂