John Rauser Velocity June, 2010 TCP and the Lower Bound of Web - - PowerPoint PPT Presentation

▶
john rauser
SMART_READER_LITE
LIVE PREVIEW

John Rauser Velocity June, 2010 TCP and the Lower Bound of Web - - PowerPoint PPT Presentation

Sep 04, 2023 231 likes •2.16k views

John Rauser Velocity June, 2010 TCP and the Lower Bound of Web Performance 1996 Its the Latency, Stupid http://rescomp.stanford.edu/~cheshire/rants/Latency.html 1) Making more bandwidth is easy. 2) Once you have bad latency

slide-1
SLIDE 1
slide-2
SLIDE 2

John Rauser Velocity June, 2010

slide-3
SLIDE 3

TCP and the Lower Bound of Web Performance

slide-4
SLIDE 4

1996

slide-5
SLIDE 5
slide-6
SLIDE 6

It’s the Latency, Stupid

http://rescomp.stanford.edu/~cheshire/rants/Latency.html

slide-7
SLIDE 7

1) “Making more bandwidth is easy.”

slide-8
SLIDE 8

2) “Once you have bad latency you're stuck with it.”

slide-9
SLIDE 9
slide-10
SLIDE 10
slide-11
SLIDE 11
slide-12
SLIDE 12
slide-13
SLIDE 13
slide-14
SLIDE 14

7,400 km 300,000 km/sec = 25 ms

slide-15
SLIDE 15

In a vacuum

slide-16
SLIDE 16
slide-17
SLIDE 17

1.5 1 = 0.66

slide-18
SLIDE 18
slide-19
SLIDE 19

Theoretical fiber

slide-20
SLIDE 20

From my house

Ping statistics: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 91ms, Maximum = 98ms, Average = 93ms

slide-21
SLIDE 21

From my house

slide-22
SLIDE 22

From my house: 90 ms Theoretical fiber: 37 ms 2

slide-23
SLIDE 23

It’s been this way for over a decade.

slide-24
SLIDE 24

“Once you have bad latency you're stuck with it.”

slide-25
SLIDE 25

Fascinating!

slide-26
SLIDE 26
slide-27
SLIDE 27

Network latency matters for web applications

slide-28
SLIDE 28

History of the Internet

slide-29
SLIDE 29

September 1981

slide-30
SLIDE 30
slide-31
SLIDE 31

RFC 793

slide-32
SLIDE 32

Transmission Control Protocol

slide-33
SLIDE 33

Transmission Control Protocol

slide-34
SLIDE 34

Basic Data Transfer Reliability Flow Control Multiplexing Connections Precedence and Security

slide-35
SLIDE 35

Basic Data Transfer Reliability Flow Control Multiplexing Connections Precedence and Security

slide-36
SLIDE 36

Reliability

slide-37
SLIDE 37

“This is achieved by… requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted.”

  • RFC 793
slide-38
SLIDE 38

Client Server

slide-39
SLIDE 39

Client Server

slide-40
SLIDE 40

Client Server

slide-41
SLIDE 41

Client Server

slide-42
SLIDE 42

Client Server

slide-43
SLIDE 43

Client Server

slide-44
SLIDE 44

Client Server

slide-45
SLIDE 45

Flow Control

slide-46
SLIDE 46

“This is achieved by returning a „window‟ with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of

  • ctets that the sender may

transmit before receiving further permission.”

  • RFC 793
slide-47
SLIDE 47

“This is achieved by returning a „window‟ with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of

  • ctets that the sender may

transmit before receiving further permission.”

  • RFC 793
slide-48
SLIDE 48

TCP Window: The maximum amount of un-ACKed data in flight.

slide-49
SLIDE 49

Client Server

Window: 5kB Max Segment Size: 1kB

slide-50
SLIDE 50

Client Server Window: 5kB Max Segment: 1kB

slide-51
SLIDE 51

Client Server Window: 5kB Max Segment: 1kB

slide-52
SLIDE 52

Client Server Window: 5kb Max Segment: 1kb

slide-53
SLIDE 53

Client Server Window: 5kB Max Segment: 1kB

slide-54
SLIDE 54

Client Server Window: 5kB Max Segment: 1kB

slide-55
SLIDE 55

September 1981 RFC 791, 793 TCP/IP

slide-56
SLIDE 56

September 1981 213 hosts

slide-57
SLIDE 57

May 1982 235 hosts

slide-58
SLIDE 58
slide-59
SLIDE 59
slide-60
SLIDE 60

August 1983 BSD 4.2

slide-61
SLIDE 61

100,000 200,000 300,000 400,000 500,000 600,000 700,000 800,000 1979 1981 1983 1985 1987 1989 1991 1993

Growth in Internet hosts 1981-1991

Data from RFC 1296

slide-62
SLIDE 62

1 4 16 64 256 1024 4096 16384 65536 262144 1048576 1979 1981 1983 1985 1987 1989 1991 1993

Growth in Internet hosts 1981-1991

Data from RFC 1296

slide-63
SLIDE 63

October 1986 Congestion collapse

slide-64
SLIDE 64

Window size is allocated 16 bits in a TCP header, so maximum window size is 64kB

slide-65
SLIDE 65

Client Server Window: 64kb Max Segment: 1kb

slide-66
SLIDE 66

Client Server Window: 64kb Max Segment: 1kb

slide-67
SLIDE 67
slide-68
SLIDE 68

Client Server

slide-69
SLIDE 69

Client Server Window: 64kb Max Segment: 1kb

slide-70
SLIDE 70

January 1984 John Nagle - RFC 896

slide-71
SLIDE 71

“…a sudden load on the net can cause the round-trip time to rise faster than the sending host‟s measurements of round- trip time can be updated.”

  • RFC 896
slide-72
SLIDE 72

“Should the round-trip time exceed the maximum retransmission interval for any host, that host will begin to introduce more and more copies of the same datagrams into the net. The network is now in serious trouble.”

  • RFC 896
slide-73
SLIDE 73

“Should the round-trip time exceed the maximum retransmission interval for any host, that host will begin to introduce more and more copies of the same datagrams into the net. The network is now in serious trouble.”

  • RFC 896
slide-74
SLIDE 74

“Eventually all available buffers in the switching nodes will be full and packets must be dropped. Hosts are sending each packet several times, and eventually some copy of each packet arrives at its destination. This is congestion collapse.”

  • RFC 896
slide-75
SLIDE 75

“Eventually all available buffers in the switching nodes will be full and packets must be dropped. Hosts are sending each packet several times, and eventually some copy of each packet arrives at its destination. This is congestion collapse.”

  • RFC 896
slide-76
SLIDE 76

“This condition is stable. Once the saturation point has been reached, if the algorithm for selecting packets to be dropped is fair, the network will continue to operate in a degraded condition.”

  • RFC 896
slide-77
SLIDE 77

“Congestion collapse and pathological congestion are not normally seen in the ARPANET / MILNET system because these networks have substantial excess capacity.”

  • RFC 896
slide-78
SLIDE 78

1 4 16 64 256 1024 4096 16384 65536 262144 1048576 1979 1981 1983 1985 1987 1989 1991 1993

Growth in Internet hosts 1981-1991

Data from RFC 1296

slide-79
SLIDE 79

“The critical congestion problems the ARPANET is experiencing causes TELNET and FTP connections to time

  • ut and mail messages from MILNET

hosts to take up to 2-3 days to be delivered to BBNNET hosts.”

  • Nancy Cassidy in mod.risks, September 22 1986
slide-80
SLIDE 80
slide-81
SLIDE 81
slide-82
SLIDE 82
slide-83
SLIDE 83
slide-84
SLIDE 84
slide-85
SLIDE 85
slide-86
SLIDE 86
slide-87
SLIDE 87
slide-88
SLIDE 88
slide-89
SLIDE 89
slide-90
SLIDE 90
slide-91
SLIDE 91
slide-92
SLIDE 92

1

slide-93
SLIDE 93

1 2

slide-94
SLIDE 94

1 2 3

slide-95
SLIDE 95

1 2 3 4

slide-96
SLIDE 96

1 2 3 4 5

slide-97
SLIDE 97

“Nothing in this trace resembles desirable behavior.”

slide-98
SLIDE 98

TCP Slow Start

slide-99
SLIDE 99

window : receiver

slide-100
SLIDE 100

window : receiver + congestion window : sender

slide-101
SLIDE 101

window = the maximum amount of un-ACKed data in flight.

slide-102
SLIDE 102

min(window, cwnd) = the maximum amount of un-ACKed data in flight.

slide-103
SLIDE 103

Congestion window: Slow start Congestion avoidance Fast retransmit Fast recovery

slide-104
SLIDE 104

Tahoe Reno Vegas New Reno Westwood BIC/CUBIC (Linux 2.6.19) Compound TCP (Vista)

slide-105
SLIDE 105

RFC 2851 - TCP Congestion Control RFC 3390 - Increasing TCP's Initial Window

slide-106
SLIDE 106

Congestion window: Slow start Congestion avoidance Fast retransmit Fast recovery

slide-107
SLIDE 107

Slow start: 1) Initialize cwnd to three full segments 2) Increment cwnd by one full segment for each ACK

slide-108
SLIDE 108

Client Server

slide-109
SLIDE 109

Client Server cwnd=3

slide-110
SLIDE 110

Client Server cwnd=3 cwnd=6

slide-111
SLIDE 111

Client Server cwnd=3 cwnd=6 cwnd=12

slide-112
SLIDE 112
slide-113
SLIDE 113
slide-114
SLIDE 114

June 1988 BSD4.3 Tahoe

slide-115
SLIDE 115

November 1988 Congestion Avoidance and Control Van Jacobson Michael J Karels

http://ee.lbl.gov/papers/congavoid.pdf

slide-116
SLIDE 116

November 1989 RFC 1122

slide-117
SLIDE 117

“Recent work by Jacobson on Internet congestion and TCP retransmission stability has produced a transmission algorithm combining „slow start‟ with „congestion avoidance‟. A TCP MUST implement this algorithm.”

  • RFC 1122
slide-118
SLIDE 118

“Recent work by Jacobson on Internet congestion and TCP retransmission stability has produced a transmission algorithm combining „slow start‟ with „congestion avoidance‟. A TCP MUST implement this algorithm.”

  • RFC 1122
slide-119
SLIDE 119
slide-120
SLIDE 120

TCP slow start

slide-121
SLIDE 121

network latency strictly limits the throughput of new connections

slide-122
SLIDE 122

Client Server cwnd=3 1 round trip

slide-123
SLIDE 123

No problem! Send bigger packets

slide-124
SLIDE 124

“… the maximum length of an IP datagram sent over an Ethernet is 1500 octets”

  • RFC 894
slide-125
SLIDE 125

Client Server cwnd=3 1 round trip

Assuming 1460 byte segments

slide-126
SLIDE 126

No problem! It’s only on the first hit

slide-127
SLIDE 127

Yahoo 2007: One hit in five is uncached

http://www.yuiblog.com/blog/2007/01/04/performance-research-part-2/

slide-128
SLIDE 128

If average session length is N,

(and you assume equal probability of departure on each hit)

then 1 hit in N is a first hit

slide-129
SLIDE 129

No problem! It’s only five round trips until the window is fully open

slide-130
SLIDE 130

The window field in the TCP header is 16 bits

slide-131
SLIDE 131

2**16 = 65536 1460 = 44 segments

slide-132
SLIDE 132

Round Trip Congestion window size 1 3 2 6 3 12 4 24 5 44

slide-133
SLIDE 133

Round Trip Congestion window size 1 3 2 6 3 12 4 24 5 44

slide-134
SLIDE 134

Delayed ACK RFC 813, July 1982

slide-135
SLIDE 135

“…overly frequent acknowledgement …greatly increases the processing time at the sender's end.”

  • RFC 813
slide-136
SLIDE 136

Client Server

slide-137
SLIDE 137

Client Server

slide-138
SLIDE 138

Client Server

slide-139
SLIDE 139

Client Server

slide-140
SLIDE 140

Client Server

slide-141
SLIDE 141

Client Server

slide-142
SLIDE 142

Client Server

slide-143
SLIDE 143

Client Server

slide-144
SLIDE 144

Client Server

slide-145
SLIDE 145

Client Server

slide-146
SLIDE 146

Client Server

slide-147
SLIDE 147

Client Server

slide-148
SLIDE 148

Client Server

slide-149
SLIDE 149

“A TCP SHOULD implement a delayed ACK”

  • RFC 1122
slide-150
SLIDE 150

When a packet arrives, delay your ACK

slide-151
SLIDE 151

When a packet arrives, delay your ACK BUT

slide-152
SLIDE 152

When a packet arrives, delay your ACK BUT If another packet arrives while you’re waiting, ACK both right away.

slide-153
SLIDE 153

Client Server cwnd=3

slide-154
SLIDE 154

Client Server cwnd=3

slide-155
SLIDE 155

Client Server cwnd=3

slide-156
SLIDE 156

Client Server cwnd=3 cwnd=4

slide-157
SLIDE 157

Client Server cwnd=3 cwnd=4

slide-158
SLIDE 158

Client Server cwnd=3 cwnd=4 cwnd=5

slide-159
SLIDE 159

Client Server cwnd=3 cwnd=4 cwnd=6

slide-160
SLIDE 160

Client Server cwnd=3 cwnd=4 cwnd=6 cwnd=9

slide-161
SLIDE 161

Round Trip Congestion window size 1 3 2 4 3 6 4 9 5 13 6 19 7 28 8 42 9 44

slide-162
SLIDE 162

TCP slow start and delayed ACK

slide-163
SLIDE 163

network latency strictly limits the throughput of new connections

slide-164
SLIDE 164

3 6 12 21 33 51 78 120 164 208 50 100 150 200 250 1 2 3 4 5 6 7 8 9 10 11 Segments Round trips

Minimum Round Trips To Deliver N Segments

slide-165
SLIDE 165
slide-166
SLIDE 166

51 Kb

(just the HTML)

slide-167
SLIDE 167

Accept-Encoding: gzip,deflate

slide-168
SLIDE 168

Raw HTML: 51Kb Gzipped: 11Kb

slide-169
SLIDE 169

50 100 150 200 250 1 2 3 4 5 6 7 8 9 10 11 Segments Round trips

Minimum Round Trips To Deliver N Segments

whitehouse.gov 11Kb compressed 8 1,460 byte segments

slide-170
SLIDE 170
slide-171
SLIDE 171

210 Kb

(just the HTML)

slide-172
SLIDE 172

50 100 150 200 250 1 2 3 4 5 6 7 8 9 10 11 Segments Round trips

Minimum Round Trips To Deliver N Segments

Wikipedia: White House 44Kb compressed 31 1,460 byte segments

slide-173
SLIDE 173
slide-174
SLIDE 174
slide-175
SLIDE 175

What to do about it?

slide-176
SLIDE 176

1) Carefully consider every byte of content

slide-177
SLIDE 177

3 6 12 21 33 51 78 120 164 208 50 100 150 200 250 1 2 3 4 5 6 7 8 9 10 11 Segments Round trips

Minimum Round Trips To Deliver N Segments

slide-178
SLIDE 178
slide-179
SLIDE 179

Accept-Encoding: gzip,deflate

slide-180
SLIDE 180

Tony Gentilcore: ~15% of users don’t do gzip

http://en.oreilly.com/velocity2009/public/schedule/detail/9072

slide-181
SLIDE 181

Software Accept-Encoding modification Ad Muncher Stripped CA Internet Security Suite Accept-EncodXng: gzip, deflate CEQURUX Stripped Citrix Application Firewall Stripped ISA 2006 Stripped McAfee Internet Security 6.0 XXXXXXXXXXXXXXX: +++++++++++++ Norton Internet Security 2005

  • --------------: -------------

Novell iChain 2.3 Stripped Novell Client Firewall Stripped WebWasher Stripped ZoneAlarm Pro 5.5 XXXXXXXXXXXXXXX: XXXXXXXXXXXXX

Source: http://en.oreilly.com/velocity2009/public/schedule/detail/9072

slide-182
SLIDE 182

1) Carefully consider every byte of content

slide-183
SLIDE 183

2) Think about what goes into those first few packets

slide-184
SLIDE 184

2.1) Keep your cookies small

slide-185
SLIDE 185

2.2) Open connections for assets in the first three packets

slide-186
SLIDE 186

2.3) Download small assets first

slide-187
SLIDE 187

3) Accept the speed of light

slide-188
SLIDE 188

Meta lessons

slide-189
SLIDE 189

1) If your application is delivered on the web, you need to understand how the network functions

slide-190
SLIDE 190

2) Humility

slide-191
SLIDE 191

end