why we make each burst of data 2 times the product of bandwidth and delay?

Question

Below is from my textbook:

if we need to send data in bursts and wait for the acknowledgment of each burst before sending the next one. To use the maximum capability of the link, we need to make the size of our burst 2 times the product of bandwidth and delay; we need to fill up the full-duplex channel (two directions). The sender should send a burst of data of (2 × bandwidth × delay) bits. The sender then waits for receiver acknowledgment for part of the burst before sending another burst.

I'm a little bit confused here, let's say we have a bandwidth of 1 bps. We also assume that the delay of the link is 5s. According to what the textbook says, we need to send each burst of 10 bits. Does it mean that we make each 5 bits data as a message, and each time we send two messages actually?

PS. Below is a picture from the textbook

I don't understand why some people says the it takes 5s for receiver to receive the message, in this example, 5 bits is considered as a message, and the receiver receives the first bit after 5s, and it takes another 5s to receive the last bit, so it needs a total of 10s to receive the whole 5 bits, isn't it? besides, we can only send another message before we get the ack from the receivers, so if we send 10 bits(two messages),isn't that against the meaning of acknowledge?

Answer 1

The sender should send a burst of data of (2 × bandwidth × delay) bits. The sender then waits for receiver acknowledgment for part of the burst before sending another burst.

Look at these last two sentences. The key to understanding what the author meant, about "(2 × bandwidth × delay) bits", is in the last sentence. "The sender then waits for receiver acknowledgment for part of the burst before sending another burst."

Here's a timeline of what happens.

1. t=0, sender starts transmitting, at 1 bit per second
2. t=5, the first bit starts arriving at the receiver, even as the next 4 bits are immediately following it and still in transit, as can be seen in the picture.
3. t=5, assuming the receiver can respond immediately and doesn't need any time at all to decide if even the 1st bit is received correctly, it immediately starts sending an ACK (say, a 1-bit ACK, like 1 for success, 0 for failure).
4. t=5 to t=10, back at the sender, it continues to send bits 6 to 10 out, even while it has not yet received the ACK from the receiver. The sender does this because "the size of our burst 2 times the product of bandwidth and delay", which is 10 bits.
5. t=10, the sender receives the ACK from the receiver (this assumes the delay in the reverse direction is also 5 s), for the beginning part of the burst that the receiver had sent at t=5. The sender has just finished transmitting the 10s burst at this time, and so the arrival of that ACK is just in time for the sender to continue utilizing the maximum capability of the link and starting to send the next burst immediately, without needing to wait for the ACK.

Even though this illustration has flaws, the point the author is trying to make is that it takes time for an ACK to come back to the sender, so if we don't want this to affect the overall throughput, the sender needs to be sending out more data even while some earlier data that was sent out has not yet been acknowledged.

Probably the author may be following up later with concepts of windowing, where there can be multiple burst not yet acknowledged but the sender keeps sending burst as long as the window is not filled, etc.; and also, with more realistic assumptions like a whole "burst" needs to be received by the receiver to verify it is not in error, before the receiver sends an ACK for that burst. But the author may be building up to these concepts to come.

Answer 2

Your textbook does a poor job of explaining the concept. You might look for other sources.

Your example doesn't work well, because the serialization delay is tremendously large (20% of the propagation delay). A more workable example is to assume the bandwidth is 1kbps. Now the serialization delay is negligible.

Let's assume the TCP window is 5kb. You start sending data. After you've sent your entire windowo, you have to stop and wait until you get an ACK to send more data. The receiver gets the data 5 seconds later, and sends an ACK. You receive the ACK after another 5 seconds for a total of 10 seconds (2 * delay). So you end up waiting 10 seconds before you can send more data. That's 5kb every 10s or 500bps.

If you make your window equal to 2 * delay * BW, or 10kb, by the time you've sent a window's worth of data, you've received the first ACK from the receiver. So you can continue to send more data. In this way, you use all the available bandwidth, instead of sending small bursts of data and waiting in between.

Answer 3

The quoted text from your book is wrong on several levels. The two easiest to explain are below. Do not trust information from this resource.

• It's well-understood that you don't need to wait for a fixed number of in-flight transmissions to be acknowledged before sending additional segments. To use TCP terms, this is why we have a window that grows in the absence of congestion.

• The text claims the reason for 2 multiples of bandwidth*delay is full-duplex links. This is wrong. Why would the availability of bandwidth, in the direction not being used for transmission, be used to calculate the amount of unacknowledged data allowed to be in-flight?

Answer 4

The time it takes for a data packet to travel from source to destination and for the acknowledgment to travel back to the source is two times the delay or the round-trip time RTT.

To utilize the connection's full bandwidth during that period you need to send RTT * bandwidth data - or 2 * delay * bandwidth.

If you send more data (assuming higher sender interface bandwidth than path bandwidth) you are exceeding the network capacity. The path gets congested, some data will be queued and the excess must be dropped.