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 App Trans Net

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

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.

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

5 segment message segment Protocol 2 Timeline AppTransNetTransApp segment message segment segment segment message segment segment message segment message GO GO (wait)

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

7 Timeline of protocol 3 retransmission AppTransNetTransApp segment message segment segment message segment segment message segment message GO start_timer timeout start_timer

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

9 Fix by adding sequence numbers to segments AppTransNetTransApp segment message 1 message 2 GO start_timer timeout trans sees that seq number is same as previous, and doesn’t deliver duplicate 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

10 Timeout might be premature NetDllPhyDllNet segment message 7 message 8 GO start premature timeout segment segment message segment 1 message segment 1 message segment 1 message segment 1 message segment 0GO message 9 segment message segment 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 GO message 10 segment message segment 0 start segment message segment 0 message 10

11 Fix by adding seq numbers to acks AppTransNetTransApp segment message 7 message 8 GO start premature timeout segment segment message segment 1 message segment 1 message segment 1 message segment 1 message segment 0 message segment 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

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...)

13 t0t0 t t 0 + a t a t a t0t0 t 0 + a t t a t a  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

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!

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