I've learned that after three duplicate ACKs (so a total of 4 ACKs with the same value), the sender assumes that a packet was lost and sends the packet with that value again.
Here's a graph from the book I'm reading:
In this case, what does the receiver respond? ACK 120, or ACK 157?
This really depends whether or not SACK (Selective ACK) has been negotiated. If it has:
Each retransmission of ACK 100 will include a TCP SACK option indicating the aggregate of bytes that have been received after the missing segment that are pending if the gap is filled
Given what you show you should see SACK indicating that offsets 120-135, then 120-141, then 120-157.
When the missing 20 bytes are transmitted, you will see ACK 157
If SACK has not been negotiated:
You will see ACK 100 indicating the missing segment for every segment after that
When the missing segment is sent, if it contains only the original 20 bytes, the ACK will be for 120 and all subsequent segments must be retransmitted as well.
I've learned that after three duplicate ACKs (so a total of 4 ACKs with the same value), the sender assumes that a packet was lost and sends the packet with that value again.
Here's a graph from the book I'm reading:
In this case, what does the receiver respond? ACK 120, or ACK 157?
This really depends whether or not SACK (Selective ACK) has been negotiated. If it has:
Each retransmission of ACK 100 will include a TCP SACK option indicating the aggregate of bytes that have been received after the missing segment that are pending if the gap is filled
Given what you show you should see SACK indicating that offsets 120-135, then 120-141, then 120-157.
When the missing 20 bytes are transmitted, you will see ACK 157
If SACK has not been negotiated:
You will see ACK 100 indicating the missing segment for every segment after that
When the missing segment is sent, if it contains only the original 20 bytes, the ACK will be for 120 and all subsequent segments must be retransmitted as well.
I have been learning wireshark lately. While inspecting TCP segments, I saw a strange situation, at least for me. There was a mismatching SEQ,ACK numbers. Then I realized that difference between two ACK's same as 1 and half package size. However, as far as I know, ACKs are only growing by the full packet size. So what happened here?
SEQ ACK
1 1
2897 8689
5793 13033 <--
8689 14481
11585
14481
Well, there's not much to go by here, but I'm going to guess that you are capturing packets on the machine sending the large packets, i.e., the packets with 2896 bytes of TCP payload. As such, you are seeing the packets before they are IP-fragmented and actually transmitted out on the wire.
But you can't just send 2896 bytes of data onto the wire; Ethernet links typically impose a 1500 byte MTU (Maximum Transmission Unit), and when you account for IP and TCP header overhead, you usually end up with 1460 bytes of available payload or MSS (Maximum Segment Size). In your case it looks like you're only getting 1448 bytes of available MSS, most likely due to the addition of one or more IP and/or TCP header options.
In any case, the 2896 bytes of payload are going to be fragmented over 2 IP fragments, each containing 1448 bytes of TCP payload. I'm pretty sure that what you're seeing is an ACK from the receiver after having received 1 full segment plus 1 IP fragment from the next segment.
The previous ACK number was 8689, and 8689 + 2896 = 11585. Now add 1/2 of the data segment (2896 / 2 = 1448) and you get 11585 + 1448 = 13033. That's the ACK number you're seeing. Now add the other 1/2 and you get 13033 + 1448 = 14481, which is the ACK number of the next packet.
I hope that makes sense?
For an in depth look at the drawbacks of local packet captures, I direct you to a well-written blog by Jasper Bongertz titled, "The drawbacks of local packet captures".
Since I do not have reputation to comment the answer of Christopher Maynard, I comment it here.
As Christopher stated correctly the MTU (Maximum Transmission Unit) is standard Ethernet networks is 1500Bytes. However, crafting 1460Bytes (1500Bytes - 20Bytes IP Header - 20Bytes TCP Header, ignoring possible TCP options) TCP segments imposes a high load on the network stack since every segment must be handled separately.
As an example, if I want to transmit 1Mb (equals to 1024*1024Bytes = 1048576Bytes) of data, it would result in 1Mb/1460Bytes = 719 segments. In contrast to 1Mb/65525Bytes (theoretical max TCP segment size) = 16 segments. Since the overhead in the Kernel is mostly independent of the segment/packet size, small segments require much more processing.
To counteract this fact, TCP Segmentation Offloading (TSO) was developed. TSO allows the Kernel to craft TCP segments with maximum size and the NIC (Network Interface Card) uses hardware acceleration to split these segments into the separate TCP segments of 1460Bytes. Therefore, no IP fragmentation is required.
In a situation where both client and server sets their respective sequence number to 0, I read that the following is true:
C-->S: SYN=1, SEQ=0 (No data bytes)
C<--S: SYN=1, SEQ=0, ACK=1 (No data bytes)
C-->S: SEQ=1, ACK=1 (Data bytes optional)
In the third part, I understand the server is expecting the next sequence number to be 1, but aren't sequence numbers supposed to be set to initial_seq_num + sent_data_bytes_num? Since there was no data bytes sent in the first part of the handshake shouldn't the seq # be 0?
Is this just an exception during the handshake or are segments sent to with no data bytes supposed to increment the sequence number by 1 if they can be sent at all?
(There is a similar Q & A but the answer doesn't explain if this is an exception during the handshake phase OR if this happens after a TCP connection has been establish. I'm not even sure if a segment with no data bytes can even be sent. I'm assuming you can't)
ADDED It seems TCP keep-alive packets have no payload either. RFC 1122 says in these packets, SEG.SEQ = SND.NXT-1, and because this sequence number will be an already ACKed number, and a duplicate ACK will be sent, so as to keep the sequence number of the server the same.
Otherwise, I couldn't find any indications of what needs to be done when the sequence number is correct but there is no payload. I might be wrong since I only briefly scanned the document, but there is also no statement of rules of sequence numbering during the handshake except for examples.
In RFC 1122, it says
Unfortunately, some misbehaved TCP implementations fail to respond to a segment with SEG.SEQ = SND.NXT-1 unless the segment contains data.
So I'm assuming it depends on each implementation, but if there is any statement of a) the sequence numbering during handshake, and b) how to behave when the sequence # is correct but there is no payload, I would really appreciate it if someone could point me to that part.
Thanks!
The first ACK (that occurs as part of Handshake) acknowledges the reception of SYN from the other end. The SYN segment does not carry any data. But to allow the provision for acknowledging the reception of SYN, the first ACK is incremented though no payload is present.
I was reading Computer Networking from Kurose, and while reading in the TCP chapter about the differences between TCP and Go Back N I found something that I don't fully understand. The book says the following about some of the differences between the two protocols:
"many TCP implementations buffer correctly received but out-of-order segs rather than discard.
also, suppose a seqof segs 1, 2, …N, are received correctively in-order,ACK(n),
n < N, gets lost, and remaining N-1 acks arrive at sender before their respective timeouts
TCP retransmit most one seg, i.e., seg n, instead of pkts, n, n+1, …, N
TCP wouldn’t even retransmit seg n if ACK(n+1) arrived before timeout for seg n"
I understand the buffering of out-of-order segments, but I don't understand the other behavior, and I think it is because I don't fully understand Go Back N. Following that example, if ACK(n+t) arrives before Go Back N timeout, the protocol would continue as if seg n was in fact received, which is the case, because of the accumulative ACKS... so, Go Back N wouldn't retransmit that segment either.... or am I missing something?
I was looking at this question's answer and after finding it I thought even though this is old, it might help someone, so I copied a fragment from Kurose-Ross Computer Networking - A top down approach:
Is TCP a GBN or an SR protocol? Recall that TCP acknowledgments are
cumulative and correctly received but out-of-order segments are not individually ACKed by the receiver. Consequently, the TCP sender need only maintain the smallest sequence number of a transmitted but unacknowledged byte (SendBase) and the sequence number of the next byte to be sent (NextSeqNum). In this sense, TCP looks a lot like a GBN-style protocol. But
there are some striking differences between TCP and Go-Back-N. Many TCP implementations
will buffer correctly received but out-of-order segments [Stevens 1994].
Consider also what happens when the sender sends a sequence of segments 1, 2, . . . ,
N, and all of the segments arrive in order without error at the receiver. Further suppose
that the acknowledgment for packet n < N gets lost, but the remaining N – 1 acknowledgments
arrive at the sender before their respective timeouts. In this example, GBN
would retransmit not only packet n, but also all of the subsequent packets n + 1, n + 2,
. . . , N. TCP, on the other hand, would retransmit at most one segment, namely, segment
n. Moreover, TCP would not even retransmit segment n if the acknowledgment
for segment n + 1 arrived before the timeout for segment n.
My conclusion: in practice TCP is a mixture between both GBN and SR.
see these links, it is easy to understand about GBN and SR:
Go Back N protocol (GBN):
enter link description here
Selective Repeat protocol (SR):
https://www.youtube.com/watch?v=Cs8tR8A9jm8
in GBN and SR protocol,the receiver has to send ACK message for all segments which it has received in the slide window.
in TCP protocol, the receiver don't send ACK message for all segments which it has received in the slide window. the receiver only send ACK to get the next segments that it expect. it means that less ACK messages will be sent to the sender. therefore, it is good for reducing network congestion.
in abnormal cases, some segments are lost (by network congestion or bit error), TCP transmission time is longer than GBN and SR because the receiver can not sent 2 ACK messages at the same time.
in my opinion, losing segment rarely happens. so TCP protocol optimizes for normal cases instead of abnormal cases. in normal cases, TCP is better than GBN and SR
The quote says that the ACK(n) got lost, not the nth segment got lost. In such case, nothing needs to be re-transmitted, because ACK(n + x) means that everything upto n + x was successfully received.
I was confused by the statement from the book too, but I think I have found the answer:
Consider also what happens when the sender sends a sequence of segments 1, 2, . . . , N, and all of the segments arrive in order without error at the receiver. Further suppose that the acknowledgment for packet n < N gets lost, but the remaining N – 1 acknowledgments arrive at the sender before their respective timeouts. In this example, GBN would retransmit not only packet n, but also all of the subsequent packets n + 1, n + 2, . . . , N. TCP, on the other hand, would retransmit at most one segment, namely, segment n. Moreover, TCP would not even retransmit segment n if the acknowledgment for segment n + 1 arrived before the timeout for segment n.
Actually, in the above example, even though the ACK for packet n+1 arrives at the sender before its timeout, one has to be aware that the timer for packet n could have timed-out before that arrival. So, because packet n timeout and the GBN has not seen ACK(n+1) or ACK(n+2)... so far, it will trigger the re-transmission of all packets after n .
However, for TCP, the sender would only send packet n again at this specific moment.
P.S. this question has been very old. But, anyway, hopefully that might help anyone.
ACK(n) acknowledges arrival of the entire stream up to n. So ACK(n+1) says that everything up to n+1 has arrived, including n.