Presentation is loading. Please wait.

Presentation is loading. Please wait.

© Janice Regan, CMPT 128, 2007-2012 CMPT 371 Data Communications and Networking Flow Control 0.

Similar presentations


Presentation on theme: "© Janice Regan, CMPT 128, 2007-2012 CMPT 371 Data Communications and Networking Flow Control 0."— Presentation transcript:

1 © Janice Regan, CMPT 128, 2007-2012 CMPT 371 Data Communications and Networking Flow Control 0

2 Janice Regan © 2007-2012 1 Flow Control  Flow may be controlled because:  The receiving transport layer entity can not keep up and runs out of buffer space  The receiving application layer process can not accept data fast enough and data must remain in transport buffer for longer

3 Janice Regan © 2007-2012 2 Flow Control in Sliding Windows  Control Flow using one of the following approaches:  Conservative: send ACK only when buffer is available, to avoid buffer overflow  Optimistic: send ACK so next data will arrive when buffer is expected to be available. (data may be lost and require retransmission)  Credit mechanism: decouple ACK from control of sliding window buffer

4 Janice Regan © 2007-2012 3 Credit allocation mechanism  The choice of when to ACK a packet can be addressed by using a credit allocation mechanism which separates acknowledgement of receipt from moving the sliding window  Each ACK contains two values  One indicates the next packet expected  One indicates the amount the sliding window can be moved  An ACK can be sent immediately after receipt of a packet, the sliding window need not be moved at the same time.  When the receiver can handle additional data, an additional ACK can be sent to move the window

5 Janice Regan © 2007-2013 4 Sliding Window with credit allocation F0 F2 F3 F4 F5 ACK1Window5 ACK6Window6 ACK3Window4 F6 F7 5678 9 10111213514012341516 5678910 11 121314012341516 567891011121314012341516 5678910113121314012341516 567891011121314012341516 56789101112 13 14012341516 567891011312413514012341516 567891011121314012341516 F1 567891011121314012341516 567891011121314012341516 567891011121314012341516 567891011121314012341516 5678910111213140123415 16 567 8 91011121314012341516 567891011121314012341516 567891011121314012341516 567891011 12 1314012341516 ACK2Window5 ACK4Window3 ACK5Window5 5678910111213140123415716 ACK7Window6

6 TCP flow control  Uses a sliding window type algorithm that employs a credit allocation scheme  Each TCP packet uses a sequence number indicating the octet number of the first octet in the packet  Each TCP ACK is a cumulative ACK with a acknowledgment number indicating the next octet the receiver expects  TCP uses a credit control mechanism Janice Regan © 2007-2012 5

7 Janice Regan © Sept 2007-2012 6 Structure of a TCP packet ACKNOWLEDGEMENT NUMBER WINDOW 20 Variable length header: from 20 bytes (no options) to 60 bytes CODEBITS

8 TCP Header  The credit mechanism used for flow control in TCP uses the acknowledgement number to hold the number N sent back to indicate the ACKN  The ACK flag in the code bits is sent to indicate the packet is an ACK  The window field is used to carry the information about how much space is available in the receivers buffer at the present time Janice Regan © 2007-2012 7

9 Flow Control (From the TCP GUIDE)  http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFl owControl-2.htm#Figure_226 Janice Regan © 2007-2012 8

10 Flow Control (From the TCP GUIDE)  http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFl owControl-2.htm#Figure_226 Janice Regan © 2007-2012 9

11 Flow Control (From the TCP GUIDE)  http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFl owControl-2.htm#Figure_226 Janice Regan © 2007-2012 10

12 Managing the send window  Keep track of three quantities  LastByteAcked <=LastByteSent  LastByteSent <= LastByteWritten  bytes in range LastByteAcked to LastByteWritten must be buffered Janice Regan © 2007-2012 11 LastByteAcked LastByteSent LastByteWritten (by application)

13 Managing the receive window  Keep track of three quantities  LastByteRead < NextByteExpected  NextByteExpected <= LastByteRcvd + 1  bytes in range NextByteRead and LastByteReceived must be buffered. Janice Regan © 2007-2012 12 NextByteRead (by application) NextByteExpected LastByteReceived

14 Reopening a window  If the receiving machine is very busy and has reduced its send window is reduced to 0 the window is said to be closed.  In this case how do we reopen the sender’s window?  When the receiving machine is ready to accept more data it will send an ACK to the sender telling the sender to slide its window and begin transmitting again.  Sounds straightforward, but what if this ACK is lost Janice Regan © 2007-2012 13

15 Probe segments  When the window is closed the sender will periodically send a probe message to the server  The probe message will contain 0 or 1 byte of data  The probe message will prompt the server to send back an ACK containing the current window size Janice Regan © 2007-2012 14

16 Receiver reducing buffer size  Must be careful that the receiver actually reduces the size in a way that does not allow the sender to overrun the buffer.  Cannot reduce so that the window may be smaller that the sender expects  Must reduced the size of the buffer by sending fewer credits when allowing the sender to re- expand its window after the window is reduced by congestion Janice Regan © 2007-2012 15


Download ppt "© Janice Regan, CMPT 128, 2007-2012 CMPT 371 Data Communications and Networking Flow Control 0."

Similar presentations


Ads by Google