Flow Control

Document Sample
Flow Control Powered By Docstoc
					Chapter 11: Flow Control – can occur at layer
2 (data link) and at layer 4 (transport)
   You saw the need in the most recent assignment.
   Data packets can be damaged, but it’s not only data
    that can be changed.
   If the sequence number is changed how do you know
    what packet was damaged?
   What if the acknowledgment is damaged?
   What if a data packet is lost?
   What if an acknowledgment is lost?
   How many data packets can we acknowledge with
    one acknowledgment packet?
   Book does some calculation of bit rates; you can
    skip that stuff. We’ll focus on the protocols.
   Main thing is that the download speed is a function
    of not only the raw bit rate, but the flow control
    protocol used.
   Recall the layering of protocols
       Frame – layer 2 unit of transmission
       Packet – layer 3 unit of transmission
       Text uses layer 2 context for flow control, but it
        does occur at layer 4 (TCP) as well
Figure 2.4 An exchange using the OSI model




 2.4
   Byte oriented
       Frame interpreted as a sequence of bytes
       Each byte means something
       Old protocol typical of transferring text files
       Flags (e.g. 01111110) delimit start and end of
        frame
   What if flag was part of the data (non-text files)?
   Bit oriented
       More typical of streaming, binary files, graphics,
        etc
       Frame interpreted as a bit stream
       Start and end of frame marked with a
        flag=01111110
   Again, what if flag is part of the data?
   Stuff a bogus 0 after 5 consecutive 1s.
Flow control


Flow control refers to a set of procedures used to restrict the amount of data
                       that the sender can send before
                         waiting for acknowledgment.
Figure 11.5 Taxonomy of protocols discussed in this chapter




 11.10
Acronyms
   ARQ – Automatic Repeat reQuest
   ACK – acknowledgment
   NAK – negative acknowledgment (indicates a
    problem with a frame – damaged or never arrived)
Figure 11.6 The design of the simplest protocol with no flow or error control




       Has similarities to a streaming protocol
     11.12
Algorithm 11.1 Sender-site algorithm for the simplest protocol




 11.13
Algorithm 11.2 Receiver-site algorithm for the simplest protocol




 11.14
Figure 11.7 Flow diagram for Example 11.1




 11.15
   No mechanism for error control or acknowledgments
Figure 11.8 Design of Stop-and-Wait Protocol




 11.17
Algorithm 11.3 Sender-site algorithm for Stop-and-Wait Protocol




 11.18
Algorithm 11.4 Receiver-site algorithm for Stop-and-Wait Protocol




 11.19
Figure 11.9 Flow diagram for Example 11.2




 11.20
   Assumes no errors in frames
   Assumes frames are not lost
   Assumes Acks are not lost
   Each frame has a sequence number
   Sequence nos range from 0 to 2m-1, where m is the
    number of bits used to represent the sequence
    number
   If m=3, sequence nos are as follows
                0,….7, 0,….7, 0,….7, etc
   ARQ: adds simple error control
   Distinguish Ack frames from NAK frames
   Implement a timer if neither of the above does not
    arrive in timely fashion
Figure 11.10 Design of the Stop-and-Wait ARQ Protocol




 11.24
Algorithm 11.5 Sender-site algorithm for Stop-and-Wait ARQ




                                                             (continued)
 11.25
                                                             (continued)
Algorithm 11.5 Sender-site algorithm for Stop-and-Wait ARQ




       Option: If a NAK frame arrives, proceed as in the
        timeout

11.26
Algorithm 11.6 Receiver-site algorithm for Stop-and-Wait ARQ Protocol




        Option: Do an error check and send either an Ack or
         NAK frame
 11.27
Figure 11.11 Flow diagram for Example 11.3




 11.28
   What if an ack is not lost but just delayed past when
    the timer expires?

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:3/22/2013
language:Unknown
pages:29