I need another "cisco answer" here folks.
I was watching another training video and the instructor mentioned the following example:
Data Sender sends 4 segments to a Data Recipient:
- Seq 100
- Seq 200
- Seq 300
- Seq 400
If Sequence 200 didn't make it to the recipient, the recipient would send back an ACK 200 (which is considered error detection) and the sender would resend the lost segment (which is considered error recovery).
I can't help but disagree with this... I would think that the process of requesting segments to be resent (and sending them) is a function of "error recovery" and that error detection is associated with other error checking functions (for example the TCP payload checksum).
My question is: What components of TCP pertain to "Error recovery" and what components of TCP pertain to "Error detection"? Cisco answers please
What the training video is describing is a Retransmit. The way it is describing it is a Fast Retransmit. Interestingly enough a TCP Ack is not an Acknowledgment of the segment specified, but an expectation of which segment it is expecting. Since the receiver has already received higher sequenced segments, it assumes that the earlier one was lost in transit. It then start pumping out acknowledgements for the earlier segment (again the segment it is expecting) until it is received. This bypasses the TCP timers that would have to expire for a normal retransmit and allows for quicker recovery.
I agree with you that that isn't the error detection/recovery process but segment loss recovery process. The error detection and recovery process is a little less familiar to me. However, I am pretty sure this is what happens. Anyone else please correct me if I am wrong.
Each tcp segment has a checksum. This is typically offloaded into hardware on the NIC. So if you look at it in Wireshark, you will see bogus errors. For this reason, I recommend disabling TCP Checksum Validation on sniffers when looking at traffic source or destined to the pc where the sniffer is running.
Anyway, this Checksum is calculated as the datagram is built. After it has been transmitted the receiving station checks it. If it doesn't calculate properly, the segment may have issues and is dropped. This station could certainly acknowledge this segment to trigger a fast retransmission, and I would expect it to do so. Again, this is in the TCP stack and may behave differently in different OS's. The recommended behavior is probably in RFC793.
Cisco Answer? I don't know. I'd pay extremely close to the wording of the question.
EXCELLENT feedback Paul. Thanks!
When the ACK is calculated, there is also some window factoring going on as well. Looking at how protocols work is really fun. That's one reason I love playing with issues in Wireshark. The best reading I have found on the guts of TCP is in TCP/IP Unleashed 3rd Edition. Pretty engaging book about packets and protocols
Great response as always Paul!!!
I have one minor question concerning your statement: 'The TCP checksum gets off-loaded to hardware on the NIC.' TCP is L4, and therefore, an OS, TCP/IP stack thing, and NICs are L2, so I believe the TCP PDU would simply be passed up the stack, and processed by the OS...IMHO.
I totally agree with your logic. Honestly, I'm not sure how it is done. I usually think of the network driver as a shim between the stack and the NIC. Evidently, there must be some hooks back into the special hardware on the NIC to allow it to handle this. Basically, it is supposed to keep the TCP Checksum calculation off of the System CPU. Maybe similar to a GPU? Attached is actually a screen shot of the setting that is in my laptop (I know, don't dog me because its Vista). I looked around briefly just now and didn't find anything that explained this. I've always just known that it existed because you can look at your own trace in Wireshark and have unexpected results until you disable it. If anyone knows more architectural specifics on this, I'd like to know.
I truly enjoy these exchanges...you push my level of understanding! I agree with you. The network driver resides between L3 and L2 at the (NDIS) Network Driver Interface Specification layer, for TCP/IP, or the (ODI) Open Data-Link Interface layer, for IPX/SPX. Therefore, the NIC driver does "act" as a shim between the TCP/IP stack, implemented by the OS, and the NIC.
You're correct, there would have to be be "hooks" from the NIC into the stack. Not sure why the NIC would handle the processing of the TCP checksum. It does appear to though, according to the screen shot.
You were correct all along:
In other words, when you're turning it off on the NIC, you're allowing the Upper-Layer protocol via the CPU, to process the checksum as it normally would. By turning off the NIC's ability to process the TCP checksum, you're allowing WireShark which is running as an Application to get the correct checksum as processed by the CPU. This appears to be something newer, faster, NICs are capable of.
When you pass your CCENT, you had better continue to ask questions!!! I learn so much from your questions and the responses from those answering your posts.
Have you changed your Avatar?
I think when Mike pass his CCENT he will jump to CCIE with all the knowledge he has acquired.
I still think he is really Scott. . Just joking Mike.
Hi Conwyn ol' Buddy,
Yeah, I changed my avatar, with me in an "cloud." I'm like the infamous network cloud: once the data enters, one never knows, how, where, or if, the processing takes place, or whether it has exceeded the CIR...lol.
What Scott says is true. We were seen in public together last week. That was BEFORE he realized one of my computers had Vista on it. I have to wonder if he would have agreed to lunch with me had I told him my home Laptop has Vista.
I would have had to seriously rethink that.
Or make sure to go home and bathe.