CORNELL CS 5190 - Lecture 5 Transport: TCP performance

Unformatted text preview:

1CS519: Computer NetworksLecture 5, Part 3: Mar 10, 2004Transport: TCP performance CS519TCP performance| We’ve seen how TCP “the protocol” works| But there are a lot of tricks required to make it work wellz Indeed, the Internet nearly died an early death because of bad TCP performance problemsCS519TCP performance| Making interactive TCP efficient for low-bandwidth links| Filling the pipe for bulk-data applications| Estimating round trip time (RTT)| Keeping the pipe full| Avoiding congestionCS519Interactive TCP| Interactive applications like telnet or RPC send only occasional data| Data sent in both directions| Data often very small| Packet overhead is huge for small packetsz <3% efficiency for a 1-byte data packetz This is bad for low-bandwidth links2CS519Who cares about low-BW links?| Historically low-BW links were a serious problemz As access links got faster, people worried less about this| Ubiquitous computing over TCP/IP wireless links makes this interesting againz Low-power devicesCS519Transmit versus wait| One basic engineering tradeoff is to wait before transmitting| Wait for more data to send a bigger packet| Hold off on the ACK so that data can be piggybacked with the ACK| This is not an easy tradeoff to make---you can only go so far with this approachCS519TCP/IP header compression| A better approach is to “compress” the TCP and IP headers (RFC 1144, 2507 - 2509)| Basic idea is to:z not transmit fields that don’t change from packet to packet, z and to transmit only the deltas of those fields that do changeCS519TCP/IP compression components3CS519TCP header compression| How much compression can we get out of TCP/IP| From 40 bytes to:z 20 bytes?z 10 bytes?z 5 bytes?z 2 bytes?CS519TCP/IP fields that don’t changeThis cuts the header in half!CS519More compression| Total length not needed because link layer transmits that (2 bytes)| IP checksum not needed because there isn’t much left to checksum (2 more bytes)CS519Compression header4CS519Compression issues| The main issue is how to deal with errors| Once an error occurs, the decompressor can’t recover unless a new complete packet is sent| RFC1144 has a clever solution to this . . .CS519When to schedule transmission| As we saw, TCP segment transmit doesn’t have to correspond to app send()| When should TCP send a fragment?z As soon as it gets data to send?z As soon as it has a packet’s worth to send (MSS Max Segment Size)?z Not until some timer goes off?CS519When to schedule transmission| If TCP sends right away, it may send many small packets| If TCP waits for a full MSS, it may delay important data| If TCP waits for a timer, then bad behavior can resultz Lots of small packets get sent anywayz Silly Window SyndromeCS519Silly Window Syndrome| This is a nice situation:z (nice big packets, full pipe)5CS519Silly Window Syndrome| Imagine this situation:z How could we get out of it???CS519Silly Window Syndrome| Small packets introduced into the loop tend to stay in the loop| How do small packets get introduced into the loop?CS519Silly Window Syndrome: Small packet introducedCS519Silly Window Syndrome prevention| Receiver and sender both wait until they have larger segments to ACK or send| Receiver:z Receiver will not advertise a larger window until the window can be increased by one full-sized segment orz by half of the receiver’s buffer space whichever is smaller6CS519Silly Window Syndrome prevention| Sender:z Waits to transmit until either a full sized segment (MSS) can be sent orz at least half of the largest window ever advertised by the receiver can be sent orz it can send everything in the bufferCS519When to schedule transmission (again)| App can force sender to send immediately when data is availablez Sockopt TCP_NODELAY| Otherwise, sender sends when a full MSS is available| Or when a timer goes offz But with silly window constraints…CS519TCP: Retransmission and TimeoutsHost AHost BACKRound-trip time (RTT)ACKRetransmission TimeOut (RTO)Estimated RTTData1 Data2Guard BandTCP uses an adaptive retransmission timeout value:CongestionChanges in RoutingRTT changes frequentlyNext few slides from Nick McKeown, StanfordCS519TCP: Retransmission and TimeoutsPicking the RTO is important:  Pick a values that’s too big and it will wait too long to retransmit a packet,  Pick a value too small, and it will unnecessarily retransmit packets.The original algorithm for picking RTO:1. EstimatedRTTk= α EstimatedRTTk-1+ (1 - α) SampleRTT2. RTO = 2 * EstimatedRTTCharacteristics of the original algorithm: Variance is assumed to be fixed. But in practice, variance increases as congestion increases.Determined empirically7CS519TCP: Retransmission and Timeouts There will be some (unknown) distribution of RTTs. We are trying to estimate an RTO to minimize the probability of a false timeout.RTTProbabilitymeanvarianceLoad(Amount of trafficarriving to router)Average Queueing DelayVariance grows rapidly with loadRouter queues grow when there is more traffic, until they become unstable. As load grows, variance of delay growsrapidly.CS519TCP: Retransmission and TimeoutsKarn’s AlgorithmRetransmissionWrong RTT SampleHost A Host BRetransmissionWrong RTT SampleHost A Host BProblem:How can we estimate RTT when packets are retransmitted?Solution:On retransmission, don’t update estimated RTT (and double RTO).CS519TCP: Retransmission and TimeoutsNewer Algorithm includes estimate of variance in RTT: Difference = SampleRTT - EstimatedRTT EstimatedRTTk= EstimatedRTTk-1+ (δ*Difference) Deviation = Deviation + δ*( |Difference| - Deviation ) RTO = µ * EstimatedRTT + φ * Deviationµ ≈ 1φ ≈ 4Same as beforeCS519Fast implementation of thisSampleRTT -= (EstimatedRTT >> 3);EstimatedRTT += SampleRTT;if (SampleRTT < 0)SampleRTT = -SampleRTT;SampleRTT -= (Deviation >>3);Deviation += SampleRTT;TimeOut = (EstimatedRTT >> 3) + (Deviation >> 1);8CS519Fast implementation of this| Note no floating point arithmetic, just adds, subtract, and shift!| Also, TCP implementations use “header prediction” to gain execution speedSampleRTT -= (EstimatedRTT >> 3);EstimatedRTT += SampleRTT;if (SampleRTT < 0)SampleRTT = -SampleRTT;SampleRTT -= (Deviation >>3);Deviation += SampleRTT;TimeOut = (EstimatedRTT >> 3) + (Deviation >> 1);CS519Fast Retransmit| Even with all this fancy RTT estimation, retransmits still tend to over-estimate, and TCP can stall while waiting for a time-outz Stall because pipe often bigger than


View Full Document

CORNELL CS 5190 - Lecture 5 Transport: TCP performance

Download Lecture 5 Transport: TCP performance
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 5 Transport: TCP performance and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 5 Transport: TCP performance 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?