Thanks so much for watching!!! Honestly out of everything I learned in college, this concept is what is helping me most as an engineer in the industry. I am always glad to share the knowledge and I'm grateful for you listening! ❤️🙂👍 Keep up the good studying!
Thanks 😀 I'm honestly really surprised that new people are still finding this. XD I made it for a class at UCF 😊 and I've found a lot of people taking the exact same class, ironically.
Regarding window size advertisement and ACKs. There are two things I noticed. 1. The TCP window indicates how many bytes a sender can send before it requires an ACK. 2. The TCP Retransmission timer also plays a role waiting for the ACK. Therefore, the TCP timer will only start once the sender has already sent a packet containing the final byte. So for example it advertised a windows size of 800. So I think, the TCP timer will start counting once the packet containing the 800th byte has been sent. Any comments?
#1, yes that is correct. The window size is how many packets can be sent before an ACK is required. A window size that is too big can lead to network congestion. A window size that is too small can lead to delays.
For #2, The timer starts when TCP sends a segment and stops when the ACK is received. So if host A sends a datagram and it times out, then it will try to resend. Alternatively if host A sends a datagram and it is received but the ACK is lost & never received within the timeout, then host A will never know that the data has actually been sent, and it will retry when the timer expires.
The three acks are sent for each piece of data :) One ack is sent for 100, one for 120, and one for 130. 100 and 120 ack got screwed up, but since your ack kept incrementing, it necessarily means that all the data before that has been received, so you don't need to resend the previous acks.
Also, once 130 is received by the receiver, the sender doesn't know that until it recieves an ack. So the receiver will send the ack again if it gets corrupted or if the sender hasn't gotten it before the timeout window. After 3 acks, this is a sign of network instability and usually the protocol is to stop trying and wait until a later time where the network is less busym
I think I see your confusion more specifically now. So the ACK = 130 does not mean that 130 has been sent. It means that 130 is the next byte sequence that needs to be sent. So if your network is trying to send 130, and it fails, you'll get the ack back of the sequence number that needs to be sent, which is 130 in this case. If you get this same ack back 3 additional times, that is a sign of network congestion so you have to fast retransmit the data. Stopping everything to force send the 130 byte sequence.
So when fast retransmission occurrs, does the Cwnd and SSthreshold stay the same? Does is retransmit the packet and then wait for the acK and then keeps going like nothing happened?
Yes, if an ACK is lost, it just sends the next packet. Eventually, because of the cumulative ACK, the receiver will know based on the value of the ACK whether the previous packets were received. Does that answer your question?
The sequence number increments based on the size of the data packet :) So if your initial sequence number is 92 and the next packet is 8 bytes and was successfully sent, the next sequence number would be 100. If the data is lost, then the sequence number stays the same & resends the packet.
your explanation about the importance of cumulative ack is simple and easy to follow. i need this for my assignment this week. thanks!
This is the only good video explaining fast retransmit on youtube, to be honest. Glad I came across.
Yay!!! I am so thankful I have helped someone ^~^
Great video, cleared a lot of confusion i had with acks, thank you !
Glad to clear it up 😊😁 thanks for watching!
Thank you so much for this! Midterm tomorrow i really needed this.
Thanks so much for watching!!! Honestly out of everything I learned in college, this concept is what is helping me most as an engineer in the industry. I am always glad to share the knowledge and I'm grateful for you listening! ❤️🙂👍 Keep up the good studying!
@@kelcamer That's awesome to hear! I'm glad there's people like you to help us out! Did well on the midterm btw! 😊
@@Quantickzz yay! Congratulations!
A wonderful teacher by nature!
Wow! Thank you so much for your kind words 😊
excellent explations!
Superb and excellent...waiting more and more videos like this....
Thank you! 😃
Great
Thank you from iraq
very well explained. thanks a lot!!!
love it. For me, it is a very good explanation. Thanks!
"it drives me crazy personally" *sigh*
Thanks! :) And what's that? What drives you crazy?
haha no it just what you said at 1.03
@@saifulafiqzakaria3221 oh yeah lol
Thank you so much for this short video
Of course!
Thanks ma'am ❤
thank you so much . ure amazing. Love ur teaching style.
Awww, thanks :D
great video Kelsey, thank you !
Many thanks Kelsey.
Thank you for watching! :)
Great explanation
bless your soul
Thanks 😀 I'm honestly really surprised that new people are still finding this. XD
I made it for a class at UCF 😊 and I've found a lot of people taking the exact same class, ironically.
Great content, thank you so much!!
Excellent explanation !!
Thank you! Earned a Sub
You're welcome! 🥰 And thanks for the sub!
Great job!. Upvoted.
awesome explanation!! love it!
Thank you so much!
You are so welcome 😊
awww. How sweet!!!
Amazing! I love you!
Glad you like the video! :)
@@kelcamer A lot!! DO you have any video with RFC 1323 or ECN? I really would like to watch your explanation about it.
@@gatorichyups I don't, but I'll definitely keep that in mind if I do any future TCP videos! :)
Regarding window size advertisement and ACKs. There are two things I noticed.
1. The TCP window indicates how many bytes a sender can send before it requires an ACK.
2. The TCP Retransmission timer also plays a role waiting for the ACK. Therefore, the TCP timer will only start once the sender has already sent a packet containing the final byte. So for example it advertised a windows size of 800. So I think, the TCP timer will start counting once the packet containing the 800th byte has been sent. Any comments?
#1, yes that is correct. The window size is how many packets can be sent before an ACK is required. A window size that is too big can lead to network congestion. A window size that is too small can lead to delays.
For #2, The timer starts when TCP sends a segment and stops when the ACK is received.
So if host A sends a datagram and it times out, then it will try to resend.
Alternatively if host A sends a datagram and it is received but the ACK is lost & never received within the timeout, then host A will never know that the data has actually been sent, and it will retry when the timer expires.
TCP window indicate
limit of reciver
Not limit of sender
So you can send more than tcp window size but it create congestion
thanks bruh
thank you so much
awesome
ali alaei thanks :D
Thank you for such a great video ! :’)
Could you supply the link of the website you've mentioned ?
Wow :D thanks so much for commenting! Sure I can:
www.ccs-labs.org/teaching/rn/animations/gbn_sr/
Didn't understand why those 3 ACKs are sent. Also why will the ACK for 130 will be sent multiple times when 130 has been received by the receiver ?
The three acks are sent for each piece of data :)
One ack is sent for 100, one for 120, and one for 130.
100 and 120 ack got screwed up, but since your ack kept incrementing, it necessarily means that all the data before that has been received, so you don't need to resend the previous acks.
Also, once 130 is received by the receiver, the sender doesn't know that until it recieves an ack.
So the receiver will send the ack again if it gets corrupted or if the sender hasn't gotten it before the timeout window.
After 3 acks, this is a sign of network instability and usually the protocol is to stop trying and wait until a later time where the network is less busym
I think I see your confusion more specifically now.
So the ACK = 130 does not mean that 130 has been sent.
It means that 130 is the next byte sequence that needs to be sent. So if your network is trying to send 130, and it fails, you'll get the ack back of the sequence number that needs to be sent, which is 130 in this case. If you get this same ack back 3 additional times, that is a sign of network congestion so you have to fast retransmit the data. Stopping everything to force send the 130 byte sequence.
Remember that this is a cumulative ack. So each ack will store the next byte sequence.
So when fast retransmission occurrs, does the Cwnd and SSthreshold stay the same? Does is retransmit the packet and then wait for the acK and then keeps going like nothing happened?
Yes, if an ACK is lost, it just sends the next packet. Eventually, because of the cumulative ACK, the receiver will know based on the value of the ACK whether the previous packets were received. Does that answer your question?
Thank you so much. But if the data is lost from host A what will the sequence number?
The sequence number increments based on the size of the data packet :)
So if your initial sequence number is 92 and the next packet is 8 bytes and was successfully sent, the next sequence number would be 100.
If the data is lost, then the sequence number stays the same & resends the packet.
what happenes if seq 100 wasnt received, and then seq 120 is sent immediately after? what are the corresponding ack no?
Are you asking what happens if the seq no ACK for 100 was dropped?
Hello, can i get help plz
Jones Deborah Miller Elizabeth Martin Gary