As I understand TCP starts a retransmission timer for each data segement it sends and retransmit the packet (assume no dup ack received from receiver) whenever the timer expires and restarts a new timer with longer duration until failures numbers have reached some limits.
Just wondering if it does the same thing for FIN packet loss in transit ? (such as tries of retransmission, timer length increase etc.)
For example, in below TCP close chart,
If 1st or 3rd FIN is lost, does TCP use same logic to retrasmit it like a normal data segment before it fails ?
if after 1st FIN is sent we never heard from receiver for 1st ACK, does sender have to shutdown the TCP connection on its own or have to keep it alive ?
if sender never gets 2nd FIN from receiver, sender should be still in FIN_WAIT2 state, what might be the timeout (I guess not 2MSL ? ) before it directly moves to closed state ? Or does it do it at all ?
As I understand TCP starts a retransmission timer for each data segement
Each segment except an ACK-only segment.
it sends and retransmit the packet (assume no dup ack received from receiver)
Duplicate ACKs don't have anything to do with it.
Just wondering if it does the same thing for FIN packet loss in transit?
Yes.
If 1st or 3rd FIN is lost, does TCP use same logic to retrasmit it like a normal data segment before it fails?
There is no 3rd FIN in the state diagram, but they are subject to retransmission.
if after 1st FIN is sent we never heard from receiver for 1st ACK, does sender have to shutdown the TCP connection on its own or have to keep it alive?
It stays in FIN_WAIT_1 until acknowledged or retries expire.
if sender never gets 2nd FIN from receiver, sender should be still in FIN_WAIT2 state, what might be the timeout (I guess not 2MSL ? ) before it directly moves to closed state ? Or does it do it at all ?
Not at all. The connection stays half open, just as though the sender had done an output shutdown.
Related
In case that a sender sent SYN at the first time, but the sender did not receive SYN/ACK in a timeout duration.
(Q1) When the sender retransmits SYN again, is the re-transmitted SYN same as the previous SYN?
(Q2) Are their sequence numbers same?
Yes it does, but you might observe a difference or two.
A retransmission is exactly what it sounds like; the original packet is retransmitted. This means that the source host, source port, destination host, destination port, initial sequence number, etc. are all the same.
However, if the system supports PAWS and sends the TCP timestamp option, you should expect that the timestamp will change. As a result, the TCP checksum will also change.
In the alternating bit protocol, how does the receiver know the difference between a delayed packet and a correct one. For example if the sender sends a packet with seq#0, it gets severely delayed on the way there, so much so that the sender and receiver have completed 2 packets in between and the receiver is expecting the next packet with seq#0, and instead receives the delayed one. Should the receiver have a temporary storage of the last few packets to compare if it's just delayed or are there other ways to check?
I am taking a packet trace and the server on my system receives a RST flag,, it then replies with a packet were the ACK,RST and PSH bits are all set. This does not seem normal to me? I m not sure why I would see the PSH bit set in a RST scenario? does anyone know why this might be?
Once the connection is established, all packets need to have ACK set and match the sequence number of the received packets for reliable transport/security. RST without ACK will not be accepted. When one side sends RST, the socket is closed immediately and the receiving side also closes the socket immediately after receiving valid RST. It does not need to be and can't be acknowledged.
after TCP handshake
A --->B Syn=x, Ack=y, len=z, ACK Flag
B --->A Syn=y, Ack=x+z, len=o, ACK Flag
A --->B Syn=x+z, Ack=y+o, len=p, ACK Flag
B --->A Syn=y+o, ACK=x+z+p,len=q, RST, ACK Flag
B closes the socket after it sends the last packet and A closes the socket after it receives it.
(not considering TCP window here, or there might be more packets from one end before the acknoledgement)
ACK Flag, acknowledgement number and the procedure of acknowledgement are related but not the same thing.
Per RFC793
RFC793
Acknowledgment Number: 32 bits
If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive. Once a connection is established this is always sent.
Reset Processing
In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN.
The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state.
In a TCP connection the end that performs the active close is required to stay in TIME_WAIT state for 2MSL of time. Why exactly does it need to be 2MSL? Many people said that one MSL is for the final ACK and the other MSL is for retransmitted FIN. But, the RTO of FIN is way shorter than MSL, and the FIN doesn't need to wait for an MSL to be retransmitted. So, their explanation doesn't make sense to me. Can anyone present a specific example of how segments are exchanged during that time?
Figure 1. Packet exchange for TCP connection.
Why does the TIME_WAIT state exist?
The book <<UNIX Network Programming(Volume1,3rd)>> give an answer:
There are two reasons for the TIME_WAIT state:
To implement TCP's full-duplex connection termination reliably
To allow old duplicate segments to expire in the network
I think this is also the answer to this question(Why TIME_WAIT state need to be 2MSL long?)
First look at reason 1. In order to reliably terminate the full-duplex connection, suppose that the last ACK sent by the client in Figure 1 is lost, and the server will retransmit the FIN. In order to receive this timeout and retransmitted FIN, the client needs TIME_WAIT Status; does the TIME_WAIT status have to be 2MSL? In fact, this depends on the server-side FIN timeout retransmission time RTO. If RTO is less than MSL, then TIME_WAIT state MSL is enough. If RTO is greater than 2MSL then TIME_WAIT state 2MSL is not enough, so only when RTO is between MSL and 2MSL , Reason 1 for the existence of the TIME_WAIT state is the reason why the time of TIME_WAIT is 2MSL. In fact, in general, RTO is much smaller than MSL, but considering the worst case, RTO is 2MSL, so the TIME_WAIT state is 2MSL to ensure that the worst case can also receive the FIN that is retransmitted over time.
The time of TIME_WAIT is another important reason for 2MSL. Reason 2, in order to ensure that all packets generated during the duration of this connection disappear from the network, that is, to ensure that when a new TCP connection is established, the old duplicate packets from the connection are already in Disappeared from the network. Some people here may have a question: After the client replies to the last ACK, it feels that all packets can disappear with one MSL. Why do all packets of 2MSL disappear? The reason is:
Suppose that the client sends an ACK just after one MSL time, and the server just starts to retransmit the FIN over time before receiving the ACK, so if the FIN disappears, 2MSL is needed.
Let's recall the process
A FIN B
B ACK A
B FIN A
A ACK B
After above 4 steps, A is now at TIME_WAIT stage while B is at LASK_ACK.
What if step 4(A ACK B) is lost?
B will wait for 1 MSL for step 4, yet failed to get it, so B redo step 3, and step 3 will take 1 MSL to reach A. Hence, A has to wait for 2 MSL for a graceful wave goodbyte.
But there is another question, what if step 4 is lost again? :)
I also have the same question about this. I thought of an assumption.
In extreme senario, suppose the last ACK from client end spends MSL to reach server end. At this point, the end point thinks that this ACK has already perished due to MSL timeout. So server end retransmit the FIN imediately. In order to assure this FIN can reach client end (or if not, we have to assure its perishment), we must have another MSL.
The purpose of TIME-WAIT is to prevent delayed packets from one connection being accepted by a later connection. It can happen as:
A connection from (address a, port p) to (address b, port q) is terminated
A second connection from (address a, port p) to (address b, port q) is established
A duplicate packet from the first connection is delayed in the network and arrives at the second connection when its sequence number is in the second connection’s window.
In such cases the endponts have no idea to identify to identify which connection the packet belongs.
The two reasons for the existence of the TIME-WAIT state and the 2SML timer:
If the last ACK segment is lost, the server TCP, which sets a timer for the last FIN (Finish) bit set, assumes that its FIN is lost and resends it. If the client goes to the CLOSED state and closes the connection before the 2MSL timer expires, it never receives this resent FIN segment, and consequently, the server never receives the final ACK. The server cannot close the connection. The 2MSL timer makes the client wait for a duration that is enough time for an ACK to be lost (one SML) and a FIN to arrive (another SML). If during the TIME-WAIT state, a new FIN arrives, the client sends a new ACK and restarts the 2SML timer.
A duplicate segment from one connection might appear in the next one. Assume a client and a server have closed a connection. After a short period, they open a connection with the same socket addresses (same source and destination IP addresses and the same source and destination port numbers). A duplicated segment from the previous connection may arrive in this new connection and be interpreted as belonging to the new connection if there is not enough time between the two connections. To prevent this problem, TCP requires that an incarnation cannot occur unless a 2MSL amount of time has elapsed.
Tcp must prevent old duplicates from a connection from reappearing at some later time and being misinterpreted as belonging to a new the same connection. To do this, Tcp will not initiate a new connection that is currently in the TIME_WAIT state.
The TIME_WAIT state is twice the MSL, this allows MSL seconds for a packet in one direction to be lost, and another MSL seconds for the reply to be lost.
I've been researching TCP congestion control recently, however one question plagues me...
If I understand everything correctly, TCP will not send NEW data unless allowed by the cwnd (congestion window) and rwnd (the receiving side's window). In other words:
if(flightSize < MIN(cwnd, rwnd))
{
// Send some new data (if possible)
// Taking into account other details that we don't need
// to get into such as Nagle's algorithm, etc.
}
Where flightSize is the amount of data that has been sent but not yet acknowledged.
Let us assume that TCP is going along, sending data, and increasing cwnd as appropriate. Let's say cwnd = [10 full packets], and the flightSize == cwnd. Then packet loss occurs in the network, and the sender's retransmission timer goes off. How/When does New Reno retransmit the unacknowledged data?
Here's my current understanding/misunderstanding:
When the timer goes off, the cwnd will be reset to [1 full packet], the oldest sent but unacknowledged packet will be resent, the rto will be doubled, and the retransmission timer will be reset. So if we say the rto was 1 second when the timer went off, it will get updated to 2 seconds, and the retransmission timer will get started again with a wait time of 2 seconds.
Here is why I'm confused:
In the above situation, TCP will resend only a single packet. Even if that packet gets ACKed right away, TCP cannot send any NEW data because cwnd is still less than the flightSize. So what does it do? Sit around and wait until the 2 second retransmission timer goes off again before it resends another packet? Does it force a resend of the old data since it can't send new data? Does it reset the flightSize, and reconsider all previously sent data to be unsent?
I've read all the RFC's I could find, and all kinds of guides and explanations of TCP. I must have missed something somewhere...
Clarification:
I was considering multiple losses, where TCP is not using SACK.
If duplicate acks are received, TCP will resend the oldest ack on the 3rd duplicate ack (fast retrasmit) and will send new data on and after the 4th duplicate ack (fast recovery). My question concerns what happens if the TCP sender gets less than 3 dup acks?
I found the answer in the book "TCP/IP Illustrated, Volume 2", section 25.11, pages 842-844:
[On a retransmission timeout] the next
send sequence number (snd_nxt) is set
to the oldest unacknowledged sequence
number (snd_una). ... By moving
snd_nxt back, [TCP can begin to
retransmit all unacknowledged data].
In other words, the flightSize will get reset, so data can continue to be sent (in slow start mode). It's just that some of this data may be data that has already been sent before. A cumulative ack might come along that prevents all data from being resent though.
Request for clarification: are you considering a single packet loss? Or multiple losses within a window?
In a single loss case, there will be duplicate acknowledgements received because of packets received after the lost one. I believe New Reno will transmit subsequent packets ("NEW data") in response to the duplicate acks. This then resets the timeout timer.