TCP recap Three phases 1. Connection setup 2. Data transfer Flow - - PowerPoint PPT Presentation

▶
tcp recap
SMART_READER_LITE
LIVE PREVIEW

TCP recap Three phases 1. Connection setup 2. Data transfer Flow - - PowerPoint PPT Presentation

Apr 02, 2023 270 likes •847 views

TCP recap Three phases 1. Connection setup 2. Data transfer Flow control dont overwhelm the receiver ARQ one outstanding packet Go-back-N, selective repeat -- sliding window of W packets Tuning flow control (ack

slide-1
SLIDE 1

TCP recap

Three phases

  • 1. Connection setup
  • 2. Data transfer
  • Flow control – don’t overwhelm the receiver
  • ARQ – one outstanding packet
  • Go-back-N, selective repeat -- sliding window of W packets
  • Tuning flow control (ack clocking, RTT estimation)
  • Congestion control
  • 3. Connection release
slide-2
SLIDE 2

ACK Clocking

slide-3
SLIDE 3

Sliding Window ACK Clock

  • Typically, the sender does not know B or D
  • Each new ACK advances the sliding window and lets

a new segment enter the network

  • ACKs “clock” data segments

CSE 461 University of Washington 3

Ack 1 2 3 4 5 6 7 8 9 10 20 19 18 17 16 15 14 13 12 11 Data

slide-4
SLIDE 4

Benefit of ACK Clocking

  • Consider what happens when sender injects a burst
  • f segments into the network

CSE 461 University of Washington 4

Fast link Fast link Slow (bottleneck) link Queue

slide-5
SLIDE 5

Benefit of ACK Clocking (2)

  • Segments are buffered and spread out on slow link

CSE 461 University of Washington 5

Fast link Fast link Slow (bottleneck) link Segments “spread out”

slide-6
SLIDE 6

Benefit of ACK Clocking (3)

  • ACKs maintain the spread back to the original sender

CSE 461 University of Washington 6

Slow link Acks maintain spread

slide-7
SLIDE 7

Benefit of ACK Clocking (4)

  • Sender clocks new segments with the spread
  • Now sending at the bottleneck link without queuing!

CSE 461 University of Washington 7

Slow link Segments spread Queue no longer builds

slide-8
SLIDE 8

Benefit of ACK Clocking (4)

  • Helps run with low levels of loss and delay!
  • The network smooths out the burst of data segments
  • ACK clock transfers this smooth timing back to sender
  • Subsequent data segments are not sent in bursts so do

not queue up in the network

CSE 461 University of Washington 8

slide-9
SLIDE 9

TCP Uses ACK Clocking

  • TCP uses a sliding window because of the value of

ACK clocking

  • Sliding window controls how many segments are

inside the network

  • TCP only sends small bursts of segments to let the

network keep the traffic smooth

CSE 461 University of Washington 9

slide-10
SLIDE 10

Problem

  • Sliding window has pipelining to keep network busy
  • What if the receiver is overloaded?

CSE 461 University of Washington 10

Streaming video Big Iron Wee Mobile Arg …

slide-11
SLIDE 11

Receiver Sliding Window

  • Consider receiver with W buffers
  • LAS=LAST ACK SENT
  • app pulls in-order data from buffer with recv() call

CSE 461 University of Washington 11

Sliding Window .. 5 6 7 5 2 3 .. LAS W=5 Finished 3 .. Too high

  • seq. number

5 5 5 5 Acceptable

slide-12
SLIDE 12

Receiver Sliding Window (2)

  • Suppose the next two segments arrive but app does

not call recv()

CSE 461 University of Washington 12

.. 5 6 7 5 2 3 .. LAS W=5 Finished 3 .. Too high

  • seq. number

5 5 5 5 Acceptable

slide-13
SLIDE 13

Receiver Sliding Window (3)

  • Suppose the next two segments arrive but app does

not call recv()

  • LAS rises, but we can’t slide window!

CSE 461 University of Washington 13

.. 5 6 7 5 2 3 .. LAS W=5 Finished 3 .. Too high

  • seq. number

5 5 5 5 Acked

slide-14
SLIDE 14

Receiver Sliding Window (4)

  • Further segments arrive (in order) we fill buffer
  • Must drop segments until app recvs!

CSE 461 University of Washington 14

Nothing Acceptable! .. 5 6 7 5 2 3 .. W=5 Finished 3 .. Too high

  • seq. number

5 5 5 5 Acked LAS

slide-15
SLIDE 15

Receiver Sliding Window (5)

  • App recv() takes two segments
  • Window slides (phew)

CSE 461 University of Washington 15

Acceptable .. 5 6 7 5 2 3 .. W=5 Finished 3 ..

  • seq. number

5 5 5 5 Acked LAS

slide-16
SLIDE 16

Flow Control

  • Avoid loss at receiver by telling sender the available

buffer space

  • WIN=#Acceptable, not W (from LAS)

CSE 461 University of Washington 16

Acceptable .. 5 6 7 5 2 3 .. W=5 Finished 3 ..

  • seq. number

5 5 5 5 Acked LAS

slide-17
SLIDE 17

Flow Control (2)

  • Sender uses lower of the sliding window and flow

control window (WIN) as the effective window size

CSE 461 University of Washington 17

Acceptable .. 5 6 7 5 2 3 .. LAS W=3 Finished 3 .. Too high

  • seq. number

5 5 5 5 Acked

slide-18
SLIDE 18

CSE 461 University of Washington 18

Flow Control (3)

  • TCP-style example
  • SEQ/ACK sliding window
  • Flow control with WIN
  • SEQ + length < ACK+WIN
  • 4KB buffer at receiver
  • Circular buffer of bytes
slide-19
SLIDE 19

Topic

  • How to set the timeout for sending a retransmission
  • Adapting to the network path

CSE 461 University of Washington 19

Lost? Network

slide-20
SLIDE 20

Retransmissions

  • With sliding window, detecting loss with timeout
  • Set timer when a segment is sent
  • Cancel timer when ack is received
  • If timer fires, retransmit data as lost

CSE 461 University of Washington 20

Retransmit!

slide-21
SLIDE 21

Timeout Problem

  • Timeout should be “just right”
  • Too long à inefficient network capacity use
  • Too short à spurious resends waste network capacity
  • But what is “just right”?
  • Easy to set on a LAN (Link)
  • Short, fixed, predictable RTT
  • Hard on the Internet (Transport)
  • Wide range, variable RTT

CSE 461 University of Washington 21

slide-22
SLIDE 22

Example of RTTs

CSE 461 University of Washington 22

100 200 300 400 500 600 700 800 900 1000 20 40 60 80 100 120 140 160 180 200

Round Trip Time (ms) BCNàSEAàBCN Seconds

slide-23
SLIDE 23

Example of RTTs (2)

CSE 461 University of Washington 23

100 200 300 400 500 600 700 800 900 1000 20 40 60 80 100 120 140 160 180 200

Round Trip Time (ms) Variation due to queuing at routers, changes in network paths, etc. BCNàSEAàBCN Propagation (+transmission) delay ≈ 2D Seconds

slide-24
SLIDE 24

Example of RTTs (3)

CSE 461 University of Washington 24

100 200 300 400 500 600 700 800 900 1000 20 40 60 80 100 120 140 160 180 200

Round Trip Time (ms) Timer too high! Timer too low! Need to adapt to the network conditions Seconds

slide-25
SLIDE 25

Adaptive Timeout

  • Smoothed estimates of the RTT (1) and variance in RTT (2)
  • Update estimates with a moving average

1. SRTTN+1 = 0.9*SRTTN + 0.1*RTTN+1 2. SvarN+1 = 0.9*SvarN + 0.1*|RTTN+1– SRTTN+1|

  • Set timeout to a multiple of estimates
  • To estimate the upper RTT in practice
  • TCP TimeoutN = SRTTN + 4*SvarN

CSE 461 University of Washington 25

slide-26
SLIDE 26

Example of Adaptive Timeout

CSE 461 University of Washington 26

100 200 300 400 500 600 700 800 900 1000 20 40 60 80 100 120 140 160 180 200

RTT (ms) SRTT Svar Seconds

slide-27
SLIDE 27

Example of Adaptive Timeout (2)

CSE 461 University of Washington 27

100 200 300 400 500 600 700 800 900 1000 20 40 60 80 100 120 140 160 180 200

RTT (ms) Timeout (SRTT + 4*Svar) Early timeout Seconds

slide-28
SLIDE 28

Adaptive Timeout (2)

  • Simple to compute, does a good job of tracking

actual RTT

  • Little “headroom” to lower
  • Yet very few early timeouts
  • Turns out to be important for good performance

and robustness

CSE 461 University of Washington 28

slide-29
SLIDE 29

Congestion

slide-30
SLIDE 30

TCP to date:

  • We can set up and tear connections
  • Connection establishment and release handshakes
  • Keep the sending and receiving buffers from
  • verflowing (flow control)

What’s missing?

slide-31
SLIDE 31

Network Congestion

  • A “traffic jam” in the network
  • Later we will learn how to control it

CSE 461 University of Washington 31

What’s the hold up? Network

slide-32
SLIDE 32

Congestion Collapse in the 1980s

  • Early TCP used fixed size window (e.g., 8 packets)
  • Initially fine for reliability
  • But something happened as the network grew
  • Links stayed busy but transfer rates fell by orders of

magnitude!

CSE 461 University of Washington 32

slide-33
SLIDE 33

Nature of Congestion

  • Routers/switches have internal buffering

CSE 461 University of Washington 33

. . .

. . . . . .

. . . Input Buffer Output Buffer Fabric Input Output

slide-34
SLIDE 34

Nature of Congestion (2)

  • Simplified view of per port output queues
  • Typically FIFO (First In First Out), discard when full

CSE 461 University of Washington 34

Router

=

(FIFO) Queue Queued Packets Router

slide-35
SLIDE 35

Nature of Congestion (3)

  • Queues help by absorbing bursts when input >
  • utput rate
  • But if input > output rate persistently, queue will
  • verflow
  • This is congestion
  • Congestion is a function of the traffic patterns – can
  • ccur even if every link has the same capacity

CSE 461 University of Washington 35

slide-36
SLIDE 36

Effects of Congestion

  • What happens to performance as we increase load?
slide-37
SLIDE 37

Effects of Congestion (2)

  • What happens to performance as we increase load?
slide-38
SLIDE 38

Effects of Congestion (3)

  • As offered load rises, congestion occurs as queues

begin to fill:

  • Delay and loss rise sharply with load
  • Throughput < load (due to loss)
  • Goodput << throughput (due to spurious retransmissions)
  • None of the above is good!
  • Want network performance just before congestion

CSE 461 University of Washington 38

slide-39
SLIDE 39

TCP Tahoe/Reno

  • TCP extensions and features we will study:
  • AIMD
  • Fair Queuing
  • Slow-start
  • Fast Retransmission
  • Fast Recovery

CSE 461 University of Washington 40

slide-40
SLIDE 40

TCP Timeline

CSE 461 University of Washington 41

1988 1990 1970 1980 1975 1985 Origins of “TCP” (Cerf & Kahn, ’74) 3-way handshake (Tomlinson, ‘75) TCP Reno (Jacobson, ‘90) Congestion collapse Observed, ‘86 TCP/IP “flag day” (BSD Unix 4.2, ‘83) TCP Tahoe (Jacobson, ’88)

Pre-history Congestion control

. . . TCP and IP (RFC 791/793, ‘81)

slide-41
SLIDE 41

TCP Timeline (2)

CSE 461 University of Washington 42

2010 2000 1995 2005 ECN (Floyd, ‘94) TCP Reno (Jacobson, ‘90) TCP New Reno (Hoe, ‘95) TCP BIC (Linux, ‘04 TCP with SACK (Floyd, ‘96)

Diversification Classic congestion control

. . . 1990 TCP LEDBAT (IETF ’08) TCP Vegas (Brakmo, ‘93) TCP CUBIC (Linux, ’06) . . . Background Router support Delay based FAST TCP (Low et al., ’04) Compound TCP (Windows, ’07)

slide-42
SLIDE 42

Bandwidth Allocation

  • Important task for network is to allocate its capacity

to senders

  • Good allocation is both efficient and fair
  • Efficient: most capacity is used but there is no

congestion

  • Fair: every sender gets a reasonable share of the

network

CSE 461 University of Washington 43

slide-43
SLIDE 43

Efficiency vs. Fairness

  • Cannot always have both!
  • Example network with traffic:
  • AàB, BàC and AàC
  • How much traffic can we carry?

CSE 461 University of Washington 44

A B C 1 1

slide-44
SLIDE 44

Efficiency vs. Fairness (2)

  • If we care about fairness:
  • Give equal bandwidth to each flow
  • AàB: ½ unit, BàC: ½, and AàC, ½
  • Total traffic carried is 1 ½ units

CSE 461 University of Washington 45

A B C 1 1

slide-45
SLIDE 45

Efficiency vs. Fairness (3)

  • If we care about efficiency:
  • Maximize total traffic in network
  • AàB: 1 unit, BàC: 1, and AàC, 0
  • Total traffic rises to 2 units!

CSE 461 University of Washington 46

A B C 1 1

slide-46
SLIDE 46

Fairness

  • What’s a “fair” bandwidth allocation?
  • The max-min fair allocation

CSE 461 University of Washington 47

slide-47
SLIDE 47

The Slippery Notion of Fairness

  • Why is “equal per flow” fair anyway?
  • AàC uses more network resources than AàB or BàC
  • Host A sends two flows, B sends one
  • Not productive to seek exact fairness
  • More important to avoid starvation
  • A node that cannot use any bandwidth
  • “Equal per flow” is good enough

CSE 461 University of Washington 48

slide-48
SLIDE 48

Generalizing “Equal per Flow”

  • Bottleneck for a flow of traffic is the link that limits

its bandwidth

  • Where congestion occurs for the flow
  • For AàC, link A–B is the bottleneck

CSE 461 University of Washington 49

A B C 1 10 Bottleneck

slide-49
SLIDE 49

Generalizing “Equal per Flow” (2)

  • Flows may have different bottlenecks
  • For AàC, link A–B is the bottleneck
  • For BàC, link B–C is the bottleneck
  • Can no longer divide links equally …

CSE 461 University of Washington 50

A B C 1 10

slide-50
SLIDE 50

Max-Min Fairness

  • Intuitively, flows bottlenecked on a link get an equal

share of that link

  • Max-min fair allocation is one that:
  • Increasing the rate of one flow will decrease the rate of a

smaller flow

  • This “maximizes the minimum” flow

CSE 461 University of Washington 51

slide-51
SLIDE 51

Max-Min Fairness (2)

  • To find it given a network, imagine “pouring water

into the network”

  • 1. Start with all flows at rate 0
  • 2. Increase the flows until there is a new bottleneck in

the network

  • 3. Hold fixed the rate of the flows that are bottlenecked
  • 4. Go to step 2 for any remaining flows

CSE 461 University of Washington 52

slide-52
SLIDE 52

Max-Min Example

  • Example: network with 4 flows, link bandwidth = 1
  • What is the max-min fair allocation?

CSE 461 University of Washington 53

slide-53
SLIDE 53

Max-Min Example (2)

  • When rate=1/3, flows B, C, and D bottleneck R4—R5
  • Fix B, C, and D, continue to increase A

CSE 461 University of Washington 54

Bottleneck Bottleneck

slide-54
SLIDE 54

Max-Min Example (3)

  • When rate=2/3, flow A bottlenecks R2—R3. Done.

CSE 461 University of Washington 55

Bottleneck Bottleneck

slide-55
SLIDE 55

Max-Min Example (4)

  • End with A=2/3, B, C, D=1/3, and R2—R3, R4—R5

full

  • Other links have extra capacity that can’t be used
  • , linksxample: network with 4 flows, links equal

bandwidth

  • What is the max-min fair allocation?

CSE 461 University of Washington 56

slide-56
SLIDE 56

Adapting over Time

  • Allocation changes as flows start and stop

CSE 461 University of Washington 57

Time

slide-57
SLIDE 57

Adapting over Time (2)

CSE 461 University of Washington 58

Flow 1 slows when Flow 2 starts Flow 1 speeds up when Flow 2 stops Time Flow 3 limit is elsewhere