Networks & Protocols INF566 - X2010 - 2012 Lecture 2a - - - PowerPoint PPT Presentation

▶
networks protocols
SMART_READER_LITE
LIVE PREVIEW

Networks & Protocols INF566 - X2010 - 2012 Lecture 2a - - - PowerPoint PPT Presentation

Sep 29, 2023 459 likes •1.19k views

Networks & Protocols INF566 - X2010 - 2012 Lecture 2a - Congestion control: Seeing Red thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/ 1 Networks & Protocols INF566 - X2010 - 2012

slide-1
SLIDE 1

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Networks & Protocols

INF566 - X2010 - 2012 Lecture 2a - Congestion control: Seeing Red

1

slide-2
SLIDE 2

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Networks & Protocols

INF566 - X2010 - 2012 Lecture 2a - Congestion control: Seeing Red

1

slide-3
SLIDE 3

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

1 9/1 Intro, kick-off, objectives and motivation (Thomas) “What Makes For A Successful Protocol?” (Mark) 2 16/1 “Bufferbloat & the Broken Internet” (Thomas & Mark) 3 23/1 “Carrier-Grade Routing” (Thomas) 4 30/1 “Peering” (Thomas & Mark) 5 6/2 RPKI (Mark) 6 13/2 "Indirection, Encapsulation, and Obfuscation" (Mark & Thomas) 7 20/2 SDOs: the ITU, IETF, ... - Guest Lecture by Elliot Lear 8 27/2 "Homenetworking and The Curse of the End-2-End Model" (Mark) 9 ??? Presentations by buddy-teams (Thomas + Mark)

2

slide-4
SLIDE 4

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

1 9/1 Intro, kick-off, objectives and motivation (Thomas) “What Makes For A Successful Protocol?” (Mark) 2 16/1 “Bufferbloat & the Broken Internet” (Thomas & Mark) 3 23/1 “Carrier-Grade Routing” (Thomas) 4 30/1 “Peering” (Thomas & Mark) 5 6/2 RPKI (Mark) 6 13/2 "Indirection, Encapsulation, and Obfuscation" (Mark & Thomas) 7 20/2 SDOs: the ITU, IETF, ... - Guest Lecture by Elliot Lear 8 27/2 "Homenetworking and The Curse of the End-2-End Model" (Mark) 9 ??? Presentations by buddy-teams (Thomas + Mark)

2

slide-5
SLIDE 5

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Objectives

3

slide-6
SLIDE 6

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Objectives

  • Recapitulate TCP Congestion Control...

3

slide-7
SLIDE 7

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Objectives

  • Recapitulate TCP Congestion Control...
  • ...and why that doesn’t actually work...

3

slide-8
SLIDE 8

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Objectives

  • Recapitulate TCP Congestion Control...
  • ...and why that doesn’t actually work...
  • Can’t fix TCP

, can we fix the routers?

3

slide-9
SLIDE 9

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Objectives

  • Recapitulate TCP Congestion Control...
  • ...and why that doesn’t actually work...
  • Can’t fix TCP

, can we fix the routers?

  • We could, but didn’t - let’s blame Cisco ;)

3

slide-10
SLIDE 10

Flow Control

Buffers “in end-points”

Sender window determined by receiver buffer capacity: do not overload receiver. Sender Receiver

“speed dating matching service” matches rate of sender to rate at which receiving application is reading

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

4

slide-11
SLIDE 11

Congestion Control

Buffers “in between”

Sender Receiver

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

5

slide-12
SLIDE 12

Congestion Control

Buffers “in between”

Sender Receiver Different senders “share” links and buffer space

“Network Buffers” (routers, etc.) overload too

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

5

slide-13
SLIDE 13

Congestion Control

So, what signals do we have...

Sender Receiver Transport Protocol Signaling

“Something’s Rotten.....”? Goal:

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

6

slide-14
SLIDE 14

Congestion Control

So, what signals do we have...

Sender Receiver Transport Protocol Signaling

“Something’s Rotten.....”? Goal:

  • Less, not more, signals
  • Infer congestion

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

6

slide-15
SLIDE 15

Congestion Control

So, what signals do we have...

Sender Receiver Transport Protocol Signaling

“Something’s Rotten.....”?

  • Message Drops
  • Duplicate ACKs

Goal:

  • Less, not more, signals
  • Infer congestion

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

6

slide-16
SLIDE 16

Congestion Control

How do we slow down?

Sender Receiver Transport Protocol Signaling

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

7

slide-17
SLIDE 17

Congestion Control

How do we slow down?

Sender Receiver Transport Protocol Signaling

  • Introduce “Congestion Window”, CWS in sender
  • Set Sender Window = min{UWS, RWS}

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

7

slide-18
SLIDE 18

Congestion Control

The Beginning: Tahoe (UWS=CWS)

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

8

slide-19
SLIDE 19

Congestion Control

The Beginning: Tahoe (UWS=CWS)

  • 1. Start: CWS = 1; threshold = reasonable-large-value

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

8

slide-20
SLIDE 20

Congestion Control

The Beginning: Tahoe (UWS=CWS)

  • 1. Start: CWS = 1; threshold = reasonable-large-value
  • 2. While CWS < threshold:
  • For each message ACKed: CWS=CWS+1

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

8

slide-21
SLIDE 21

Congestion Control

The Beginning: Tahoe (UWS=CWS)

  • 1. Start: CWS = 1; threshold = reasonable-large-value
  • 2. While CWS < threshold:
  • For each message ACKed: CWS=CWS+1
  • 3. While CWS > threshold:
  • For each CWS messages ACKed: CWS=CWS+1

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

8

slide-22
SLIDE 22

Congestion Control

The Beginning: Tahoe (UWS=CWS)

  • 1. Start: CWS = 1; threshold = reasonable-large-value
  • 2. While CWS < threshold:
  • For each message ACKed: CWS=CWS+1
  • 3. While CWS > threshold:
  • For each CWS messages ACKed: CWS=CWS+1
  • 4. If no ACK received before time-out:
  • threshold = CWS/2
  • CWS = 1

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

8

slide-23
SLIDE 23

Congestion Control

The Beginning: Tahoe (UWS=CWS)

  • 1. Start: CWS = 1; threshold = reasonable-large-value
  • 2. While CWS < threshold:
  • For each message ACKed: CWS=CWS+1
  • 3. While CWS > threshold:
  • For each CWS messages ACKed: CWS=CWS+1
  • 4. If no ACK received before time-out:
  • threshold = CWS/2
  • CWS = 1

➡probe for success, back down for failure

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

8

slide-24
SLIDE 24

Congestion Control

The Beginning: Tahoe (UWS=CWS)

Slow Start Congestion Avoidance Recovery

  • 1. Start: CWS = 1; threshold = reasonable-large-value
  • 2. While CWS < threshold:
  • For each message ACKed: CWS=CWS+1
  • 3. While CWS > threshold:
  • For each CWS messages ACKed: CWS=CWS+1
  • 4. If no ACK received before time-out:
  • threshold = CWS/2
  • CWS = 1

➡probe for success, back down for failure

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

8

slide-25
SLIDE 25

Congestion Control

Tahoe CWIN Evolution

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CWIN Size

t1 t2

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

9

slide-26
SLIDE 26

Congestion Control

Tahoe CWIN Evolution

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CWIN Size

t1 t2

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

9

slide-27
SLIDE 27

Congestion Control

Tahoe CWIN Evolution

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CWIN Size

t1 t2 Tahoe acts on no-ack + Timeout

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

9

slide-28
SLIDE 28

Congestion Control

Tahoe

  • Problems:
  • Takes complete timeout interval to

detect and react to packet loss

  • Go-back-n is “forced”
  • So, not good at the lonely packet loss ....

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

10

slide-29
SLIDE 29

Congestion Control

Reno

Slow Start Congestion Avoidance Recovery

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

11

slide-30
SLIDE 30

Congestion Control

Reno

Slow Start Congestion Avoidance Recovery

  • 1. Start: CWS = 1; threshold = reasonable-large-value
  • 2. While CWS < threshold:
  • For each message ACKed: CWS=CWS+1
  • 3. While CWS > threshold:
  • For each CWS messages ACKed: CWS=CWS+1
  • 4. If no ACK received before time-out:
  • threshold = CWS/2
  • CWS = 1

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

11

slide-31
SLIDE 31

Congestion Control

Reno

Slow Start Congestion Avoidance Recovery

  • 1. Start: CWS = 1; threshold = reasonable-large-value
  • 2. While CWS < threshold:
  • For each message ACKed: CWS=CWS+1
  • 3. While CWS > threshold:
  • For each CWS messages ACKed: CWS=CWS+1
  • 4. If no ACK received before time-out:
  • threshold = CWS/2
  • CWS = 1
  • 5. If triple duplicate ACK received:
  • Fast Retransmit + Fast Recovery (FR&R)

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

11

slide-32
SLIDE 32

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

S D

“NACK”

TCP Fast Retransmit

12

slide-33
SLIDE 33

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

S D

SND

“NACK”

TCP Fast Retransmit

12

slide-34
SLIDE 34

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

ACK:<1

Receiver:

  • Msg with too high seq# = 2
  • Send ACK:<1
  • Msg with too high seq# = 3
  • Send ACK:<1
  • Msg with too high seq# = 4
  • Send ACK:<1

S D

1:m 3:m 2:m 4:m

SND

1 2 3 4

“NACK”

TCP Fast Retransmit

ACK:<1 ACK:<1

Sender:

  • Triple duplicate ACK

12

slide-35
SLIDE 35

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

ACK:<1

Receiver:

  • Msg with too high seq# = 2
  • Send ACK:<1
  • Msg with too high seq# = 3
  • Send ACK:<1
  • Msg with too high seq# = 4
  • Send ACK:<1

S D

1:m 3:m 2:m 4:m 1: m

SND

“NACK”

TCP Fast Retransmit

ACK:<5 ACK:<1 ACK:<1

Sender:

  • Triple duplicate ACK
  • Can interpret as implicit

NACK

12

slide-36
SLIDE 36

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

ACK:<1

Receiver:

  • Msg with too high seq# = 2
  • Send ACK:<1
  • Msg with too high seq# = 3
  • Send ACK:<1
  • Msg with too high seq# = 4
  • Send ACK:<1

S D

1:m 3:m 2:m 4:m 1: m

SND

“NACK”

TCP Fast Retransmit

ACK:<5 ACK:<1 ACK:<1

Sender:

  • Triple duplicate ACK
  • Can interpret as implicit

NACK

Receiver MUST send ACK immediately when gap is filled

12

slide-37
SLIDE 37

Congestion Control

Reno CWIN Evolution

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CWIN Size

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

13

slide-38
SLIDE 38

Congestion Control

Reno CWIN Evolution

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CWIN Size

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

13

slide-39
SLIDE 39

Congestion Control

Reno CWIN Evolution

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CWIN Size

As Tahoe, acts on no-ack + Timeout

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

13

slide-40
SLIDE 40

Congestion Control

Reno CWIN Evolution

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CWIN Size

As Tahoe, acts on no-ack + Timeout Duplicate ACK Fast Retransmit & Recovery

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

13

slide-41
SLIDE 41

Congestion Control

Reno CWIN Evolution

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CWIN Size

As Tahoe, acts on no-ack + Timeout Duplicate ACK Fast Retransmit & Recovery

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

13

slide-42
SLIDE 42

TCP Tail-Drop Queue Mgmt

  • “Tail-drop”
  • If space in queue - enqueue
  • Otherwise, drop
  • React to congestion when it’s happening
  • Consequences
  • React to congestion when it’s happening ;)
  • Cause global synchronization
  • Lock-out

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

14

slide-43
SLIDE 43

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Global Synchronization

15

slide-44
SLIDE 44

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Global Synchronization

5xTCP 5xTCP

15

slide-45
SLIDE 45

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Global Synchronization

5xTCP 5xTCP

  • Each connection:
  • Start at random time
  • Lasts “forever”
  • Rwin = 20 packets
  • Packet size = 500 octets; ACK = 50 octets
  • Router buffer size: 30 packets

15

slide-46
SLIDE 46

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Global Synchronization

5xTCP 5xTCP

  • Each connection:
  • Start at random time
  • Lasts “forever”
  • Rwin = 20 packets
  • Packet size = 500 octets; ACK = 50 octets
  • Router buffer size: 30 packets

15

slide-47
SLIDE 47

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Global Synchronization

"Oscillating Behavior of Network Traffic: A Case Study Simulation" by Lixia Zhang and Dave Clark

16

slide-48
SLIDE 48

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Global Synchronization

"Characteristics of UDP Packet Loss: Effect of TCP Traffic" by Hidenari Sawashima, Yoshiaki Hori, Hideki Sunahara

Homogenous traffic flows

17

slide-49
SLIDE 49

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Lock-Out

Two flows, bottle-neck link:

  • If adequate buffers, each will each get a fair share
  • If not adequate buffers, packets are dropped
  • Observations from Real Networks:
  • Often one flow’s packets get into the queue first;
  • The other flow experiences most (all?) of the

packet drops

18

slide-50
SLIDE 50

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Lock-Out

19

slide-51
SLIDE 51

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Lock-Out

Trivially Simple Illustration: f1, f2 - buffer size 20 packets f1 keeps buffer at 20 packets, link saturated f2 transmits 1 packet (slow start) - dropped (buffer full)

19

slide-52
SLIDE 52

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Problems

  • Lock-Out
  • Reacting to congestion when it is happening
  • Congestion → slow-start
  • Prefer: Fast Retransmit & Recovery
  • Akin to “Driving on snow”:

slow down, don’t emergency-brake (& crash)

  • Global Synchronization

20

slide-53
SLIDE 53

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Lock-Out

21

slide-54
SLIDE 54

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

  • Random-drop
  • Drop some random packet, which is not the

arriving packet

Tail-Drop Lock-Out

21

slide-55
SLIDE 55

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

  • Random-drop
  • Drop some random packet, which is not the

arriving packet

  • Front-drop
  • Drop packet at head of queue

Tail-Drop Lock-Out

21

slide-56
SLIDE 56

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

  • Random-drop
  • Drop some random packet, which is not the

arriving packet

  • Front-drop
  • Drop packet at head of queue

✓Always make room for arriving packet

Tail-Drop Lock-Out

21

slide-57
SLIDE 57

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

  • Intuition: notify senders of incipient congestion
  • Drop packets before queue becomes full
  • Example: early drop
  • Thus, a “next packet” in a flow, after a

dropped packet,may get through → FR&R

  • Sender(s) slows down, but doesn’t

“emergency brake”

Tail-Drop React (only) when congested?

22

slide-58
SLIDE 58

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Global Synchronization

"Oscillating Behavior of Network Traffic: A Case Study Simulation" by Lixia Zhang and Dave Clark

23

slide-59
SLIDE 59

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Tail-Drop Global Synchronization

  • Avoid window synchronization
  • Intuition:
  • Force flows to enter FR&R at random (non-

synchronized) times

  • Random-drop (not tail-drop)

24

slide-60
SLIDE 60

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Towards.....

25

slide-61
SLIDE 61

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Towards.....

25

slide-62
SLIDE 62

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Towards.....

  • Detect incipient congestion
  • Drop packets early
  • Random-drop
  • Of course, maximize channel utilization

25

slide-63
SLIDE 63

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Towards.....

  • Detect incipient congestion
  • Drop packets early
  • Random-drop
  • Of course, maximize channel utilization

Random Early Detection (RED)

25

slide-64
SLIDE 64

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

RED Algorithm (basic)

  • Maintain weighted running avg of queue length avgq
  • Fix two threshold, minth and maxth
  • If avgq < minth:
  • do nothing
  • If avgq > maxth:
  • drop packet
  • If minth < avgq < maxth:
  • Calculate 0 < Pa < maxp
  • Drop packet with probability Pa

26

slide-65
SLIDE 65

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

RED Illustrated

minth maxth maxP 1.0 Avg queue length

Normal Congestion Avoidance Congestion Control

Drop Probability (Pa)

27

slide-66
SLIDE 66

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

RED Details (1)

  • “Classic” weighted avg

when receiving packet:

  • avgq = (1−w) * avgq +w* Q(t)
  • 0<w<1
  • Q(t) is length of queue at time t

28

slide-67
SLIDE 67

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

RED Details (1)

  • “Classic” weighted avg

when receiving packet:

  • avgq = (1−w) * avgq +w* Q(t)
  • 0<w<1
  • Q(t) is length of queue at time t

“Keep queue-length low enough to absorb some burstiness”

29

slide-68
SLIDE 68

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

RED Details (2)

  • Good idea?
  • Pa = maxp * (avgq - minth) / (maxth - minth)

“How frequently to drop packets, given current congestion level”

30

slide-69
SLIDE 69

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

RED Details (3)

  • Better: Avoid Clustering
  • Pb = maxp * (avgq - minth) / (maxth - minth)
  • Pa = Pb / (1 - count * Pb)
  • Where:
  • count: # packets since last marked packet
  • maxp is a constant, max for Pb

The goal is for the gateway to mark packets at fairly evenly-spaced intervals, in order to avoid biases and to avoid global synchronization, and to mark packets sufficiently frequently to control the average queue size.

31

slide-70
SLIDE 70

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

RED Details (4)

The goal is for the gateway to mark packets at fairly evenly-spaced intervals, in order to avoid biases and to avoid global synchronization, and to mark packets sufficiently frequently to control the average queue size.

32

slide-71
SLIDE 71

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

RED “Problems”

(Or, why RED didn’t solve the problem)

  • When several flows are in slow-start

simultaneously, maxth might be hit → tail-drop

  • With a large number of connections, not all of them

may get congestion indications → unfair

  • Parametrization required, channel/traffic dependent
  • Cisco routers didn’t support RED ;)
  • UDP

.....

33

slide-72
SLIDE 72

thomas@thomasclausen.org http://www.thomasclausen.org mark@townsley.net http://www.townsley.net/

Networks & Protocols

INF566 - X2010 - 2012 Lecture 2(b) - “Bufferbloat and the Broken Internet?”

So, mr. Cisco - what’s your excuse?

34