150 likes | 339 Views
App. App. segment. segment. segment. segment. segment. segment. segment. segment. message. message. message. message. message. message. message. message. message. Trans. message. message. message. message. Trans. Net. message. message. message. message. segment.
E N D
App App segment segment segment segment segment segment segment segment message message message message message message message message message Trans message message message message Trans Net message message message message segment segment segment segment message message message Net 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) Sender Receiver 1010101010101010010101010101010
if only all protocols could be so simple! The utopiaprotocol • void sender1(void) • { • while (true) • { • take some data from the application layer • stick a segment header on it • send it to the network layer • } • } • just inf. loops that copy data • kind, seq, ack fields not used • void receiver1(void) • { • while (true) • { • get one segment from the network layer • strip off the header • pass up the contents to the application layer • } • }
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: • Provide feedback from receiver to sendertelling it when to STOP or GO. GO maybe it should be called stop-and-go instead of stop-and-wait...
sender waits for message_arrival from receiver; essentially, the sender is waiting for an “ack” receiver is sending anacknowledgment segment to let the sender know its ok to proceed. GO 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 */ • } • }
App Trans Net Trans App message message message message segment segment segment segment segment segment message message message message Protocol 2 Timeline 011111101010101010101001111110 segment segment message segment (wait) 011111101010101010101001111110 GO 011111101010101010101001111110 (wait) segment 011111101010101010101001111110 GO
start_timer timeout 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 2with sender operating as follows: • send message • Allow for noise. • messages may be corrupted, or may be totally lost. • start timer, and wait for the acknowledgment • if timer expires first, resend message • if acknowledgment arrives first, send a new message.
App Trans Net Trans App message start_timer start_timer timeout message segment segment segment segment segment segment message message message message Timeline of protocol 3 retransmission 011111101010101 1010011010109 011111101010101010101001111110 segment 011111101010101010101001111110 GO
App Trans Net Trans App message 1 start_timer start_timer timeout message 1 message 1 segment segment segment segment segment segment segment segment message message message message message 2 Do we need numbers on messages? Yes... 011111101010101010101001111110 segment 0111111010101010 011111101010101010101001111110 segment oops!receiverdelivered a duplicate! 011111101010101010101001111110 GO
1 1 1 1 segment segment segment segment segment segment segment segment message message message message App Trans Net Trans App message 1 start_timer start_timer timeout message 1 message 2 Fix by adding sequence numbers to segments now expecting 1 011111101010101010101001111110 segment now expecting 0 0111111010101010 trans sees that seq number is same as previous, and doesn’t deliver duplicate still expecting 0 011111101010101010101001111110 segment 011111101010101010101001111110 GO
Net Dll Phy Dll Net 1 segment segment message start start start start start 1 message 7 premature timeout 1 segment segment message 0 1 1 0 message 10 message 7 0 1 segment segment segment segment segment segment segment segment segment segment segment segment segment segment message message message message message message message message 10 message 8 message 9 Timeout might be premature now expecting 1 011111101010101010101001111110 segment now expecting 0 01111110110101010101010101001111110 011111101010101010101001111110 still expecting 0 GO 011111101010101 misinterpreting ack of 1 as ack of 0 segment 01111110110101010101010101001111110 GO still expecting 0 011111101010101010101001111110 GO oops! skipped 8,9! 10110101010101010101001111110 011111101010101010101001111110
App Trans Net Trans App 1 segment segment message start start start start 1 message 7 premature timeout 1 segment segment message 1 0 message 7 message 8 0 0 segment segment segment segment segment segment segment segment segment segment message message message message message message 8 Fix by adding seq numbers to acks expecting 1 011111101010101010101001111110 1 segment expecting 0 expecting 0 receiver acks, but doesn’t deliver the duplicate 01111110110101010101010101001111110 011111101010101010101001111110 GO still expecting 0 011111101010101 1 segment sender looking for ack of 0, so doesn’t issue GO signalto net layer; instead retransmits 0. 01111110110101010101010101001 still expecting 0 successful recovery! 011111101010101010101001111110
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 theAlternating 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...)
Transmission time = 1propagation delay = a>1 Link always under utilized Transmission time = 1propagation delay = a < 1 Link still inefficiently utilized t0 t0 t0 + 1 t0 + a t0 + a t0 + 1 t0 + 1 + a t0 + 1 + a t0 + 1 + 2a t0 + 1 + 2a Link utilization with stop-and-wait (source: Stallings DCC5e, p.160ff)
App App Trans Trans Net Net Trans Trans App App “The pipelining principle” Main idea: if line holds more than one message,stop and wait underutilizes the link: 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 applythe basic idea of pipelining to increase throughput!
Continue with Kurose and Ross slides at the performance of rdt3.0 slides