TCP Response Under Loss Conditions

Curtis Villamizar

Table of Contents

• Slides from this talk
• Stan Barber's Notes
• February 1997 NANOG Home Page

Stan Barber's Notes

This is more of a tutorial. There seems to be some misunderstanding how TCP acks under congestion.

References

• RFC 2001 is a good resource, but you need to look at a number of academic papers, BSD 4.4 Lite, and TCP Illustrated by Stevens.
• 1981 - base TCP RFC (RFC 793)
• 1988 congestion collapse predicted and observed
• 1988 slow start and congestion avoidance
• 1990 Fast retransmit TCP (TCP Tahoe)

States of a TCP Connection

• Connection established
• 3 packet exchanges
  • SYN, SYN-ACK, ACK
• negotiate initial sequence numbers and options
• data can be sent with the last ACK (in principle)
• Established
• Data is exchanged
• Connection closed

• Loss during Connection Establish
• SYN, retransmit
• Timeout at 6, 24 or 48 seconds
• must establish in 75 seconds or fails
• SYN-ACK
• Same timers
• most useful if the last ack is lost

At high to extreme loss probability of delay in getting established in quite high. At 15% loss chances of connection is 2-3%.

Since most all providers are below 5% loss, it is unlikely that you can’t get a connection. There is a "first-packet" problem due to caching routers, but the probability of not getting a connection is still very small.

There are three techniques used when there are duplicates ACKs due to an isolated drop: fast retransmits, fast recover, enter congestion avoidance.

Window size in TCP should look like a saw-tooth function.

The achieved bandwidth is still going to limited by the effective window size divided by the packet round trip time (and is independent of the size of the pipe, when there is no congestion). This is true for any protocol that sends a limited amount of data in an unacknowledged packet.

Under loss, there is not a collapse, but things do get slower. For smaller window sizes (dialup customers), loss affects them more than large window sizes.

Bill Norton notes that a growing number of systems are using TCPs that are not based on BSD 4.4 lite. Curtis notes that he is not an expert on non-BSD TCPs, but he has heard that one popular implementation does not do fast retransmit and that alone will cause those users to observe problems much more quickly that those that use BSD implementations. He also notes that some PC platform implementations are much more aggressive than BSD and that is generally good.

Kent England and John Hawkinson note that the small difference in size of windows (between 512 and 1500) doesn'y make much difference in performance, but getting to large windows it does make a difference.

John Hawkinson notes that having a large MSS sending to clients with small window sizes may result in worst performance.

Curtis has noted that one possibility it to reduce MSS when window size is small. It is important that from an operator perspective, loss should be kept down, but it is not a catastrophic occurrence when loss does happen. He also notes that IPPM will be doing work to provide testing on these issues to find the best basis from which to validate these various models.

[SLIDES ON ftp.eng.ans.net]