33
Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. Controlling Flow Last Update 2008.03.04 1.0.0 1

Embed Size (px)

Citation preview

Page 1: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Controlling FlowLast Update 2008.03.04

1.0.0

1

Page 2: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Objectives

• Learn how data flows are controlled in networks

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com 2

Page 3: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Flow Control

• Flow control typically occurs at the transport layer

• However, there are three methods of flow control seen at the data link layer– X-On/X-Off– Stop and Wait– Sliding Window

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com 3

Page 4: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

X-On/X-Off

• X-On/X-Off is a simple memory buffer based method

• The receiving device allows data to be placed into the memory space allocated to the receiving buffer

• Once this space is full it says stop• When space is available in the buffer it

says start

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com 4

Page 5: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Stop and Wait

• In Stop and Wait it is even more basic• The sending NIC sends a frame• Once the receiving NIC has processed the

frame it issues an ACK• The sending frame then sends the next

frame• And so on• This method is real slow

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com 5

Page 6: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Sliding Window

• Waiting for an acknowledgement for each packet is not very efficient

• To improve efficiency a sliding window or burst mode was developed

• The sliding window acknowledgement method allows multiple packets to be sent without waiting for an acknowledgement for the first to arrive

• Let’s see what this looks likeCopyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com 6

Page 7: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Sliding Window

Packets sent and

acknowledged

Current WindowPackets sent at

one time

Packets waiting to be sent

1 2 3 4 5 6 7 8

Packets sent and

acknowledged

Current WindowPackets sent at

one time

Packets waiting to be sent

7

Page 8: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Sliding Window

• The window slides one group to the right

8

Page 9: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Sliding Window

Packets sent and acknowledged Current WindowPackets sent at

one time

Packets waiting to be sent

1 2 3 4 5 6 7 8

Packets sent and acknowledged Current WindowPackets sent at

one time

Packets waiting to be sent

9

Page 10: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Sliding Window

• In the sliding window method all packets fall into one of three sets– Those to the left of the window that have been

sent, received, and acknowledged– Those in the window that are being sent– Those to the right of the window not yet sent

• The lowest number, the one at the left edge of the window, is the first packet that has yet to be acknowledged

10

Page 11: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Sliding Window

• When sending a packet a station includes in the TCP header the current size of its receive window

• This means that the sender can send that many bytes without stopping and waiting for an ACK

11

Page 12: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Sliding Window

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com 12

Page 13: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Flow Control

• To enhance efficiency further and to prevent overloading a host each acknowledgement of the number of bytes received also contains a window advertisement that specifies how many bytes the receiver is prepared to accept at that point in time

• Typical values are 8,192 and 24,000 bytes• In most cases 8,192 is used

13

Page 14: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Flow Control

• Some servers will advertise a window of 24,000 bytes

• In response to an increased window size advertisement the sender speeds up or increases the size of the window

• Each time an acknowledgement message is received, the window size is doubled

14

Page 15: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Flow Control

• In response to a decreased window size advertisement the sender slows down or decreases the size of the window

• If packet loss occurs, the sender cuts the window size back to half

• In case of a total connection collapse, the sender resumes the connection with a small window size

15

Page 16: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Flow Control

• Thus the stream is throttled just as a car on the freeway is– During rush hour, it must slow– During the middle of the day, it can speed up

16

Page 17: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Response to Congestion

• Since the endpoints cannot account for the congestion that may be encountered outside of their areas of control such as router problems

• They assume that the packets have been lost or damaged and just resend them

• Which leads to more and more congestion

17

Page 18: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Response to Congestion

• TCP then needs to respond to the ICMP source quench packets that routers send out when congestion occurs

• They do this through– Multiplicative Decrease

• This says upon loss of a segment reduce the congestion window by half

• and• For those segments that remain in the window,

backoff the retransmission timer exponentially18

Page 19: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Response to Congestion

– Slow Start• This is used to prevent oscillation back and forth• It says start with a single segment then increase

the window one segment each time an acknowledgment is received

– Congestion Avoidance• Once the congestion windows reaches one-half of

its original size before congestion, TCP then increases the congestion window by 1 only if all segments in the window have been acknowledged

19

Page 20: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Silly Window Syndrome

• But too much speed adjustment can produce oscillation in the window size called silly window syndrome

• A solution for the problem that occurs when the sending and receiving applications operate at greatly different speeds

20

Page 21: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Silly Window Syndrome

• This resulted in each acknowledgement advertising a small window and each segment carrying a small amount of data

• This is solved by the Nagle algorithm

21

Page 22: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Silly Window Syndrome

– On the receiving side• Before sending an updated window advertisement

after advertising a zero window, wait for space to become available that is either at least 50% of the buffer size or equal to the maximum segment size

– On the sending side• Do not send data until there is sufficient data to fill

a maximum sized segment• If still waiting to send when an acknowledgement

arrives, send anyway• Ignore pushes during this time

22

Page 23: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

• Below is a nice summary of this process from a Network World newsletter by Steve Taylor and Jim Metzler from July 2005– Last time, we discussed the fact that TCP has

a flow control mechanism for each connection– The mechanism is based on a field in the

segment header called the "Advertised Window“

– The Advertised Window specifies how many additional bytes of data the receiver can accept

23

Page 24: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– The goal of congestion control is to ensure that the sending device does not transmit more data than the network can accommodate

– To achieve this goal, the TCP congestion control mechanisms are based on a parameter referred to as the "Congestion Window“

24

Page 25: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– Determining the optimum value for the Congestion Window is somewhat tricky, particularly because network congestion changes over time

– In order to ensure smooth end-to-end performance, TCP defines a parameter that is referred to as "Max Window“

– It is helpful to think of Max Window as being an upper limit on the number of bytes that the sender could transmit at any point in time

25

Page 26: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– In order to ensure that the sending device does not send more data than the network and the receiving device can accommodate, Max Window is defined to be the lesser of Advertised Window and Congestion Window

– However, data is continually being transmitted from the sending device to the receiving device and acknowledged by the receiving device

26

Page 27: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– To account for this, TCP defines a parameter called Effective Window

– Effective Window is equal to Max Window minus the number of bytes that have been sent, but not acknowledged

– The next newsletter will describe some techniques that are used to compute the Congestion Window

27

Page 28: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– Last time, we discussed how TCP combines a flow control parameter (Advertised Window) and a congestion control parameter (Congestion Window) to determine how many bytes the sending device can transmit (Effective Window)

– We also mentioned that determining the optimum value for the Congestion Window is somewhat tricky because network congestion changes over time

28

Page 29: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– TCP has multiple mechanisms to determine Congestion Window and today, we'll describe one of those called Additive Increase/Multiplicative Decrease (AI/MD)

– AI/MD is typically used when the sending device is operating close to the available capacity of the network

29

Page 30: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– The basic assumption made by AI/MD is that if the sender does not receive an acknowledgement of a sent packet, the packet was dropped by the network due to congestion

– Hence, when faced with a timeout, AI/MD assumes there is network congestion and cuts Congestion Window in half

– Subsequent timeouts result in additional halving of Congestion Window, which leads to the phrase "Multiplicative Decrease"

30

Page 31: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– While AI/MD decreases Congestion Window rapidly, it increases Congestion Window slowly

– Every time that the source is successful in sending a Congestion Window's worth of packets, it adds the equivalent of one packet to Congestion Window

– Analysis of TCP throughput demonstrates that this slow increase and rapid decrease in Congestion Window results in throughput that resembles a saw tooth

31

Page 32: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Copyright 2008 Kenneth M. Chipps Ph.D. www.chipps.com

Summary of Congestion Control

– This analysis also demonstrates that network throughput can be significantly impacted by packet loss

– Future newsletters will examine some of the techniques that are used to overcome the performance limitations of TCP

32

Page 33: Copyright 2008 Kenneth M. Chipps Ph.D.  Controlling Flow Last Update 2008.03.04 1.0.0 1

Lab

• Do lab from eCollege

Copyright 2008-2009 Kenneth M. Chipps Ph.D. www.chipps.com

33