Outline
• TCP Timers
HTTP/TCP Interactions
– Retransmission Timer
– Slow-Start Restart
– TIME_WAIT State
• HTTP/TCP Layering
– Aborted HTTP transfers
– Nagle’s algorithm
– Delayed ACKs
• Multiplexing Multiple Connections
• Server Overheads
So Far…
• HTTP runs over TCP
– TCP: defined in the`80s with other applications in
mind
• FTP, telnet
• HTTP 1.0
– poor use of TCP for short responses
• 1 connection for request
• TCP always in slow start
TCP Timers
Timers for:
1. Retransmission of lost packets
2. Repeating the slow start phase
– After inactivity period
3. Reclaiming state from a terminated
connection
4. Control transmission of delay ack
• HTTP 1.1
– Use of persistent connections w/o pipelining
• How do these timers affect Web
Performance?
Retransmission Timer (RTO)
Delay for New Connection
• TCP 3-way handshake
• Time required for TCP sender to detect
packet loss
– Except when done via 3-duplicate ack
– SYN -> SYN-ACK -> ACK
• With no loss request after 1RTT
• Loss of SYN or SYN-ACK
– Loss detected only by timeout
• Initial window is 1!!!
– What is the initial RTO value?
1. Delay in establishing a TCP connection
2. Delay in the middle of a WEB transfer
• 3sec!!!
– What happen to RTO after a retransmission
• It doubles!!!
• What happen with multiple losses?
– No much effect for non-interactive applications
– Devastating for Web performance
server
SYN-ACK
SYN SYN
client
Delay for New Connection
• Causes
– Congestion at critical links
• Access links, peering points
– Web servers discarding SYN when the incoming queue
is full
• (Remedy)
– Stop and Reload
• Abort connection and start a new one
– Sends a new SYN before the 3 sec
– Effects?
• …
T
SYN
SYN
2T
4T
Delay in the Middle of a WEB Transfer
• Long retransmission timeout are less likely
– RTT estimation refines RTO values
– 3-duplicate ack reduce timeout events
• …but, do we ever get to this stage?
– Most Web-transfers (8-12KB) never get past slowstart
• There might not be enough ack to triggerRTO
retransmission server SYN-ACK
Risposta-1
Risposta-2
SYN
client
ACK Richiesta
ACK-Dup
Risposta-1
Slow-Start Restart
• Persistent connections avoid slow-start
• What happen when sending a request after an
idle period?
Slow-Start Restart
• TCP requires sender to repeat slow-start after
a period of inactivity
1. Connect
2. Download page,
– To avoid overloading the network
– Treat a session re-starting as a new session
• Congestion window grows substantially
3. Read the page for 10 seconds
• …in the meantime network congestion occurs
4. Request another page
• How long the idle period?
– 1 RTO since idle and all previous data acked
› The large congestion window allows too many packets into
the network
• Order of few RTTs
5. More congestion!!!
Slow-Start Restart
• Pros:
Reduce Slow-Start Restart Penalty
1. Disable Slow-Start
– Good for overall network health
• Avoid sudden burst of packets
• Cons:
– Reduces performance gain of persistent
connections
– At server own risk!
2.
3.
4.
5.
Use a Larger Slow-Start Timeout
Gradually Decrease the Congestion Window
Pacing the transmission of packets
A combination of the above
The TIME_WAIT State
• TCP connections state consume memory
• OS need to reclaim resources as soon as
possible
• …but TCP need to maintain state during
connection closing for a period of time
The TIME_WAIT State
• Connection Termination: 2 pair of FIN-ACK
between sender a receiver
• Maintain state after termination to handle
special cases:
– FIN and/or ACK losses
– Duplicate packets arriving after closing
• What if new connection with same IP/ports exists?
The TIME_WAIT State
• One of the hosts need to remember that the
previous connection existed to avoid reuse same
IP/ports
– The one that sent the first FIN
– TIME_WAIT long enough that no packets exists in the
network
• 2 MSL (Maximum Segment Lifetime) 4 minutes
– MSL=2minutes, 1 in some implementations
• Potential large numbers of connections in the TIME_WAIT
state
• Potential limit the number of connections between two
hosts
Effect of TIME_WAIT on WEB Servers
• No persistent connection: Server closes the connection
after response
• Persistent connection: eventually either the client or
the server close it
– Web has incentive to close
• Web servers cannot maintain a persistent connection for each
client
– …Web clients not so
• Web servers closing the connection suffer the burden
of TIME_WAIT state
– Few seconds connection … and 4 minutes TIME_WAIT
state
Reducing TIME_WAIT Overhead
•
•
High performance Web Servers need to
reduce the burden of TIME_WAIT state
Solutions:
1. Lowering the system resources needed
•
•
Memory required: being able to send last ACK and avoid
reusing IP/ports numbers
OS overhead to check for expired timers
2. Shifting the burden to the clients
•
Modify TCP
– Use RST, FIN recipient entering TIME_WAIT state
•
HTTP/TCP Layering
• 3 examples of function implemented at
transport layer effecting (in negative way)
Web performance:
1. Aborted HTTP transfers
2. Nagle’s algorithm
Modify HTTP
– Response header asking the client to close the connection
•
…but in practice: Server OS reduces
TIME_WAIT to 5 seconds
Aborted HTTP Transfers
• Abort HTTP transfer
– Clicking on STOP
– Clicking on a link
• HTTP has no abort mechanism
– Other protocols have one, e.g., Telnet ctrl-c
– Abort would complicate handling of pipelined
requests
• Aborting a request means terminating the TCP
connection
3. Delayed ACKs
Effect of Abort Operations
• Clicking on a link
– Terminates the connection and open a new one
• Even in case of persistent connections
• HTTP request has side effects
• Increment a variable
• Trigger a script that purchase a product
– Have the request been completed?
• Web server may maintain state with this information
Effect of Abort Operations
• Pipelined requests
• Abort one request terminates all requests
– Problem with Proxies pipelining different users’
requests
• User-level abort do not immediately stops the
transfer
– Problem with Proxies having high speed
connection to server and low speed connection to
clients
Nagle’s Algorithm
Solution
• TCP does not send small packets until all
outstanding ACKs are received
– Ensures that at most one small packet is
transmitted per RTT
• Effective when it is needed: interactive
applications over a connection with a long RTT
Nagle’s Algorithm
Motivation
• Reduce the number of small packets by delaying
data transmission
– Small=fewer bytes than 1 MSS
• Deals with interactive applications as Telnet and
Rlogin need to transmit user keystrokes and short
responses
– A packet/keystroke=1byte data+40 bytes overhead
Nagle’s Alg. and Persistent Connection
• Response header and body written using two
system calls
– First packet containing header is transmitted before
second system call
– Body is sent later after an RTT
• Before only if additional data is written in the send buffer
• Same problem in case of single system call for
entire message
– Message transmitted as multiple full-size
messagges+a small final packet
Delayed ACKs
Nagle’s Alg. And Persistent Connection
Motivation
• Reduce the amount of ACKs traffic
• Solution?
Disable Nagle Algorithm…
• But what if several write are used for writing
header/response?
– To reduce overhead (each ACK requires 40byte)
Solution
• Piggybacking the ACK on an outgoing data packet,
but…
• sends an ACK for every other full size data packet
• delay an ACK no more than 500ms
Delayed ACKs and Web traffic
Delayed ACKs and Nagle’s Algorithm
• Separate response header and body packet
cwnd=2 (assume Nagle alg. disabled)
Server
Server
Client
Client
Delayed ACK
Timeout
Transmission
delayed till
ACK arrives
Delayed ACK
Timeout