How TCP Works - Selective Acknowledgment (SACK)

[@renxingliang8903]

This is very useful for me. I am an F5 engineer from China. I often need to look at data packets. Your video is simple and easy to understand. I love it!😘

[@scienceofart9121]

Thank you Chris you saved my 12 hours of reading papers.

[@ChrisGreer]

Happy to hear that it helped! This stuff can be a little dry on paper for sure.

[@ermias736]

you are the most brilliant person i ever seen in TCP analysis

[@CDizzzle4Rizzle]

Your videos are distilling down weeks of independent research. It's awesome, Thanks!

[@ChrisGreer]

Glad you like them! Thanks for the comment!

[@nadlei3270]

You must be an amazing teacher, Chris. This was very clear and easy to understand. Nice job!

[@ChrisGreer]

Thanks Nadlei! I appreciate the feedback and the comment. See you around the channel.

[@AR-dh3yk]

Chris you are like TCP , giving us trusted and oriented knowledge. Unlike the UDP trainers.

[@ChrisGreer]

ACK. :-)

[@mrRDX001]

I love your videos, no bullshit every line is up to the point and precise. Thank you

[@Ipadstands]

Thanks , Your videos are helping me get a better feel for all this

[@ChrisGreer]

Thanks for the comment - glad to hear the videos are helping.

[@mksarav75]

Crystal clear explanation. Thank you very much.

[@ali_HA24]

VERY nice to clear the sequence concept. I love your way of explaining.

[@ChrisGreer]

Thanks for the comment!

[@YahyaALOMAR-f7y]

I really appreciate your videos, you're saving much of my time❤️

[@toigonbai]

best resource for learning tcp protocol

[@pastorhudson]

You're killing it on these tutorials. Thank you very much! What is the chance you could include a link to the trace files in the description? This way we could "follow along" in our own wireshark?

[@ChrisGreer]

Sure! Here is the link to the trace in Cloudshark - www.cloudshark.org/captures/4e8ed77deb52 For my newer videos I am doing more of this, but I haven't done it yet for the older ones.

[@daniel280187]

Thanks for sharing Chris, excellent video supported with great visuals and a practical explanation.

[@ChrisGreer]

Glad it was helpful!

[@netaishvasistha9875]

Hey Chris, very informative video....can u make one video on four way handshake or connection termination please.

[@ChrisGreer]

Hello! Have you checked out my video on FINs vs Resets? kzbin.info/www/bejne/Y6fKnGyGYpuXhrs That one goes into the four-way termination and reset behavior. Hope that helps.

[@irabalabanov4211]

Hi, thank u so much for this video! I have a short Q: at minute 4:27 u show that packet 54 is accepting the next seq is supposed to be 59861, why? In packet 52 seq = 45261, len =1460, in packet 53 seq = 325, len = 0, how did it jumped to 59861?

[@陈元-t5q]

what's missing in between is 46721 and 59861, that's what the SACK showed to the other side what was missing and what was received, 59861 to 62781.

[@omegamooon]

Excellent as usual.

[@ChrisGreer]

Thanks for the comment Mohammad!

[@letsgopacket4419]

thanks man!! this really help

[@ChrisGreer]

Glad it helped! I have more coming out about sequence number analysis, so stay tuned!

[@pedrojaviermunozgarcia3721]

Neat and clear, excellent job! Thanksss

[@ansgar9289]

Great explanation!

[@MrHawk407]

Chris thanks a lot for this session, its awesome always, why cant you create WCNA course,

[@ChrisGreer]

Hello Sivasakthi! If you have not had a chance to yet - you can check out my Wireshark courses on Pluralsight - www.bit.ly/wiresharktshoot www.bit.ly/wiresharktcp I cover a ton of ground about Wireshark and TCP in these two courses. Check them out!

[@mautezsyria8480]

perfect , Chris Thank you very much here we can see many duplicate ACK ( not just 3 ) before fast retransmission, when this rule will apply :)

[@ChrisGreer]

Point of capture is important. If you are capturing from the perspective of the sender, you will see 3 duplicate acks followed by the retransmission. If you are capturing at the receiver, you may see many duplicate acks, since you are not aware of the retransmission yet.

[@mautezsyria8480]

@@ChrisGreer many thanks really appreciate

[@Rafael-zc6xy]

Hi Cris! I have a question about SACK: In 5:13 the TCP DUP ACK has: ACK 46721 SACK 59861-61321 (the package below will increase only the right edge) In 5:37 the package has SEQ 61321 Next Seq 62781 What would happen if the package above had a SEQ = 62700 instead of 61321? In this case the next DUP ACK would have 2 SACKS to indicate: 59861-61321 and 62700-62781 (gap between 46721 and 59861, and another gap between 61321 and 62700). Is that right?

[@ChrisGreer]

Yes, that is correct. If there was another gap in the sequence, the next ACK would indicate this by starting up another SACK block like you indicated. So the sender would need to fill in the space between 46721 and 59861, as well as 61321 and 62700. Nice work!

[@Rafael-zc6xy]

@@ChrisGreer Thank you!

[@abhaypratap5311]

Make a video on TLS handshake process.

[@ChrisGreer]

That's a good idea for a video Abhay. Let me work on it.

[@shirtguy9322]

@@ChrisGreer "just do it "~ Nike :)

[@TalkingMisc]

@@ChrisGreer Looking forward to it.

[@subhamthemusicalguy8851]

You are doing a great job.Thank you so much

[@ChrisGreer]

Thank you very much for the comment Subham!

[@tejasmokashi7466]

Excellent explanation.

[@nighthawk3897]

Nice and concise, thanks. I wonder...what controls how long or how many bytes the SACKer will wait before it gives up?

[@arshamghafari4906]

Why did I find you this late? damn, thank you man.

[@ChrisGreer]

Glad you found the channel!

[@ee07168]

great job Chris, can i have the Wireshark file , the one which you are using for this video

[@briancoverstone4042]

While filling in the missing sequences, what happens if one of those packets are received out of order? Can there be multiple left/right edges to indicate that there are two sections missing?

[@williewilfred88]

Great video, subscribed!

[@ChrisGreer]

Thanks for the sub!

[@sald35]

Is there a link to the pcap that was used?

[@student4373]

I understand the concept of SACK_PERM, but I'm a little confused: To me it seems as though SACK_PERM = 0 implies that the TCP connection will be using the Go-Back-N protocol, whereas with SACK_PERM = 1 the TCP connection will be using the Selective Repeat protocol. I can't seem to find any information on this elsewhere so I'd love to know if I'm mistaken or not.

[@Ajay-tn2ep]

Make a video on DNS in-depth like, different type of records

[@mikiszafeiroudis758]

Great video as usual! One thing that confuses me is the Seq (1-201, 301-501) shown in the diagram. Since each packet is 100 Bytes I was expecting to see 1-200 (1-100 for packet #1 and 101-200 for packet #2). Respectively, I would expect to see 301-500 for the second sequence.

[@surenderkamboj]

Yeah I feel the same. Seq number should be 1-200 and Ack would be 201.

[@Aashnakunkolienker]

Yes@@surenderkamboj

[@seanwilliams7073]

Thanks for giving me the ammunition to put this wireshark capture back to the customer's network 😁

[@dimplejaral2239]

thanks again very much, keep doing good work!!!

[@briandsouza1550]

Thank you Chris!

[@jackliyong]

if the gap is filled,does the sever resend these packets sequence number after the last gap sequence number?thanks

[@ToddMagers]

Great video Chris!

[@ankurgupta8233]

Thank you so much for this video

[@ChrisGreer]

You are welcome! Thanks for the comment.

[@papyrus1113]

I have a question about congestion control in relation to SACK. If a TCP layer uses SACK and a packet is missing, does TCP then detect congestion?

[@charan_75]

What does it mean when it says a max of 4 SACK blocks can be reported in 1 segment?

[@foshan]

Hi Chris, is it possible to have multiple "holes" on the TCP stream, i.e. missing multiple packets that are not contiguous. How can SACK left edge and right edge work in that case.

[@ChrisGreer]

Hello! Great question. The answer is yes. I cover that in my SACK video, here is the link to it. kzbin.info/www/bejne/jHa1mHxuhsaMhrs In short, most TCP stacks can handle up to four "blocks" of data, with holes between each block. This informs the data sender about the missing sequence numbers so these can be retransmitted. This is also a topic I cover in detail in my Foundational TCP Analysis course on Pluralsight - bit.ly/wiresharktcp

[@foshan]

@@ChrisGreer Thank you Chris. That is very helpful

[@ChrisGreer]

@@foshan Sure thing. Let me know if you have any other questions or video suggestions.

[@SnortDefence]

post some out of order and gre fragmentation packet analyses and tshoot

[@ChrisGreer]

Great ideas, thanks!

[@sizhuangliang9118]

This is amazing!

[@ChrisGreer]

Thank you!

[@MimJim6784]

Thanks. It was great. I would be better if you share the pcap file.

[@ciscosubu]

if the SACK feature is NOT supported ( which will be discovered in the TCP 3 way hand shake ) will the TCP transaction proceed . let say client is sending with SACK suppport or server is sending SYN-ACK with SACK suppport ( but client doesnt support) . jusy wanted to know the TCP-transaction will still proceed . or in the TCP- 3 way hand shake RST will happen ??? can you please shed more light on this . and also microburst scenarios which will lead to TCP packet Drops 2 or 3 TCP packets getting dropped .

[@andypratama100]

One i want to ask is, what is mean ACK, did it like d-dos attack like somebody trying sending malware but the main purpose is to make the connection slower, even some case it cause hacked and error to machine. Cause in my case is so much like that, imagine i am online just 4 minutes but packages which i am received are 17,000 and 40% are ACK then the detail i got is not website but like devices. Noted i am using wifi in here.

[@goblingames7711]

Hi Chris, Is there a specific reason why when a packet goes missing that client then sends an acknowledgment for each packet it receives with the left & right edge values in the SACK option? Normally the client will acknowledge any two packets or two full-size packets.

[@ChrisGreer]

Hello Goblin, to boil it down to a simple statement - it gives the sender more feedback about what went missing and can trigger a fast retransmission quicker. Now the details - RFC 2581 mentions that after a point of loss or reordering a receiver will dup ack every segment until the gap is filled. As these fly back to the sender, three duplicate ACKs will trigger a fast retransmission, rather than waiting for the full retransmission timer to expire. So if we only "acked" every other packet, even when there was loss, this process would take longer to get the info back to the sender about the missing segment. This feedback also helps the sender to adjust its congestion window according to how much and how often data was lost. So as much info about the loss as quickly as possible will help TCP keep that congestion window high. I hope that helps.

[@goblingames7711]

@Chris Greer, thank you for your reply. Also, I appreciate you and others putting up videos to help educate people like us who are interested in learning about networking and packets analysis. Your videos have helped me with some of my own Ah-ha moments (even if I am learning it for fun).

[@bilalmsayed]

Thanks a lot chris

[@bhatanirudha]

Namaste Sir, Kindly guide me, how to find TCP data throughput from the pcap file... Thank you

[@ChrisGreer]

Hello Anirudha - have you checked out my video on the TCP Trace graph? kzbin.info/www/bejne/r4bQcnabiNKHbdE That one goes into throughput a bit. But I plan to make a focused throughput video soon. Thanks!

[@syedmobeen981]

Great work !!!

[@yadsingh58]

Amazing videos sir indebted.

[@masudimtiaz2325]

Excellent! Thanks,

[@philozow]

Thank you very much!

[@ChrisGreer]

You're welcome!

[@zzsql]

I learned at a SANS conferences (Ed Skoudis) that if we send sequence numbers 1-99, we'd get an ACK of 100, acknowledging all before 100. Any dropped packets would be cleaned up by selective acknowledgements, if any. You say you ack 1-201 with a 201 ACK? Someone is incorrect.

[@ChrisGreer]

If I send 0-99 and you ack 100, that is a missing byte and TCP would freak out. So… gotta ACK every byte, no more.

[@megapode2648]

Is there a way I can download this exact trace to follow along?

[@SoulJah876]

What happens to lost traffic in the absence of the Selective ACK?

[@ChrisGreer]

The receiver will only be able to ACK the highest seq number before the point of loss. Any post-loss traffic that was received will not be ACKed without a SACK block. So those will need to be resent even though they were successfully received.

[@SoulJah876]

@@ChrisGreer got you, that makes sense. Many thanks.

[@ShadyNetworker]

What happens when more than one gap in the data stream appears? The TCP ACK seems to point to the first expected segment at the start of the gap, while the SACK's keep track of the running data. What happens if another gap appears?

[@ChrisGreer]

Hey, great question! SACK can handle that. It just starts another SACK block. You will see a second one appearing in the TCP options that shows what has been successfully received. It is up to the sender to resend the gaps between the blocks. Some stacks can support up to four blocks, while some only support two or three.

[@ShadyNetworker]

@@ChrisGreer Wow, that's funky. Thanks for the answer! This helps me dig deeper into TCP. And thanks for the videos, it's unbelievable that you make this available for free, they are a fantastic resource! Very concise :)

[@ChrisGreer]

@@ShadyNetworker Thanks for the comment. i will keep them coming!

[@stephen8253]

@@ChrisGreer Following up to that question, what will happen if those SACK blocks have been exhausted?

[@Zach-ge3kj]

thank you sir

[@pramodb8165]

good one

[@markopopoland]

Can You make about Profinet TCP frames and diagnostic. You can have huge amount of viewers :)

[@Aashnakunkolienker]

Hey! this is conceptually a little incorrect. If the client sent bytes 1-201, the ACK number sent by the server would have number 202 !

[@pwn0x80]

tq

[@howieg]

They are all great , but watching this in the "How Tcp Works" playlist , this one should have been moved up to even above Seq Numbers.

[@llJoDall]

ACK VIDEO

[@Kumar-gd3qh]

0 dislikes :)

[@troysipple2591]

Fantastic

[@ChrisGreer]

Thank you! Cheers!