# Why not use the channel capacity as the sliding window size?

In a sliding window protocol, if we use the maximum possible capacity of the channel as the size of the sliding window, efficiency will be theoretically 100%. What is the logic behind not doing this?

My guess is that this is done for throttling. Are there any other reasons?

EDIT: After reading the answer by bakuriu, I come to the conclusion that using the capacity as the sliding window size can make the system unreliable:

1. The receiver buffer may fill up and the increased transfer rate at the sender side will become useless.
2. Congestion and packet loss may increase. Reasons are pointed out in the linked answer.

But what if it is an Ethernet (preferably a LAN) using the Selective Repeat protocol for the data flow and CSMA/CD for choosing the sending station.

1. The receiver window would be of the same size as the sender window. So, filling up the receiver buffer should not be a concern.
2. There wouldn't be multiple stations competing for data transfer once the transfer has started (because of how CSMA/CD is defined).
3. In a wired connection (and preferably being a LAN), packet loss would be less.
4. Sender doesn't have to resend the whole window in case of packet loss or corrupted packet (because of Selective Repeat).

Do we usually try to use the channel capacity as the sliding window size in such (highly customized) cases?

• This question seems confused. Sliding window size is in unit of "bytes". Channel capacity is in unit of "bytes per second". So, it's simply not possible to set the sliding window size to be the channel capacity; those quantities are not comparable. Are you possibly thinking of the bandwidth-delay product instead of the channel capacity? – D.W. Sep 20 '15 at 4:25
• @D.W. I'm talking about the total number of bits required to fill up the channel. Do you suggest a better term than channel capacity? – – aste123 Sep 21 '15 at 17:20
• Did you read about bandwidth-delay product yet? I suspect it's the concept you're looking for. Note that "number of bits required to fill up the channel" has to be defined carefully: it potentially depends on how much other users are sending and thus might not be measurable. – D.W. Sep 21 '15 at 17:34