2. 1 The utopia protocol  Unrealistic assumptions: –processing time ignored –infinite buffer space available –simplex: data transmitted in one direction only –channel is perfect (never loses, damages or reorders segments) App Trans Net SenderReceiver message segment message segment message segment message segment message segment message segment message segment message segment message segment message segment message segment message 1010101010101010010101010101010 App Trans Net

3. 2 void sender1(void) { while (true) { take some data from the application layer stick a segment header on it send it to the network layer } void receiver1(void) { while (true) { get one segment from the network layer strip off the header pass up the contents to the application layer } if only all protocols could be so simple! The utopia protocol  just inf. loops that copy data  kind, seq, ack fields not used

4. 3 from utopia to stop-and-wait flow control  Problem with utopia: –Even if there are no errors on the channel... –There may be a flow control problem (fast sender, slow receiver)  Suppose we still assume a perfect channel, but try to solve just the flow control problem: GO –Provide feedback from receiver to sender telling it when to maybe it should be called stop-and-go instead of stop-and-wait... STOPor GO.

5. 4 stop and wait flow control void sender2(void) { while (true) { take some data from the application layer stick a segment header on it send it to the network layer wait_for an ack; /* do not proceed until given the go ahead */ } void receiver2(void) { while (true) { get one segment from the network layer strip off the headers pass up the contents to the application layer send an ack /* send a dummy segment to awaken sender */ } sender waits for message_arrival from receiver; essentially, the sender is waiting for an “ack” receiver is sending an acknowledgment segment to let the sender know its ok to proceed. GO

6. 5 segment message segment Protocol 2 Timeline AppTransNetTransApp segment message segment 011111101010101010101001111110 segment 011111101010101010101001111110 segment message segment 011111101010101010101001111110 segment message segment message GO GO (wait)

7. 6 par: positive acknowledgement with retransmission = stop and wait flow control + buffers, acks, timeouts, retransmissions  Basic idea: Since messages may be damaged, sender should retransmit if it doesn’t receive ack within reasonable time segment.  First suggestion: slight modification of protocol 2 with sender operating as follows: send message  Allow for noise. if acknowledgment arrives first, send a new message. if timer expires first, resend message start_timer timeout messages may be corrupted, or may be totally lost. start timer, and wait for the acknowledgment

8. 7 Timeline of protocol 3 retransmission AppTransNetTransApp segment message segment 011111101010101 segment message segment 011111101010101010101001111110 segment message segment message GO start_timer timeout 1010011010109 start_timer

9. 8 Do we need numbers on messages? Yes... AppTransNetTransApp segment message segment message segment 011111101010101010101001111110 segment message segment message 1 message 2 GO start_timer timeout 0111111010101010 011111101010101010101001111110 segment message segment message 1 oops! receiver delivered a duplicate! 011111101010101010101001111110 segment start_timer

10. 9 Fix by adding sequence numbers to segments AppTransNetTransApp 011111101010101010101001111110 segment message 1 message 2 GO start_timer timeout 0111111010101010 011111101010101010101001111110 trans sees that seq number is same as previous, and doesn’t deliver duplicate 011111101010101010101001111110 segment start_timer segment message segment 1 message segment 1 message segment 1 message segment 1 now expecting 0 now expecting 1 still expecting 0

11. 10 Timeout might be premature NetDllPhyDllNet 011111101010101010101001111110 segment message 7 message 8 GO start premature timeout 011111101010101010101001111110 segment 01111110110101010101010101001111110 011111101010101 01111110110101010101010101001111110 segment message segment 1 message segment 1 message segment 1 message segment 1 message segment 0GO message 9 segment message segment 1 011111101010101010101001111110 oops! skipped 8,9! misinterpreting ack of 1 as ack of 0 start segment message segment 1 now expecting 0 now expecting 1 still expecting 0 10110101010101010101001111110 GO message 10 segment message segment 0 start 011111101010101010101001111110 segment message segment 0 message 10

12. 11 Fix by adding seq numbers to acks AppTransNetTransApp 011111101010101010101001111110 1 segment message 7 message 8 GO start premature timeout 011111101010101010101001111110 1 segment 01111110110101010101010101001111110 011111101010101 01111110110101010101010101001 segment message segment 1 message segment 1 message segment 1 message segment 1 message segment 0 message segment 0 011111101010101010101001111110 message 8 successful recovery! sender looking for ack of 0, so doesn’t issue GO signal to net layer; instead retransmits 0. start expecting 1 expecting 0 receiver acks, but doesn’t deliver the duplicate segment message segment 0 still expecting 0

13. 12 Terminology: par, ABP, ARQ, stop-and-wait  PAR is positive acknowledgement with retransmission PAR is also called “Automatic Repeat Request” or ARQ {PAR,ARQ} protocols use buffers, acks, retransmission, timeouts  the “stop-and-wait” part is designed to solve the problem of fast sender overwhelming slow receiver; it’s a form of flow control  for stop-and-wait, one-bit sequence numbers are necessary and sufficient therefore (stop-and-wait + ARQ) is sometimes called the Alternating Bit Protocol (ABP).  Note the distinction: – stop-and-wait is a flow control technique – PAR (which is also known as ARQ) is an error control technique  Also note: –while many authors just lump the PAR part in with stop-and-wait –you can have stop-and-wait without necessarily having retransmissions (e.g., if a lower layer is handling reliability...)

14. 13 t0t0 t 0 + 1 t 0 + a t 0 + 1 + a t 0 + 1 + 2a t0t0 t 0 + a t 0 + 1 t 0 + 1 + a t 0 + 1 + 2a  Transmission time = 1 propagation delay = a>1  Link always under utilized  Transmission time = 1 propagation delay = a < 1  Link still inefficiently utilized (source: Stallings DCC5e, p.160ff) Link utilization with stop-and-wait

15. 14 “The pipelining principle” Main idea: if line holds more than one message, stop and wait underutilizes the link: AppTransNetTransApp TransNetTransApp GO Instead of stopping, send several messages at once to keep line utilized e.g., if window size is four: This is better! But how big would the window need to be to really use the line effectively? Maybe: enough to keep the entire pipe full… if a=4, window size should be 8? GO We’ll see how go-back-N and selective repeat apply the basic idea of pipelining to increase throughput!

16. 15  Continue with Kurose and Ross slides at the performance of rdt3.0 slides