I'm pretty sure that
Wikibooks: Serial Programming,
Wikipedia: automatic repeat request, and
Wikipedia: sliding window protocol
cover this.
You're running a very small aperture terminal (VSAT) at 4096 kbps.
The latency for a packet to travel from Earth to a geostationary satellite and back to Earth is about 250 ms.
I'm assuming you're trying to communicate with someone else on earth, and the satellite is a more-or-less passive relay station.
Such a VSAT has a minimum latency of about 500 ms between the time we sent a packet that somehow gets corrupted and the time the sender realizes that it was corrupted.
Let's say your average packet size is P (perhaps P is about 4096 bits per packet).
- Stop and wait ARQ for each packet: You get 1 packet out, and about 500 ms later, you (usually) get an ACK and send out the next packet. With no errors, that gives about 1/(500 ms) = 2 packets per second. (Perhaps this would go at 8 kbits/second, not counting retransmissions, but you could go much faster by making P somewhat larger). The occasional error makes the effective data rate slightly slower.
I'm going to assume full-duplex communications for the next two.
I'm going to assume that the sender and the receiver can both handle the full 4096 kbps data rate indefinitely, not requiring gaps between packets.
And I'm going to assume that the "window size" is more than big enough to hold all the in-flight packets.
(These assumptions may be over-optimistic, but at least we're considering errors now).
With both Go-Back-N ARQ and Selective Repeat ARQ, at 4096 kbps, the transmitter has sent about 500 ms * 4096 kbps = 2048 megabits between the time it sends a packet that becomes corrupted, and the time the sender realizes that packet was corrupted and needs to be re-sent.
With an error rate of 5 x 10E-6 (and assuming independent errors) we have on average 200 kbits of good data between errors. At 4096 kbps, we have on average 49 ms between one error and the next error.
(This is all more-or-less independent of the packet size P, assuming P is much much less than 200 kbits).
Go-Back-N ARQ: Each time we start re-transmitting some previously-sent (but corrupted) packet, we get (on average) 25 ms (?) of good data gets through before the next error, and then 500 ms later the transmitter figures out exactly what packet that next error was and again starts re-transmitting from that packet. So we have on average 525 ms per cycle, with on average 100 kbits of good data per cycle, giving an effective data rate of 190 kbps, more or less independent of packet size.
Selective Repeat ARQ: This gives an effective data rate of approximately (nominal data rate)(data in packet / total size of packet including sequence number)( 1 - (bit error rate)(packet size) ). (Perhaps 4012 kbps, but by making P somewhat smaller you could go a little faster).
(You may consider graphing effective throughput vs packet size. There will be a peak "best packet size" for selective-repeat, and another peak "best packet size" at much larger packet size but much lower data rate for stop-and-wait.)
Selective-Repeat ARQ gives far better effective data rate (goodput), when the amount of data in-flight is very large, than Go-Back-N ARQ or stop-and-wait ARQ.
However, we don't often use Selective-Repeat ARQ, because it is more complicated and gives no better performance in the more common case where the amount of data in-flight is less than 1 packet -- i.e., we are usually transmitting over much shorter distances, or at slower (nominal) bit rates, or both.