Download CSE-555 Protocol Engineering

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