Measuring interactions between transport protocols and middleboxes

Abstract

In this paper we explore the current network environment with respect to how the network's evolution ultimately impacts end-to-end protocols. The traditional end-to-end assumptions about the Internet are increasingly challenged by the introduction of intermediary network elements (middleboxes) that intentionally or unintentionally prevent or alter the behavior of end-to-end communications. This paper provides measurement results showing the impact of the current network environment on a number of traditional and proposed protocol mechanisms (e.g., Path MTU Discovery, Explicit Congestion Notification, etc.). We present results of measurements taken using an active measurement framework to study web servers. We analyze our results to gain further understanding of the differences between the behavior of the Internet in theory versus the behavior we observed through measurements. In addition, these measurements can be used to guide the definition of more realistic Internet modeling scenarios.

Measuring the state of ECN readiness in servers, clients,and routers

“…Therefore we used Scamper's [18] ICMP-paris traceroute mode [3] (even though ICMP packets would not normally be ECN marked) since it was likely to discover more hops. [21] and 2008 [17] for comparison purposes. The number of servers which negotiated ECN rose to between 14% to 17% in all web server populations.…”

Quick-Start for TCP and IP

“…Measurement studies of interactions between transport protocols and middleboxes [MAF04] show that for 70% of the Web servers investigated, no connection is established if the TCP SYN packet contains an unknown IP option (and for 43% of the Web servers, no connection is established if the TCP SYN packet contains an IP TimeStamp Option). In both cases, this is presumably due to routers or middleboxes along that path.…”

“…Alternately, the sender could resend the dropped packet with only the ECN request in the TCP header, resending the TCP SYN packet without either the Quick-Start or the ECN requests if the second TCP SYN packet is dropped. The second choice seems reasonable, given that a TCP SYN packet today is more likely to be blocked due to policies that discard packets with IP Options than due to policies that discard packets with ECN requests in the TCP header [MAF04].…”

“…The cost of having a Quick-Start Request packet dropped: Measurement studies cited earlier [MAF04] suggest that on a wide range of paths in the Internet, TCP SYN packets containing unknown IP options will be dropped. Thus, for the sender one risk in using Quick-Start is that the packet carrying the Quick-Start Request could be dropped in the network.…”

Analysis of ICMP Quotations

“…Using tcptraceroute, the paths to 84393 web servers used in a previous study [1] were traced serially between the 6th and 12th of May 2005. All TCP SYN packets sent from the measurement source, as well as all ICMP time exceeded, unreachable, source quench, redirect, and parameter problem messages were recorded using tcpdump.…”