1CS514: Intermediate Course in Computer SystemsLecture 6: Sept. 17, 2003“Performance of the Internet WAN”CS514What performance are we interested in?| Latencyz Small web accessz Interactive voice/video or gaming| Jitter (variation in inter-packet arrival)z Interactive voice/videoz Streaming could benefit (less buffering)| Throughputz Large web accessz Interactive or streaming video| Problemsz Packet loss, outages, out-of-order packets, packet corruption2CS514This lecture| Shows why measuring performance is difficult| Shows how some of the measurement takes place| Tries to give some sense of how well the internet worksz Though really nobody knows!!!CS514Email with Vern Paxson*Q: What are the best papers for describing the performance of the internet more generally?A: There's no broad-perspective available like that. Very hard to do, given the immense diversity and difficulty of attaining sufficient measurement perspectives.* God of internet measurement3CS514Paxson 1994-1995 Study| 35 sites| Measured TCP bulk transfersz Idea is that measurements of TCP can be applied to understanding TCP as well as understanding the Internetz Problem though is that TCP backs-off, so don’t have complete control over your measuring tool| Built filter to measure exact timesz Some packets missed by filter, but this is detectableCS514TCP-centric measurementsSimple UDP or ICMP-based measurements don’t tell you how well TCP will perform| You have to look at things that will hurt TCP performance:z Out of order deliveryz Replication (rare, it turns out)z Packet corruption4CS514Out of order delivery: Why does TCP care?S RX12ack(1)3ack(1)2S R12ack(1)3ack(1)2If packet lost, best strategy is to retransmit immediately after duplicate ACKIf packet reordered, best strategy is to wait for another ACKCS514Out of order delivery| It does happen (~0.2% in 1995)z Route changes? Path splitting? | It varies a lot (up to 15% seen)z Thus nice if TCP could measure it dynamically| Different in either direction1. Asymmetric paths2. Data more frequently reordered than ACKsz Therefore can’t determine sending reorder rate from measuring received reorder rate5CS514Packet corruption| Happens (1 in 5000 data packets)z Since 16-bit TCP checksum misses 1/65000 errors, 1/300M corrupted packets go undetectedz Not a lot, but if your data is important, check at higher layersz Encryption will do this for you| Happens much less for short packets (TCP ACKs)z Suggests that corruption happens in routersz Because link-layer checksum shouldn’t care about packet lengthCS514Measuring bottleneck bandwidth: principleSend two packets withina short time spaceBottleneck link will increase the spacingMeasured receive spacing tells you the size of the bottleneck link6CS514Why do we care?| If we want to understand effect of queuing delays, processing delays, etc., we must know bottleneck bandwidthz For instance, difference between bottleneck BW and available BW tells what fraction of the bottleneck link we got| TCP never wants to send faster than the bottleneck bandwidthz Though often TCP wants to send much slower because of competing traffic (available bandwidth)CS514Why is it hard?In part, because any competing traffic changes the spacing7CS514| Multi-channel effects| Bottleneck may changez Route changez Dynamic bandwidth allocation (ISDN)| Poor clock resolution| Out-of-order deliveryOther complicationsCS514Hard to do at one end| If ICMP echo, can’t tell in which direction bottleneck occurs| If TCP, ACK spacing may be compressed on return pathz Queue emptying effect8CS514Basic approach to bottleneck bandwidth est.| Send stream of evenly spaced packetsz Look for smallest spacing| If possible link bandwidths known apriori, then look for peaks near these speedsz (modem speeds, T1, E1, multiples of these, Ethernet, etc.)| This actually works pretty wellz But impossible to do good bottleneck bandwidth estimation without loading the networkCS514Measuring packet loss| Not real hardz Though can’t use TCP data to measure loss rate, because TCP backs off in order to prevent lossz But can use ACKs• If loss in both directions is not correlated, which is the case| Lots of variation| Lots of correlation z Likelihood packet is lost if predecessor was lostz 25%-50%z But this is pre-RED9CS514One-way Transit Time (Latency)| To do with absolute accuracy, required synchronized clocksz GPS, which is fairly inexpensive these days (<$500)| Paxson didn’t have thisz But with analysis could determine relative skew between clocksz Basically by sampling only packet round trips with low and similar delay, and tracking timestamps against these| He really only measured relative OTTCS514Other Paxson ’97 factoids| Queuing time scalesz Period of time over which a queue’s delay changesz We care because if time is too small, no point in trying to adaptz Typically 0.1 – 1 sec, but can be much larger• 60 second spike, but due to routing oscillations10CS514Other Paxson ’97 factoids| Available bandwidthz Percentage of bottleneck bandwidth allocated to a given connectionz Essentially actual_bw/bottleneck_bwz Wide range:• From 5% to 100%• Less as bottleneck BW growsCS514Large scale measurement now common| Many ongoing measurement projectsz NIMI (Paxson), RIPE TTM, Caida skitter, etc.| Standard measurement metricsz IP Performance Metrics (IPPM)z RFC 2330: IPPM Frameworkz Basic concepts and termsz Allows results from different measurement infrastructures to be meaningfully compared and combined11CS514IPPM Metrics• RFC 2678: IPPM Metrics for Measuring Connectivity• RFC 2679: A One-way Delay Metric for IPPM• RFC 2680: A One-way Packet Loss Metric for IPPM• RFC 2681: A Round-trip Delay Metric for IPPM• Series ended in 1999, with metrics clearly missing• Bandwidth especially, also jitter, packet order, packet corruption, …CS514Internet Flow Rates| Zhang, Breslau, Paxson, Shenker| Study of flow rates and sizes | Particular interest in causes of different flow characteristics| Traced flows at ISPs and campus access links| Developed a tool (T-RAT) to analyze cause of rate limitinghttp://www.research.att.com/projects/T-RAT/Subsequent slides taken from Sigcomm 2002 presentation12CS514Internet Flow Rates Data Set| Packet traces at ISP backbones and campus access linksz 8 datasets; each lasts 0.5 – 24 hours; over 110 million packets| Summary flow statistics collected at 19 backbone routersz 76 datasets; each lasts 24 hours; over 20 billion
View Full Document
Unlocking...