7

I have a question regarding TCP timeout. If we look at this picture http://www.dcs.bbk.ac.uk/~ptw/teaching/IWT/transport-layer/timeout.gif

We can see that the timeout starts when the packet loss occur, but how long is the timeout? Is it until the specific packet has been delivered and acknowledged or when?

To clarify, I'm not asking about any specific time. I'm just asking for what are indicating that a TCP timeout has been finished.

BlommaN
  • 95
  • 1
  • 1
  • 4
  • i bet you could find the answer in 5 seconds if you googled it.. – Ron Trunk Aug 19 '15 at 15:19
  • 1
    If I had I wouldn't have asked this question. If you know it I appreciate if you can help me instead. – BlommaN Aug 19 '15 at 15:35
  • When I google "default TCP timeout," I get several answers right away. What do you get when you google it? – Ron Trunk Aug 19 '15 at 15:38
  • 1
    But my question is not what the default TCP timeout is, my question is when a TCP timeout ends. (For example a TCP handshake ends when ACK+GET has been sent) So I'm not asking for any specific time or similair. – BlommaN Aug 19 '15 at 15:44
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Dec 31 '20 at 20:59

5 Answers5

4

Short Answer: Basically the timeout is indicated by a retransmission of a packet that is now considered lost.

Long Answer: A TCP stack sending component sends a stream of bytes. The sending window is the range of sequence numbers of bytes that are currently in flight. When sending the first byte (sequence number: x), a timer is started that has a default timeout. When the timeout ends, we retransmit. In case there is an ACK for byte y and y >= x, the timer is reset and we are awaiting an ACK for y+1. The reason for accepting everything above and equal x is due to the fact that ACKs in TCP are cumulative ("ack everything including the mentioned number") in contrast to selective ("ack only mentioned number").

Netzdoktor
  • 415
  • 2
  • 4
  • 11
3

There is no specific end time for TCP timeout. When it times out the session is dead. It does not "stay dead" for a specific time period.

Ippy
  • 345
  • 1
  • 4
  • 14
  • Well I'm not asking for any specific time or something. All I want to know is what indicates that TCP timeout has passed? If we look at TCP handshake (http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_9-4/94_syn_fig1_lg.jpg) We can see that when the first ACK arrives the TCP handshake is done. What indicate when TCP timeout is done is my question. – BlommaN Aug 19 '15 at 16:29
  • 1
    I think this is what you are looking for: [TCP STATE TRANSITION DIAGRAM](http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html#ST) – Ippy Aug 19 '15 at 16:51
2

The indication for a timeout to be finished is not receiving an ACK for the packet that started the timer.

TCP uses a ACK messages sent by the receiver to let the sender know a packet was correctly received.

So basically, if a portion of bytes of the message is not ACK'd then the timer will expire and cause the timeout.

You can read more here on sections Reliable transmission, Error detection and Selective acknowledgments

Lowb
  • 21
  • 4
  • You should expand on your answer, and maybe provide some documentation. One-line, unsubstantiated answers (correct or not) are generally frowned upon and considered suspicious. – Ron Maupin Jan 29 '16 at 17:32
  • @RonMaupin alright, done!+ – Lowb Jan 29 '16 at 21:56
2

We can see that the timeout starts when the packet loss occur, but how long is the timeout? Is it until the specific packet has been delivered and acknowledged or when?

Wrong. Look closely at the picture and you will see that the timeout starts exactly as the packet is being transferred, not when it is loss.

A node does not know the time of when a packet is loss (it is not possible). Before that, I will explain what is a timeout. When a node is sending a packet to another node (for example, using TCP), the sender node sets a timer for that packet to be replied. This is called a timeout. If a reply for the packet does not arrive within the timeout, the sender node will assume that a packet loss has occurred. This will cause the sender node to re-send/retransmit the packet.

So timeout is the time limit for the sender node to receive a reply from the destination node before retransmit the packet.

I'm just asking for what are indicating that a TCP timeout has been finished.

You can however determine when it is 'finished' or more precisely, what behavior does a sender do after the timer/timeout has been reached. As mentioned before, when a sender decides to retransmits a packet, it indicates that the timeout has been reached (or what you called as "timeout has been finished").

amiris
  • 21
  • 2
1

you are speaking different languages.....

the question is wrong: there is no timeout discovery or notification.

if pkt X where get lost CONNECTION IS NOT; sending host will not receive ACK for that pkt wile (not)receiving host just see more and more data coming from source; when "second copy" arrives TCP reassemby all into a meaningful something.

if TCP connection X get lost it mean that a firewall or other active device has dropped it (and allow not to rebuild except if you made a new one).

so, there is no kind of timeout discovery except timeout expiration that is not a discovery nor a notification

switch
  • 51
  • 2