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

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 receivers input buffer
• Synchronization problem
• Never make assumptions about relative speeds of
  concurrent processes

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

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)

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

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)

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

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

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

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
• Senders credit varies between 0 and W
• Sender delayed only when credit 0

13
Window Protocol (Contd)

• 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

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

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.

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)

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

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

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

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

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
  senders credit
• Range of seq s should be larger than max credit
  to allow receiver to distinguish duplicate
  messages
• Implemented in sliding window protocols

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 busys true if ack for
  seq s is awaited
• Initially all elements are set equal to true
• Array stores 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 unacked messages
• n the seq of the oldest unacked message
• m the seq of the last acked message

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
  gt 0

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
• recvdm keeps track of status of last received
  messages
• Accept process
• Uses sequence s to restore order
• Acks message

25
Identification of Duplicates

• recvdm can help detect duplicates at receiver
• recvdm is a Boolean array that remembers the
  seq s of messages received, but not yet accepted
• bufferm 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
• recvdm true
• Other for message that can no longer be received
  (outside current window)
• recvd(m-WM)M recvd(m-W)M false
• Duplicate message is recognized by an already set
  recvd flag to true

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 didnt reach sender
• Ack should be repeated
• p helps decide which case apply
• valid (m) (0 lt p - m W) ll (0 lt p M - m
  W)

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 gt 2 W -1)
• Protocol still works correctly

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

29
Extended Alternating Bit Protocol Sender

• NAK needs no sequence number

30
Extended Alternating Bit Protocol Receiver
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)

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 senders request

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 MltS
• 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

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

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)

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)

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