I seen everywhere in slow start mechanism if initial sender size denoted by cwnd= 1mss , then after 1 RTT cwnd becomes = 2 mss, and after 2 RTT cwnd becomes = 4 mss and so on. My question is why transmission time (TT) isn't added with RTT? That means if cwnd= 1mss , then it should after 1 RTT + 1 TT cwnd becomes = 2 mss, and after 3 TT+ 2 RTT cwnd becomes = 4 mss and so on. So my assumption is that cwnd becomes 2^n after nRTT + (2n+1) TT where we take 1 TT per 1 mss and n=0,1,2,3,4..........................


1 Answer 1


My question is why transmission time (TT) isn't added with RTT?

In the context of TCP, RTT can mean two things.

  • Meaning one: RTT that is supposed to be measured by TCP to calculate retransmission timeout.
  • Meaning two: RTT is used in the description of congestion control algorithms.

Meaning one of RTT

TT is inside RTT.

RTT is measured at the implementation of layer4. It measures the time between layer 4 send the packet to layer3 and layer4 receives ACK from layer3 [at least, some layer4 processing might end up in RTT as well].

Thus RTT includes host processing at layer3 and below, sending of the packet, all network processing, receiving the corresponding ACK and processing up to layer3 on the host for the ACK.

Note, that it is impossible for TCP implementation to know when the packet is actually sent out of the system. This is done by a network card, which does not notify OS about this. It is especially impossible if the packet is sent over Wi-Fi. Nobody knows how much time the packet needs to wait before the channel is free to send it. Also, OS implements buffers for outgoing interfaces. This queueing delay is in RTT as well.

Meaning two of RTT

This RTT is quite fuzzy.

The idea is the same - for a single segment it means the time between layer4 sending segment to layer3 and layer4 receiving corresponding acknowledgement.

However, in a lot of cases it actually means the time between first packet of current window is sent and first ACK of the current window is received. It works under the assumption that sending time of a window is smaller than RTT, i.e., by the time the first ACK of a window is received, the whole window is already sent.

This allows to reason of congestion control in rounds, where each round corresponds to one RTT. In each round, congestion control specifies window size, aka number of packets sent in this round.

Obviously actual TCP congestion control cannot work like this. This is an abstraction that is used to simplify understanding.

Note: When diving deeper in congestion control, this abstraction can become somewhat confusing. It is reasonable to assume that round time (in this case RTT) is constant and independent of congestion window, but it is not. When congestion window becomes large enough, it causes excessive packets to be buffered on bottleneck link, which increases RTT. Thus the RTT is actually not constant and slightly increases with congestion window once the window has reached certain threshold.

  • What about TT you just explain unnecessary things?
    – Alok Maity
    Sep 23, 2021 at 9:05
  • How can you say "TT is inside RTT. "? And RTT measures the time for sender packets in l4 to receiver in l4 and acknowledgment from l4 to sender l4? Your concepts seem to be wrong..
    – Alok Maity
    Sep 23, 2021 at 9:36
  • how would TCP even know transmission time?
    – Effie
    Sep 23, 2021 at 11:32
  • and if you say you add TT why don't you add receive time. TCP piggybacks ACKs, which means an ACK can itself be a full segment, with its receive time exactly as long as transmission time.
    – Effie
    Sep 23, 2021 at 11:34
  • Acknowledgment negligible here.
    – Alok Maity
    Sep 23, 2021 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.