Lecture20: Scheduling and QoS · Lecture 20 Overview TCP Bandwidth Probing Scheduling u (Weighted) Fair Queuing CSE 123 –Lecture 20: Scheduling & QoS 2

CSE 123: Computer NetworksAaron Schulman

Lecture 20:Scheduling and QoS

Lecture 20 Overview

● TCP Bandwidth Probing

● Schedulingu (Weighted) Fair Queuing

2CSE 123 – Lecture 20: Scheduling & QoS

TCP Bandwidth Probing● TCP uses AIMD to adjust congestion window

u Converges to fair share of bottleneck linku Increases modestly in good timesu Cuts drastically in bad times

● But what rate should a TCP flow use initially?u Need some initial congestion windowu We’d like to TCP to work on all manner of linksu Need to span 6+ orders of magnitude, e.g., 10 K to 10 Gbps.u Starting too fast is catastrophic!


● Goal: quickly find the equilibrium sending rate

● Quickly increase sending rate until congestion detectedu Remember last rate that worked and don’t overshoot it

● TCP Reno Algorithm: u On new connection, or after timeout, set cwnd=1 MSSu For each segment acknowledged, increment cwnd by 1 MSSu If timeout then divide cwnd by 2, and set ssthresh = cwndu If cwnd >= ssthresh then exit slow start

● Why called slow? Its exponential after all…

4

Slow Start

CSE 123 – Lecture 20: Scheduling & QoS

1

2Ack 2

3Ack 3

4567

cwnd=1

cwnd=2

cwnd=4

cwnd=8

Sender Receiver

0

50

100

150

200

250

300

0 1 2 3 4 5 6 7 8round-trip times

cwnd

Ack 4

Ack 5Ack 6Ack 7Ack 8

5

Slow Start Example


Slow Start + Congestion Avoidance

0

2

4

6

8

10

12

14

16

18

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40

round-trip times

cwnd

Timeout

ssthresh

Slow start

Congestionavoidance

6

Basic Mechanisms


● Fast retransmitu Timeouts are slow (default often 200 ms or 1 second)u When packet is lost, receiver still ACKs last in-order packetu Use 3 duplicate ACKs to indicate a loss; detect losses quickly

» Why 3? When wouldn’t this work?

● Fast recoveryu Goal: avoid stalling after loss u If there are still ACKs coming in, then no need for slow startu If a packet has made it through -> we can send another oneu Divide cwnd by 2 after fast retransmitu Increment cwnd by 1 MSS for each additional duplicate ACK

7

Fast Retransmit & Recovery


1

2Ack 2

3

4567

Sender Receiver

Ack 4

Ack 4Ack 4Ack 4Ack 4

Ack 3

4

3 Dup Acks

Fast retransmit

Fast recovery(increase cwnd by 1)

8

8

Fast Retransmit Example


Slow Start + Congestion Avoidance +Fast Retransmit + Fast Recovery

0

2

4

6

8

10

12

14

16

18

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40

round-trip times

cwnd

Fast recovery

9

More Sophistication


● Short connection: only contains a few pkts● How do short connections and Slow-Start interact?

u What happens when a packet is lost during Slow-Start?u What happens when the SYN is dropped?

● Bottom line: Which packet gets dropped matters a lotu SYNu Slow-Startu Congestion avoidance

● Do you think most flows are short or long?● Do you think most traffic is in short flows or long flows?

10

Short Connections


● TCP is designed around the premise of cooperationu What happens to TCP if it competes with a UDP flow?u What if we divide cwnd by 3 instead of 2 after a loss?

● There are a bunch of magic numbersu Decrease by 2x, increase by 1/cwnd, 3 duplicate acks, initial

timeout = 3 seconds, etc.

● But overall it works really well!u Still being constantly tweaked…

11

Open Issues


● TCP Probes the network for bandwidth, assuming that loss signals congestion

● The congestion window is managed with an additive increase/multiplicative decrease policyu It took fast retransmit and fast recovery to get thereu Fast recovery keeps pipe “full” while recovering from a loss

● Slow start is used to avoid lengthy initial delaysu Ramp up to near target rate, then switch to AIMD

12

TCP CC Summary


● So far we’ve done flow-based traffic policingu Limit the rate of one flow regardless of the load in the network

● In general, need schedulingu Dynamically allocate resources when multiple flows competeu Give each “flow” (or traffic class) own queue (at least

theoretically)

● Weighted fair queuingu Proportional share schedulingu Schedule round-robins among queues in proportion to some

weight parameter

Scheduling


Bottleneck link(10 Mbps)

1 UDP (10 Mbps) and 31 TCPs sharing a 10 Mbps line

UDP (#1) - 10 Mbps

TCP (#2)

TCP (#32)

...

UDP (#1)

TCP (#2)

TCP (#32)

...

Our Previous Example


UDP vs. TCP w/FIFO


TCP vs. UDP w/Fair Queuing


Flow 1

Flow 2

Flow n

I/P O/P

(Weighted) Fair Queuing


● Maintain a queue for each flowu What is a flow?

● Implements max-min fairness: each flow receives min(ri, f) , where

u ri – flow arrival rateu f – link fair rate (see next slide)

● Weighted Fair Queuing (WFQ) – associate a weight with each flow to divvy bandwidth up non-equally

Fair Queuing


● If link congested, compute f such that

862

44

2

f = 4: min(8, 4) = 4min(6, 4) = 4min(2, 4) = 2

10

Fair Rate Computation


● Associate a weight wi with each flow i● If link congested, compute f such that

862

44

2

f = 2: min(8, 2*3) = 6min(6, 2*1) = 2min(2, 2*1) = 2

10(w1 = 3)(w2 = 1)(w3 = 1)

If Σk wk <= C, flow i is guaranteed to be allocated a rate >= wi

Flow i is guaranteed to be allocated a rate >= wi*C/(Σk wk)

Another Example


● Flows can be served one bit at a time

● WFQ can be implemented using bit-by-bit weighted round robin

u During each round from each flow that has data to send, send a number of bits equal to the flow’s weight

Fluid Flow


0 152 104 6 8

5 1 1 11 1

● Orange flow has packets backlogged between time 0 and 10

● Other flows have packets continuously backlogged

● All packets have the same size

flows

link

weights

Fluid Flow Example


● Packet (Real) system: packet transmission cannot be preempted. Why?

● Solution: serve packets in the order in which they would have finished being transmitted in the fluid flow system

Packet-Based Implementation


0 2 104 6 8

0 2 104 6 8

● Select the first packet that finishes in the fluid flow system

Servicein fluid flow

system

Packetsystem

Packet-Based Example


For next time…

● Changing gears severely next lecture!

● Read Ch. 1.5 in P&D


Documents

Lecture20: Scheduling and QoS · Lecture 20 Overview TCP Bandwidth Probing Scheduling u (Weighted) Fair Queuing CSE 123 –Lecture 20: Scheduling & QoS 2