computer networks n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Computer Networks PowerPoint Presentation
Download Presentation
Computer Networks

Loading in 2 Seconds...

play fullscreen
1 / 50

Computer Networks - PowerPoint PPT Presentation


  • 94 Views
  • Uploaded on

Computer Networks. Lecture 17 Congestion Control; AIMD; TCP Reno 10/31/2013. Admin.: Assignment 4. Part 1: Design discussion with instructor or a TF: Nov. 11; Code check point: 11:55 pm, Nov. 15 Part 2: Design discussion with instructor or a TF: Nov. 14; Code and report: 11:55 pm, Nov. 19.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Computer Networks' - urban


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
computer networks

Computer Networks

Lecture 17

Congestion Control; AIMD; TCP Reno

10/31/2013

admin assignment 4
Admin.: Assignment 4

Part 1: Design discussion with instructor or a TF: Nov. 11; Code check point: 11:55 pm, Nov. 15

Part 2: Design discussion with instructor or a TF: Nov. 14; Code and report: 11:55 pm, Nov. 19.

proj-sol (part 1):

129 400 3045 FishThread.java

388 1457 12873 Node.java

51 167 1145 PingRequest.java

83 250 2106 SimpleTCPSockSpace.java

181 605 5248 TCPManager.java

889 3088 26381 TCPSock.java

60 149 1316 TCPSockID.java

123 382 3866 TransferClient.java

147 500 5059 TransferServer.java

2051 6998 61039 total

proj:

129 400 3045 FishThread.java

341 1301 11313 Node.java

51 167 1145 PingRequest.java

50 128 909 TCPManager.java

132 460 3146 TCPSock.java

123 382 3866 TransferClient.java

147 500 5059 TransferServer.java

973 3338 28483 total

recap connection management
Recap: Connection Management
  • Connection setup:
    • agree on initial sequence numbers to avoid accepting duplicate/out of order packets
    • Internet solution: Three-Way-Handshake (TWH)
  • Connection close
    • both sides can release allocated resources
    • Internet solution: time wait
slide4

CLOSED

SYN SENT

SYN

ESTABLSIHED

ACK

SYN/ACK

FIN

ACK

%netstat -t -a

CLOSED

LISTEN

SYN RCVD

ESTABLSIHED

ESTABLSIHED

ESTABLSIHED

FINWAIT 1

FIN

CLOSEWAIT

LASTACK

FINWAIT 2

TIMEWAIT

ACK

slide5

A Summary of Questions

  • How to improve the performance of rdt3.0?
    • sliding window protocols
  • What if there are duplication and reordering?
    • network guarantee: max packet life time
    • transport guarantee: sender not reuses a seq# before life time
    • seq# management and connection management
  • How to determine the “right” parameters?
slide6

History

  • Key parameters for TCP in mid-1980s
    • fixed window size W
    • timeout value = 2 RTT
  • Network collapse in the mid-1980s
    • UCB  LBL throughput dropped by 1000X !
    • Blamed timeout and fixed window size
timeout
Ideal timeout = RTT

too short: premature timeout

unnecessary retransmissions/duplicates

too long: slow reaction to segment loss

Measure RTT: measuretime from segment transmission until ACK receipt

Timeout
from ideal to implementation
From Ideal to Implementation
  • Problem: SampleRTTvary, want a “smoother”estimated RTT
    • use several recent measurements, not just current SampleRTT

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

  • Exponential weighted moving average
  • influence of past sample decreases exponentially fast
  • typical value:  = 0.125
setting timeout
Problem:

using the average of SampleRTT will generate many timeouts due to network variations

Solution:

EstimtedRTT plus “safety margin”

Q: what is margin in original TCP

Margin should depend on variation: large variation in EstimatedRTT -> larger safety margin

RTT

Setting Timeout
tcp timeout

freq.

RTT

TCP Timeout

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|

(typically,  = 0.25)

Then set timeout interval:

TimeoutInterval = EstimatedRTT + 4*DevRTT

slide12

A Summary of Questions

  • How to improve the performance of rdt3.0?
    • sliding window protocols
  • What if there are duplication and reordering?
    • network guarantee: max packet life time
    • transport guarantee: sender not reuses a seq# before life time
    • seq# management and connection management
  • How to determine the “right” parameters?
    • timeout: mean + variation
    • sliding window size
principles of congestion control
Big picture:

How to determine a flow’s sending rate?

a top-10 problem!

Congestion:

informally: “too many sources sending too much data too fast for the network to handle”

different from flow control !

manifestations:

lost packets (buffer overflow at routers)

long delays (queueing in router buffers)

wasted bandwidth

Principles of Congestion Control
slide14

Some General Questions

  • How can congestion happen?
  • What is congestion control?
  • Why is congestion control difficult?
slide15

Cause/Cost of Congestion: Single Bottleneck

flow 1

5 Mbps

20 Mbps

10 Mbps

20 Mbps

flow 2 (5 Mbps)

20 Mbps

router 1

router 2

  • - Flow 2 has a fixed sending rate of 5 Mbps
  • - We vary the sending rate of flow 1 from 0 to 20 Mbps
  • - Assume
    • no retransmission; link from router 1 to router 2 has infinite buffer

delay at central link

throughput: e2e packets delivered in unit time

Delay?

throughput of flow 1 & 2 (Mbps)

sending rate by flow 1 (Mbps)

10

5

0

sending rate by flow 1 (Mbps)

5

5

0

slide16

Cause/Cost of Congestion: Single Bottleneck

router 5

router 3

flow 1

5 Mbps

20 Mbps

10 Mbps

20 Mbps

flow 2 (5 Mbps)

20 Mbps

router 2

router 1

router 4

router 6

  • Assume
    • no retransmission
    • the link from router 1 to router 2 has finite buffer
    • throughput: e2e packets delivered in unit time
  • Zombie packet: a packet dropped at the link from router 2 to router 5; the upstream transmission from router 1 to router 2 used for that packet was wasted!

throughput of flow 1 & 2 (Mbps)

10

sending rate by flow 1 (Mbps)

5

x

5

0

slide17

packet

loss

knee

cliff

Throughput

congestion

collapse

Load

Delay

Load

Summary: The Cost of Congestion

Cost

  • Packet loss
    • wasted upstream bandwidth when a pkt is discarded at downstream
    • wasted bandwidth due to retransmission (a pkt goes through a link multiple times)
  • High delay
slide18

Outline

  • Admin and recap
  • Transport congestion control
    • what is congestion
    • congestion control
slide19

Rate-based vs. Window-based

Rate-based:

  • Congestion control by explicitly controlling the sending rate of a flow, e.g., set sending rate to 128Kbps
  • Example: ATM

Window-based:

  • Congestion control by controlling the window size of a transport scheme, e.g., set window size to 64KBytes
  • Example: TCP

Discussion: rate-based vs. window-based

slide20

Window-based Congestion Control

  • A main advantage of window-based congestion control is self-clocking: considers flow conservation, andadjusts to RTT variation automatically
slide21

cwnd * MSS

throughput 

Bytes/sec

RTT

Sliding Window Congestion Control

  • Transmission rate limited by congestion window size, cwnd, over segments:

cwnd

  • Assume cwnd segments, each with MSS bytes sent in one RTT:

MSS: Minimum Segment Size

slide22

The Desired Properties of a Congestion Control Scheme

  • Efficiency: close to full utilization but low delay
    • fast convergence after disturbance
  • Fairness (resource sharing)
  • Distributedness (no central knowledge for scalability)
a simple model
A Simple Model

User 1

x1

d =  xi > Xgoal?

x2

User 2

xn

User n

Flows observe congestion signal d, and locally take actions to adjust rates.

slide24

Linear Control

  • Proposed by Chiu and Jain (1988)
  • The simplest control strategy

Discussion: values of the parameters?

slide25

fairness line: x1=x2

x(0)

efficiency line: x1+x2=C

State Space of Two Flows

x2

overload

underload

x1

slide26

x0

efficiency: distributed linear rule

x0

x0

fairness

intersection

congestion

x0

efficiency

implication congestion overload case
Implication: Congestion (overload) Case
  • In order to get closer to efficiency and fairness after each update, decreasing of rate must be multiplicative decrease (MD)
    • aD = 0
    • bD < 1
slide28

no-congestion

x0

efficiency: distributed linear rule

x0

x0

fairness

convergence

x0

efficiency

implication no congestion case
Implication: No Congestion Case
  • In order to get closer to efficiency and fairness after each update, additive and multiplicative increasing (AMI), i.e.,
    • aI > 0, bI > 1
  • Simply additive increase gives better improvement in fairness (i.e., getting closer to the fairness line)
  • Multiplicative increase is faster
slide30

Four Special Cases

Discussion: state transition trace.

slide31

fairness line:x1=x2

overload

efficiency line: x1+x2=C

underload

AIMD: State Transition Trace

x2

x0

x1

another look
Another Look
  • Consider the difference or ratio of the rates of two flows
    • AIAD
    • MIMD
    • MIAD
    • AIMD
mapping a m i md to protocol
Mapping A(M)I-MD to Protocol
  • What do we need to apply the A(M)I-MD algorithm to a sliding window protocol?
mapping a m i md to protocol1
Mapping A(M)I-MD to Protocol
  • What do we need to apply the A(M)I-MD algorithm to a sliding window protocol?
implicit vs explicit
Implicit:

congestion inferred by end systems through observed loss, delay

Explicit:

routers provide feedback to end systems

explicit rate sender should send at

single bit indicating congestion (SNA, DECbit, TCP ECN, ATM)

Implicit vs. Explicit
slide36

Outline

  • Admin and recap
  • Transport congestion control
    • what is congestion
    • congestion control principle
    • TCP congestion control: Reno
slide37

TCP Congestion Control

  • Closed-loop, end-to-end, window-based congestion control
  • Designed by Van Jacobson in late 1980s, based on the AIMD alg. of Dah-Ming Chu and Raj Jain
  • Works well when the bandwidth of the Internet has increased by more than 200,000 times
  • Many versions
    • TCP/Tahoe: this is a less optimized version
    • TCP/Reno: many OSs today implement Reno type congestion control
    • TCP/Vegas: not currently used
    • TCP CUBIC

For more details: see TCP/IP illustrated; or readhttp://lxr.linux.no/source/net/ipv4/tcp_input.c for linux implementation

slide38

TCP/Reno Congestion Detection

  • Detect congestion (d) in two cases and react differently:
    • 3 dup ACKs
    • timeout event

Philosophy:

  • 3 dup ACKs indicates network capable of delivering some segments
  • timeout is “more alarming”
slide39

Basic Structure

  • Two “phases”
    • slow-start: MI
    • congestion avoidance: AIMD
  • Important variables:
    • cwnd: congestion window size
    • ssthresh: threshold between the slow-start phase and the congestion avoidance phase
slide41

Slow Start: MI

  • What is the goal?
    • getting to equilibrium gradually but quickly
  • Implements the MI algorithm
    • doublecwnd every RTT until network congested get a rough estimate of the optimal of cwnd
slide42

segment 1

cwnd = 1

ACK for segment 1

segment 2

segment 3

ACK for segments 2 + 3

segment 4

segment 5

segment 6

segment 7

Slow-start

Initially:

cwnd = 1;

ssthresh = infinite (e.g., 64K);

For each newly ACKed segment:

if (cwnd < ssthresh)

/* slow start*/

cwnd = cwnd + 1;

cwnd = 2

cwnd = 4

cwnd = 6

cwnd = 8

tcp reno congestion avoidance
TCP/Reno Congestion Avoidance
  • Maintains equilibrium and reacts around equilibrium
  • Implements the AIMD algorithm
    • increases window by 1 per round-trip time (how?)
    • cuts window size
      • to half when detecting congestion by 3DUP
      • to 1 if timeout
      • if already timeout, doubles timeout
slide45

TCP/Reno Congestion Avoidance

Initially:

cwnd = 1;

ssthresh = infinite (e.g., 64K);

For each newly ACKed segment:

if (cwnd < ssthresh)

/* slow start*/

cwnd = cwnd + 1;

else

/* congestion avoidance; cwnd increases (approx.) by 1 per RTT */ cwnd += 1/cwnd;

Triple-duplicate ACKs:

/* multiplicative decrease */

cwnd = ssthresh = cwnd/2;

Timeout:

ssthresh = cwnd/2;

cwnd = 1;

(if already timed out, double timeout value; this is called exponential backoff)

slide46

TCP/Reno: Big Picture

cwnd

TD

TD

TD

TO

ssthresh

ssthresh

ssthresh

ssthresh

Time

congestion

avoidance

slow

start

congestion

avoidance

congestion

avoidance

slow

start

congestion

avoidance

TD: Triple duplicate acknowledgements

TO: Timeout

a session
A Session

Question: when cwnd is cut to half, why sending rate is not?

high level idea
High-level Idea

Ideally, we set timeout = RTT, but RTT is not a fixed value (why?)

Set timeout = average + safe margin

high level idea1
High-level Idea

Ideally, we set timeout = RTT, but RTT is not a fixed value (why?)

Set timeout = average + safe margin