TCP Congestion Control // Hands-On Deep Dive TCP Analysis with Wireshark 

Working on more as we speak! thank you for watching and commenting.

Thank you for the comment! I appreciate the positive feedback.

thank you for the comment!

Thanks for the comment!

Thank you for the comment!

Thanks for the comment!

Thank you! Will do!

Awesome! Glad the video helped you!

My pleasure!

Great to have you! Yeah congestion control is a tough thing to get straight.

Glad you stopped by Mike!

Glad you enjoyed it!

Wow thanks for the comment Colin!

Yikes, yeah it's a tough one to understand. I'm glad it helped!

Happy to help!

You bet! Glad it helps.

Glad you liked it!

Glad you enjoyed it!

You got it!

You're very welcome!

My pleasure!

I love that stuff. Good idea!

Thanks for the comment!

Welcome Alex!

Thanks for watching and commenting!

Thanks!

Thanks a lot!

Thanks for the comment Yohan!

Glad to hear it!

Very welcome!

Most welcome!

Thank you!

Thanks and welcome!

Definitely!

Hey Nathan, nice job! Great analysis and great question. Without having a pcap on the other side, we can't be 100% sure, but we definitely can measure that 20mSec delta between the RT and the Out-of-order (which is also technically a retransmission but the wireshark TCP analysis bits can sometimes get that confused). Based on the behavior, I would say that there are a two possiblities 1. Like you mentioned, the server could have halted 20msec in transmitting the second retrans. 2. The network could have buffered it along the path. I say that because we already see high latency and congestion-induced loss on this network. So it's possible it got stuck in a buffer for a few ms en route. Either way - great spot and thank you for the comment! This is definitely a case-in-point of why i ask my clients for dual-side captures when I am doing deep TCP analysis. Takes the guessing out of the way. Keep on capturing Nathan!

That is great to hear. Have you checked out my wireshark course - www.bit.ly/wiresharkintro It is a good overview of wireshark

Thanks for the comment. I haven't seen a pcap like that yet. If you have one let me know and I could feature it.

Hey thanks for the comment! They are very closely related concepts so it's easy to mix them up. Here is an awesome article about sliding windows that should help - www.extrahop.com/company/blog/2017/tcp-windowing/

I would say so because that is a super small MSS! Are you thinking of the initial window? I haven't ever increased it that much manually. I'm sure the super-smart people who designed the TCP stack did though....

​@@ChrisGreer Yeah the value which defines the initial window size. I performed performance tests over TCP to boost performance over lines with latencies and 100-1000 MBPS. ("Fat long pipes") Before sending app data which is very consuming (MB-GB of data), it sends few MBs (1-10). I found that with latency it took x3 times as much because of the slow start. So I boosted it up to 64 initial MSS and got the best result because it no longer slow started. [Was very visible in the Wireshark also thanks for your videos :) ]

Haha! Please don’t drop out for my content! 😜 honestly just keep analyzing traffic no matter what and you will have a bright future in this field, college or not.

Thanks for the comment!

The TCP stack itself usually has a default window size option that is used. However it is possible for an application to override this option with a different value.

Gotta check, but I am pretty sure it was cubic as well.

Look above the "Sequence Number" field in the TCP header. You should see TCP Segment Length. That is the one you want to add as a column. Right click - Apply As Column.

@@ChrisGreer Found it. Thank you.

Hey! Great question. In short, kinda. ACK frequency is usually dependent on the stack settings and how sensitive it is to incoming data. In this case we do see the receiver delaying the ack for several large ingress MSS's, but it is not time based. We can see that the receiver is striking a balance - ACKing quickly, but not every other packet which isn't really necessary in this case. I've seen this behavior with throughput tests like these where a large amount of data quickly arrives at the receiver.

@@ChrisGreer Thanks, I appreciate your answer.

Good spot @richardscheffenegger9138 - this trace was created using iPerf. I tweaked a few of the window size settings so it would be easier to see the collapse of the congestion window. When you are teaching cwin, doing so in a real, uncontrolled environment is very tricky. Not the best way to introduce new learners to the concept.

@@ChrisGreer Sure. I meant which OS (& version) this was captured on. Linux is supposed to infer the slow-start phase and ACK every segemnt then (non-RFC behavior). TSO/LRO/GRO can interfere and create this extreme ACK thinning you showed. So for a clean (textbook) example, disabling TSO/GRO and clearing the HostCache are key. For the highest alignment of the TCP implementation with the RFCs, you may want to use FreeBSD or another BSD variant. If you want to show some fancy effects like continous cwnd growth while the application limits its sending speed, and then provides a huge chunk of data, you want to use uperf. That could demonstrate what happens After Idle, or when the cwnd is kept open, with little data transfern, until a massive burst of data is provided - line rate jump in the TCP sending rate, usually massive induced losses in the Tail-Drop queues, and even lost retransmissions (which again Linux does a very good job handling, even while RFCs are silent on that). You may want to look into RACK/TLP (Netflix traffic) though, since the loss recovery there is quite outstanding. And as I mentioned elsewhere, a good demonstation of the TCP ECN control loop is no where to be found, even though many large players (MSFT, Apple, ...) have started deploying ECN since a few years. (Also check DCTCP). If you want more details, contact me ;)

@@richardscheffenegger9138 As I recall this was between a Win11 and Mac 11.1.x or something like that. A lot of what you are describing is far beyond the intent of this video and even beyond the interest of the standard RU-vid viewer. Good fodder for a TCP Congestion course though.

Hello! That is a great question. So an ACK carries no data and does not have the SYN or FIN bit set, both of which will increase the seq number by one (the ghost byte). So in this case, .196 is not sending any data, so there is no need to move the seq number forward in that direction. Hope that helps!

@@ChrisGreer thank you!

Without the packets it's tough to say for sure. But I am guessing that the server is timing out the encrypted session first, and the client is just reacting. After the FIN that the client sends, it considers anything other than the ACK to that FIN to be further activity, and it will reset. It could be just how the client's TCP stack settings are configured. Unless it is actually breaking anything with the application, you should be able to ignore it. It's just ending the connection with a reset.

Thanks for the initial analysis Chris. I have the wireshark captures with me. Can I mail you the those ? Would you help me with the further analysis ?

@@anubhavkumar2059 the RST may only a courtesy notificiation to the server, to quickly move on from the TIME-WAIT state, releasing some still held resources on the server side... Allowing for a quick recycling of the 4-tuple for a new session (some OS don't have too much leeway in their ephemerial port selections, and re-using the same one in quick succession could otherwise result in a very delayed reconnection time...

It will usually go up quickly until it reaches to ssthresh value (slow start threshold) which is an internal value in the stack.

Hey great comment. That is because not all OS’s and applications tweak according to the RFC. iPerf is especially picky about it. SHOULD is always a fun word to navigate.

Nowadays, IW is up to 10; and frequently tunable (as root) - RFC 6928. Also, virtually all full-feature stacks cache some path information between subsequent sessions - to not overshoot with slow-start the (previously recorded) capabilities of the network (Host Cache). During slow start, ABC (appropriate byte counting) - RFC3465 - is in common use, since delayed ACKs (with an extreme example in the shown trace - more likely ACK thinning going on by the network, or ACK compression due to receiver side LRO, but less likely based on the involved timings - allows for a growth of up to 2 MSS per ACK, if that ACK covers 2*MSS or more - this is to address ACK splitting attacks, where a receiver once could drive the sender to ramp up slow start extremely quickly, locally (close to the server) resulting in massive congestion and an effective DoS attack variant. I would really like to see real advanced topics - such as Timestamps for troubleshooting, how to spot common signatures of TSO, LRO, ACK compression, ACK thinning, HyStart [++], SACK+RTO, Lost Retransmission (Detection), ECN (AccECN), PRR, Rescue Retransmission, TLP, RACK, BBR and what may be typical misbehaviors associated there would be.

Got it! One of the best , probably the best video on tcp packet congestion

You seem to enjoy these “clarifications”. Could you please post a like to your channel? Might be a better way to go.

@@ChrisGreer I find it amusing that someone who clearly doesn't understand network protocols in any sort of comprehensive way has a "channel". The modern one-eyed man in the land of the blind. Good for you.

It’s ok if you are afraid of creating your own channel and posting content. I really did feel like that for a long time. I felt like I had nothing to share. I felt like everyone would hate my content, think I was stupid, would over criticize the smallest detail. It’s normal. I’m so blessed to have experienced the kindness and good will of the overwhelming majority. You will too. Give it a try. I’ll be happy to reference your stuff!

@@ChrisGreer Right. The guy who reads stuff off a wireshark display without knowing what he's talking about is brave and I'm afraid.

I haven't seen that! Sounds interesting though....

@@ChrisGreer i am smelling some new content! :D