TCP/IP Basics with Hansang Session 3
Вставка
- Опубліковано 18 вер 2024
- It’s SYN-ACK Sunday! (should we go with SEQUENCE# Sunday) In this exciting episode, we continue to learn about how sequence numbers work in TCP/IP.
Intro music is “Hey” from www.bensound.com
Playlist for the series: bit.ly/HSB-TCP...
As always, if you have a question please use “@1:15” to tell me what part of the vide you’re talking about. And if there are enough questions, I’ll create the corresponding Q&A video for this session.
Thanks! Hansang
Thanks for coming up with this wonderful series. looking for more to come. thanks once again Hansang Bae
You're welcome 😊 Glad you're finding it useful. I'm itching to get to the packets, and I have to hold back every time I record! :)
I really appreciate these videos!
Glad you like them! Not a bad cover art, uhhhh I mean, thumbnail too, no? /* fishing for compliments */
....woah!!!!!! that was dangerous@0:09....Just a few more inches of standing up and ... 😂
Hey hansang awaiting your this week TCP/ Ip sessions
Here's a hint, I'm a little congested :) Going up today or tomorrow.
Hope it's OK to discuss the homework question here... if not I can remove this.
I would say that nobody cares if a naked ACK goes missing because a naked ACK says "I'm good up to seq number X, so start with X+1", and as long as the next ACK comes in, there's really no issue if the previous one went missing.
For example, if a naked ACK for say #2921 goes missing, as long as the next ACK for #4381 comes in, the effect is the same. The sender knows to start with #4381 and that all data up until that point was acknowledged as received by the receiver. If it were the case that seq numbers acknowledged a particular range, then it would matter if they went missing, but because they just continuing moving the "right edge" further, we can lose naked ACKs with no issue.
I'm wondering though, aren't there situations in which a naked ACK missing could "matter" at least in causing poor performance? Couldn't a naked ACK that goes missing cause a re-transmission to occur from the sender side, if it lines up in such a way that the sender is pausing and waiting on seeing the ACK before continuing to send, causing a "deadlock"? I guess I'm thinking of Nagle's Algorithm, and the sender buffering data, waiting to see a naked ACK that the sender actually sent but went missing?
Andrew, yes, we're all here to learn. You're mostly correct and brought up a lot of points that I wanted people to bring up, so well done! ACK is in fact cumulative, so a few missing here or there makes ZERO difference. **EXCEPT** the one corner case that you brought up. But to be more precise, the ACK that goes missing that ack's the *last* packet of data will in fact cause a retransmission timeout. Which is terrible because the sender will go into congestion avoidance. The reason why is that there are no more data packets being sent by the sender. It was his last chunk of data to send. So he's waiting for the final ACK to come in. But that naked ACK goes missing. So he waits his requisite RTO (retransmission timeout) assumes the packet went missing and will retransmit. But also will reduce throughput because of RTO event.
Now there is another textbook answer. There is no way to tell if ACK went missing in the first place. The receiver of the data sends out the ACK. But there is no tracking of that naked ack by the receiver. Why? Because there is no data that is being transmitted from the original receiver.
In other words, assume that the PC is sending to the server. The server is just ACK'ing that he received it and sends the ACK. The server has no data to send to the PC. So when that ACK from the server goes out, it does not contain any data. So there is no ACK for the ACK packet. Only packets with TCP data is tracked.
Of course the sender (PC in this example) *needs* the acks to do its job properly. But he's not keeping track of the ACK packet itself. He's only using it as a feedback mechanism. If 15 acks come in, it's no different than ack 1 then, ack15 coming in. ack 15 covers 1-14.
Hope that helps, and again, great questions.
@@hansangb Thanks so much for the detailed reply Hansang! I've been learning a ton through your videos not only from this recent course, but your videos from years past on your channel as well. Keep them coming!
@@andrewohanian5132 Glad to be of help! And keep on learning! The grind never stops! :) /* But it's a good grind! */
Awesome thumbnail
LOL. Thank you for noticing! It came to me at the last minute.
Thanks for the session how can i really deep dive in this 🤔 I am afraid now that I don't know this
The sequence number concepts I presented, you mean? Or TCP in general? Did you watch video #2 as well?
@@hansangb yes I watched video 2 and I am talking about knowing TCP to troubleshoot
The Andrew response is a little confusing for me I understand pc sends an ack just an ack no data count from 0 then to 1 then the servers says ok it is 1 (no data) then i send 10 bytes from pc to server and server says thank you for the 10 bytes (1 to 10 = 11) so not please send #11 and then the pc sends 10 more (11-21) so the next sequence number will be 22 or 21??
Hi Lucille, I think you might just be getting a little confused on the math. For that last part - when you start with seq 11 and send 10 more, you will only send 11-20, right? 11 counts as the 1st byte, 12 is the 2nd byte, etc.... 19 is the 9th byte, 20 is the 10th byte. The Next Expected Seq # will then be 21.
Lucille, I didn't quite follow the first part (0 then to 1 then the servers.." But don't forget that NEXT expected sequence number hasn't been sent yet. So you have to very clear about what the current sequence number is, how much you need to add to it, and what the next expected sequence number is, and what the expected ACK number will be. What helps is if you draw out the transfer and fill in the SEQ, # of bytes being sent, NEXT EXP SEQ#, and the ACK coming from the other side. Give that a go and let me know.