Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed (KFUPM) Spring 2004 (Term 032) Flow Control 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 Term 032 2-3-3 CSE555-Sqalli 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 Term 032 2-3-4 CSE555-Sqalli 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 Term 032 2-3-5 CSE555-Sqalli 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) Term 032 2-3-6 CSE555-Sqalli 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 Term 032 2-3-7 CSE555-Sqalli 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) Term 032 2-3-8 CSE555-Sqalli 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 Term 032 2-3-9 CSE555-Sqalli 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 Term 032 2-3-10 CSE555-Sqalli 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 Term 032 2-3-11 CSE555-Sqalli 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 Term 032 2-3-12 CSE555-Sqalli 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 Term 032 2-3-13 CSE555-Sqalli 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): Term 032 2-3-14 CSE555-Sqalli 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…. Term 032 2-3-15 CSE555-Sqalli 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) Term 032 2-3-16 CSE555-Sqalli 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 Term 032 2-3-17 CSE555-Sqalli 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 Term 032 2-3-18 CSE555-Sqalli 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 Term 032 2-3-19 CSE555-Sqalli 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 Term 032 2-3-20 CSE555-Sqalli 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 Term 032 2-3-21 CSE555-Sqalli 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: Term 032 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 CSE555-Sqalli 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 Term 032 2-3-23 CSE555-Sqalli 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 Term 032 2-3-24 CSE555-Sqalli 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 Term 032 2-3-25 CSE555-Sqalli 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) Term 032 2-3-26 CSE555-Sqalli 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 Term 032 2-3-27 CSE555-Sqalli 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 Term 032 2-3-28 CSE555-Sqalli Extended Alternating Bit Protocol: Sender NAK needs no sequence number Term 032 2-3-29 CSE555-Sqalli Extended Alternating Bit Protocol: Receiver Term 032 2-3-30 CSE555-Sqalli 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 Term 032 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 CSE555-Sqalli 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 Term 032 2-3-32 CSE555-Sqalli 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 Term 032 2-3-33 CSE555-Sqalli 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 Term 032 2-3-34 CSE555-Sqalli 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) Term 032 2-3-35 CSE555-Sqalli 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) Term 032 2-3-36 CSE555-Sqalli 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 Term 032 2-3-37 CSE555-Sqalli