Determining the time to receive in object using TCP

5.8k views Asked by At

The question I am trying to figure out is:

In this problem we consider the delay introduced by the TCP slow-start phase. Consider a client and a Web server directly connected by one link of rate R. Suppose the client wants to retrieve an object whose size is exactly equal to 15S, where S is the maximum segment size (MSS). Denote the round-trip time between client and server as RTT (assumed to be constant). Ignoring protocol headers, determine the time to retrieve the object (including TCP connection establishment) when

  1. 4S/R > S/R + RTT > 2S/R
  2. 8S/R > S/R + RTT > 4S/R
  3. S/R > RTT

I have the solution already (its a problem from a textbook), but I do not understand how they got to the answer.

  1. RTT + RTT + S/R + RTT + S/R + RTT + 12S/R = 4 · RTT + 14 · S/R
  2. RTT + RTT +S/R + RTT +S/R + RTT +S/R + RTT + 8S/R = 5 · RTT + 11 ·S/R
  3. RTT + RTT + S/R + RTT + 14S/R = 3 · RTT + 15 · S/R

and here is the image that goes with the answer: client-server diagram

What kind of makes sense to me: Each of the scenarios is one where the RTT time is more or less than the time it takes to transmit a certain amount of segments. So for the first one, it takes somewhere between 3S/R and S/R seconds per RTT. From there I don't understand how slow-start is operating. I thought it just increases the window size for every acknowledged packet. But, for example in the solution to #1, Only two packets appear to be sent and ACKed and yet the window size jumps to 12S? What am I missing here?

2

There are 2 answers

0
almanisulaiman On

This trick is to understand that if 3R/S > RTT > R/S, then when the server is busy 4 packets (blue ones), it will receive an ACK before it has finished sending the 4th one. So the rest of the time would be 1RTT for (previous ack and) packets to travel and n * R/S where n is the number of packets sent one after another without wait.

Now before we get to the server sending 4 packets, there will be 1 RTT for auth, 1 RTT + R/S till the time client has sent 1st Ack, 1 RTT + R/S till the time client has sent 2nd Ack, and when the server receives the 2nd ack (and 3rd in very short order), it will send the rest of the packets (blue and purple ones) together because it will not be waiting for ACK because RTT < 3R/S. You can do a similar analysis for the other parts.

0
Rony_Stack_overflow On

Yes the answer is correct,

Slow start double the amount of MSS every time, so starting from 1 then 2 then 4 then 8...

To understand the figure, think of it that way: EACH time ONE MSS is well received , 2 MSS are sent. in your example: when the first green mss is well acknowledged , 2 blue mss are sent and when the second mss is well acknowledged , 2 more blue mss are sent.

When the number of mss increases you wont be waiting RTT because while sending the acknowledgment other MSS are being set in a simultaneous way.