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

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?

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.

• @auspivious99 Thank you for your answer. I get the idea,but still have a question, it seems that the receiver will send ack bit for every bit it receives , so the receiver will send a nth ack bit for the nth bit it receices, which is against the fundament of what a ack is , for example, you need to wait for the first ack to decide whether you can send the second bit, if you didn't receive the first bit, you need to send the first bit again, but in your case, you send the second bit regardless of the success receiving of the first bit. Commented May 17, 2020 at 3:59
• @secondimage Yes, in this example. the author appears to be talking about a scheme where you send an ack bit for every bit received. As you have pointed out, continuing to transmit bits before receiving acks for the earlier bits, means, the sender might later find out that one of the earlier bits was not received. There are ways to handle that, probably discussed later in the chapter in the textbook. But a main point in the simple example is that the sender needs to keep transmitting to use the maximum capability of the link. Waiting for each ack before transmitting more, is too inefficient. Commented May 17, 2020 at 6:03
• @auspivious. Thanks I see. Yes this example is covered in early chapter, author will cover TCP window in later chapters Commented May 17, 2020 at 6:07

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.

• Thanks for your answer. But I don't understand why "The receiver gets the data 5 seconds later", isn't that the receiver gets the full 5kb in 10 seconds? I have added a picture to denote in my post , could you have a look? Commented May 16, 2020 at 23:15
• No. It only takes 5 mS to put the data on the wire. It arrives 5 seconds later. Commented May 16, 2020 at 23:23
• But it takes one sec to send one bit since the bandwidth is 1bps, how can we send 5 bits in one sec? Commented May 16, 2020 at 23:57
• I was assuming 1kbs. 1 bps is 20% of delay Commented May 17, 2020 at 1:15

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?

• It's clearer if you say bandwidth * (delay * 2). delay * 2 is the round-trip time (RTT) that it takes for the first ACK to reach the sender. Of course, it has nothing to do with full duplex.
– Zac67
Commented May 16, 2020 at 16:03
• @Zac67 but why we need to send bandwidth * (delay * 2) data?Does the data contain one or two messages? Commented May 16, 2020 at 22:48
• @secondimage bandwidth * delay is the amount of data "in flight" between sender and destination. The exact same amount has already been received by the destination before its ACK reaches the sender (assuming delay is symmetric). If you send less the connections idles.
– Zac67
Commented May 17, 2020 at 6:10

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.