CSE 555 Protocol Engineering

1. CSE 555Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed (KFUPM) Spring 2004 (Term 032)

2. Flow Control

3. Why Flow Control • Two goals: • Synchronization • Congestion avoidance • Specifically: • To avoid swamping the receiver (i.e., data not sent faster than can be processed) • To optimize channel utilization (sending data too slowly is wasteful) • To avoid congesting transmission links (sending data too fast can cause congestion) • It is possible to design a transmission protocol without flow control • Consider following example 2-3-3

4. Example: No Flow Control • Protocol work reliably when receiver is faster than sender • Receiver is usually slower • Many more tasks than sender process • If assumption of fast receiver is false, sender can overflow receiver’s input buffer • Synchronization problem • Never make assumptions about relative speeds of concurrent processes 2-3-4

5. X-on/X-off Flow Control • This is the oldest and least reliable flow control scheme • However, it addresses the synchronization problem • Requires no prior negotiations between sender and receiver • Two control messages are used: • Suspend (X-off); and • Resume (X-on) • Assume error-free channel and a protocol vocabulary of: • V = {mesg, suspend, resume} • Procedure rules: • Implemented by two additional processes, one in the sender and other in the receiver 2-3-5

6. X-on/X-off Protocol: Sender Processes • Toggle process sets the value of state to wait on receiving suspend message • Sender process simply waits until the state becomes “go” (i.e., arrival of a resume message in the toggle process) 2-3-6

7. X-on/X-off Protocol: Receiver Processes • Counter process increments a variable n when message arrives • Passes message to receiver/acceptor process through internal buffer • Receiver decrements n after accepting the data message • If number of messages waiting to be accepted is: • More than a limit (i.e., max), counter process sends a suspend message to sender process • Less than a limit (i.e., min), receiver/acceptor process sends a resume message to sender process 2-3-7

8. Problems with X-on/X-off • Correct working of protocol depends on the properties of transmission channel • Suspend message lost or delayed overflow problem • Correct working of a protocol should not depend on the time it takes a control message to reach the receiver • Resume message lost  deadlock for all 4 processes • Problems to be solved: • Protect against overrun errors more reliably • Protect against message loss • Overrun problem can be solved by having sender explicitly wait for the acknowledgment • Ping-Pong protocol (i.e., stop and wait protocol) 2-3-8

9. Ping-Pong Protocol • Overrun problem is solved • System still deadlocks if either a control or a data message is lost • How to solve deadlock problem? • Formulate the problem differently using the concept of a window 2-3-9

10. Deadlock Problem • Round trip delay at sender = 2t + a – p • t: message propagation time on the channel • a: time it takes the receiver to process and accept an incoming message • p: time it takes the sender to prepare a message for transmission • Acknowledgement message signifies: • Arrival of last message (acknowledgement) • Receiver extends to the sender to transmit the next message, i.e., available buffer space (window) • This directly lead to the solution of deadlock/delay problem: • The Window Protocol 2-3-10

11. Window Protocols • At call setup time, receiver can tell the sender how much buffer space it has reserved for incoming messages • Initial credit is W messages • For each message sent, the sender decrements its credit • For each message received, the receiver sends an ack message, and extends a new credit to the sender • Relation between used and unused credit • # of credit messages received by sender at time t = a(t) • # of messages sent by the sender to receiver at time t = m(t) • Value of n at time t = n(t) • Maximum # of messages that the sender can have outstanding, waiting acknowledgment, is: = W-n(t) + m(t)-a(t) = unused credit + used credit • W-n(t) + m(t)-a(t) ≤ W  m(t) – a(t) ≤ n(t) • Both sender and receiver update this inequality • Sender increments both sides, right side first • Receiver decrements both sides, left side first 2-3-11

12. Window Protocol for an Ideal Channel • Provides flow control for channels with long transit delays • Enables sender to send multiple messages while waiting for acks • Sender’s credit varies between 0 and W • Sender delayed only when credit = 0 2-3-12

13. Window Protocol (Cont’d) • This protocol still does not solve the deadlock problem • Receiver overrun problem is solved • Advantage over Ping-Pong: higher throughput with lower latency • Deadlock problem: a set of acks can get lost • Sender hangs waiting for ack • Receiver hangs waiting for messages it credited • Solution: use of timeout 2-3-13

14. Timeouts • Sender keeps track of the time to protect against lost messages • How long is too long? • Sender can try to predict worst case RTT (for acks) • No ack to sender until RTT  message is lost  timeout • Calculation of worst turn-around time: • Using a heuristic: • N is usually 1 and rarely larger than 2 • Average and variance of round-trip delay T are used • Receiver can be modeled as an M/M/1 queuing system • var(T) = [mean(T)]2 ; thus • Worst case RTT (with N=1): 2-3-14

15. Ping Pong Protocol with Timeouts • Common mistake • Both sender and receiver use timeouts • Problem: • Sender can match wrong ack with retransmitted message • Consider an example…. 2-3-15

16. Time Sequence Diagram of the Error • Deletion error • Sender retransmits message after timeout • Receiver retransmits previous ack after timeout • Problems: • Mismatched ack for retransmitted message • This will continue to happen indefinitely • What is wrong? • Only one of sender or receiver should timeout & retransmit • Need sequence numbers (to solve mismatch problem) 2-3-16

17. Sequence Numbers • Both messages and acks have sequence numbers • Solves problems of out-of-sequence messages • Solves duplication problems • Problem with sequence numbers: • Restricted range • How to “recycle” them without disturbing the protocol • Solution: • Use sequence numbers in combination with a window protocol • Window protocol + sequence numbers  sliding window protocol • Consider the example of the alternating bit protocol 2-3-17

18. Original Alternating Bit Protocol • Protocol defined with two finite state machines (6 states in each) • Total: 6x6 = 36 states • Two processes A and B • Edge labels specify message exchanges: sender + seq # • Sequence # was called alternation bit • Send actions are underlined • Double headed arrows  input/output states at receiver/sender • Messages with wrong seq #  retransmission of last message sent • Can be extended with timeouts to recover from lost messages 2-3-18

19. Alternating Bit Protocol with Timeouts • Two types of messages: • {mesg, data, seq #} • {ack, seq #} • Single bit variables: • a, e, r, s • s: last seq # sent • r: last seq # received • e: next # expected • a: last actual seq # received • All variables initialized to a value of 0 2-3-19

20. Time Sequence Diagram of an Error • Protocol recovers from the deletion errors • Sender times out and retransmits • What if ack is delayed • Delayed long enough to cause sender timeout and retransmission • Duplicate mesg from the sender • Duplicate ack from the receiver • This is duplication • Solution: • Use sequence # • Ignore duplicate mesg and ack 2-3-20

21. Message Reordering • Obvious solution to recover from reordered messages • Use a large seq # to encode original order of messages • With 16-bit seq #, we can number 65,536 subsequent messages • How long it takes the counter to wrap around? • Example: message length = 128 bits line speed = 9600 bps Counter can wrap around within 15 minutes • How to solve the wrap around problem? • Limit # of messages in transit by limiting sender’s credit • Range of seq #s should be larger than max credit to allow receiver to distinguish duplicate messages • Implemented in sliding window protocols 2-3-21

22. Implementation of Sliding Window Protocol • Assume M is the range of seq. #s and W is the initial credit • M is sufficiently larger than W to avoid confusion of recycled seq #s • Sender keeps two arrays for bookkeeping • Boolean array element busy[s] =true if ack for seq # s is awaited • Initially all elements are set equal to true • Array store[s] remembers the last message with seq # s transmitted • Other variables with initial values 0: • s: the seq # of the next message to send • window: the # of outstanding unack’ed messages • n: the seq # of the oldest unack’ed message • m: the seq # of the last ack’ed message 2-3-22

23. Sliding Window Protocol: Sender Process • Split the sender task into 3 subtasks: • Transmitting messages • Processing acks • Retransmitting unacknowledged messages after timeout • Messages are transmitted as long as credit limit > 0 2-3-23

24. Sliding Window Protocol: Receiver Process • Receiver process is split into 2 subtasks: • Receiver process • Accept process • Receiver process • Receive and stores messages in any order of arrival • recvd[m] keeps track of status of last received messages • Accept process • Uses sequence #s to restore order • Acks message 2-3-24

25. Identification of Duplicates • recvd[m] can help detect duplicates at receiver • recvd[m] is a Boolean array that remembers the seq #s of messages received, but not yet accepted • buffer[m] remembers the contents of those messages • Protocol progress variable p is the seq # of next message to be accepted • Initialized to zero • Two flags are set for a valid received message: • One for message just received: • recvd[m] = true • Other for message that can no longer be received (outside current window): • recvd[(m-W+M)%M] = recvd[(m-W)%M] = false • Duplicate message is recognized by an already set recvd flag to true 2-3-25

26. Identification of Duplicates (Cont.) • Two possible reasons for arrival of a duplicate message: • Message was received, but not yet acknowledged • Message was received and acknowledged, but the ack didn’t reach sender • Ack should be repeated • p helps decide which case apply • valid (m) = (0 < p - m ≤ W) ll (0 < p + M - m ≤ W) 2-3-26

27. Maximum Window Size • If all out-of-order messages were rejected by the receiver • Max window size = M-1 • If out-of-order message is received but seq # is not recycled before acknowledging the last message using it • Max window size = M/2 (because M > 2 W -1) • Protocol still works correctly 2-3-27

28. Negative Acknowledgements • Acks were used for flow control • What about error control • Messages can get lost or damaged • Sender eventually times out and retransmits • When probability of error is high • Sender will be idle most of the time • Low efficiency of the protocol • Solution: negative acknowledgements • Receiver sends negative ack when it detects errors • Sender immediately retransmits without waiting for time out • Time out is still needed to recover from lost messages • Example: extended alternating bit protocol 2-3-28

29. Extended Alternating Bit Protocol: Sender • NAK needs no sequence number 2-3-29

30. Extended Alternating Bit Protocol: Receiver 2-3-30

31. Automatic Repeat Request (ARQ) • Method of using acks to control retransmission is called ARQ method • Three variants of ARQ method • Stop-and-wait ARQ • Example: Ping-Pong protocol extended with NAK • Sender waits for positive or negative ack after each message sent • Selective repeat ARQ • Example: sliding window protocol with acks • Message is retransmitted if it triggers a NAK or a timeout, independent of any other outstanding message • Go-back-N continuous ARQ • Sender retransmits corrupted as well as all subsequent messages • Receiver design is simplified • Receiver refuses to accept out-of-order messages • Ack with seq # s acknowledges all messages up to and including s (cumulative ack) 2-3-31

32. Block Acknowledgement • It is a strategy to reduce the number of individual acknowledgement messages • Each positive ack specifies a range of seq #s for correctly received messages • Sent periodically or at sender’s request 2-3-32

33. Congestion Avoidance • Recall that flow control has two objectives: • Synchronization and • Congestion avoidance • Question: • For a given data link, how W and M are chosen? • Easy to set an upper limit on window size (W) beyond which the throughput does not improve if the channel is already fully saturated • Consider an example: • If a link capacity is S bps and a sender is fully using that capacity by transmitting S bps before waiting for ack • If there are M bits per transmitted message, the best window size is S/M • Assume M<S • A larger than S/M is wasteful • After transmitting last message, ack is expected • If ack does not arrive, it is probably time to retransmit • Problem: flow control problem is reduced to a link level-issue 2-3-33

34. Hop-by-Hop Vs. End-to-End Flow Control • Two ways to define flow control in above example: • Hop-by-hop • End-to-end • Hop-by-hop protocol: • Window size is calculated for each link • We can find window sizes that saturate each link • Problem: first link is 100 times faster than second • Data arrive at transfer point 100 times faster than it is forwarded • Messages will be lost • Even if no ack are sent by transfer point, sender will continue to saturate the channel including retransmissions • A flow control scheme that optimizes the utilization of: • Buffer space in network nodes; and • Bandwidth of links connecting the nodes 2-3-34

35. End-to-End Flow Control • Sender should send at a rate corresponding to slowest link in the end-to-end path • Requires feed back from various links • In end-to-end flow control, problem reduces to finding slowest path from sender to the receiver • Difficult to predict • Approximation: derive a maximum window size for the whole network based on its slowest link • Problem: what about dynamic conditions? • Heavily used fastest link might become the slowest! • Flow control is not a static problem • Message “loss” may be due to congestion in the network • Sender should be told to reduce the amount of traffic it offers to network (e.g., decrease its window size) 2-3-35

36. Dynamic Flow Control • Dynamic window flow control makes the protocol self-adapting (one principle of sound design) • Commonly used method: • Force a sender to reduce its window size whenever retransmission timeouts occur • When timeouts disappear, sender is allowed to gradually increase its window size back to its max value • Three ways to parameterize: • Decrease the window by 1 for every timeout and increase it by 1 for every positive ack • Decrease the window to ½ its current size for every timeout and increase by 1 for every N positive acks received • Decrease the window to its min value of 1 on a timeout, and increase the window by 1 for every N positive acks received • Maximum window size can be calculated as before or heuristically set (e.g., number of hops on the link between sender and receiver) 2-3-36

37. Rate Control • A different congestion avoidance philosophy: • Control the rate of traffic entering into the network during overload • Better than minimizing the damage after congestion starts • Such methods are called rate control methods • Ideally, throughput of the network increases linearly with load • Until it is fully saturated • Practically, near saturation, increased load results in degradation • Congestion is defined as: increase in traffic load decrease in throughput • Solution: control the network to operate below saturation 2-3-37