Results 11 - 20
of
133
The Devil and Packet Trace Anonymization
, 2006
"... Releasing network measurement data---including packet traces--- to the research community is a virtuous activity that promotes solid research. However, in practice, releasing anonymized packet traces for public use entails many more vexing considerations than just the usual notion of how to scramble ..."
Abstract
-
Cited by 64 (3 self)
- Add to MetaCart
Releasing network measurement data---including packet traces--- to the research community is a virtuous activity that promotes solid research. However, in practice, releasing anonymized packet traces for public use entails many more vexing considerations than just the usual notion of how to scramble IP addresses to preserve privacy. Publishing traces requires carefully balancing the security needs of the organization providing the trace with the research usefulness of the anonymized trace. In this paper we recount our experiences in (i) securing permission from a large site to release packet header traces of the site's internal traffic, (ii) implementing the corresponding anonymization policy, and (iii) validating its correctness. We present a general tool, tcpmkpub, for anonymizing traces, discuss the process used to determine the particular anonymization policy, and describe the use of meta-data accompanying the traces to provide insight into features that have been obfuscated by anonymization.
Inferring TCP Connection Characteristics through Passive Measurements
, 2004
"... We propose a passive measurement methodology to infer and keep track of the values of two important variables associated with a TCP connection: the sender's congestion window (cwnd) and the connection round trip time (RTT). Together, these variables provide a valuable diagnostic of end-user-perceive ..."
Abstract
-
Cited by 63 (7 self)
- Add to MetaCart
We propose a passive measurement methodology to infer and keep track of the values of two important variables associated with a TCP connection: the sender's congestion window (cwnd) and the connection round trip time (RTT). Together, these variables provide a valuable diagnostic of end-user-perceived network performance. Our methodology is validated via both simulation and concurrent active measurements, and is shown to be able to handle various flavors of TCP. Given our passive approach and measurement points within a Tier-1 network provider, we are able to analyze more than 10 million connections, with senders located in more than 45% of the autonomous systems in today's Internet. Our results indicate that sender throughput is frequently limited by a lack of data to send, that the TCP congestion control flavor often has minimal impact on throughput, and that the vast majority of connections do not experience significant variations in RTT during their lifetime.
Open Issues on TCP for Mobile Computing
- JOURNAL OF WIRELESS COMMUNICATIONS AND MOBILE COMPUTING
, 2002
"... We discuss the design principles of TCP within the context of heterogeneous wired/wireless networks and mobile networking. We identify three shortcomings in TCP's behavior: (i) the protocol's error detection mechanism, which does not distinguish different types of errors and thus does not suffice fo ..."
Abstract
-
Cited by 60 (26 self)
- Add to MetaCart
We discuss the design principles of TCP within the context of heterogeneous wired/wireless networks and mobile networking. We identify three shortcomings in TCP's behavior: (i) the protocol's error detection mechanism, which does not distinguish different types of errors and thus does not suffice for heterogeneous wired/wireless environments, (ii) the error recovery, which is not responsive to the distinctive characteristics of wireless networks such as transient or burst errors due to handoffs and fading channels, and (iii) the protocol strategy, which does not control the tradeoff between performance measures such as goodput and energy consumption, and often entails a wasteful effort of retransmission and energy expenditure. We discuss a solution-framework based on selected research proposals and the associated evaluation criteria for the suggested modifications. We highlight an important angle that did not attract the required attention so far: the need for new performance metrics, appropriate for evaluating the impact of protocol strategies on battery-powered devices.
RR-TCP: A Reordering-Robust TCP with DSACK
, 2003
"... TCP performs poorly on paths that reorder packets significantly, where it misinterprets out-of-order delivery as packet loss. The sender responds with a fast retransmit though no actual loss has occurred. These repeated false fast retransmits keep the sender’s window small, and severely degrade the ..."
Abstract
-
Cited by 55 (2 self)
- Add to MetaCart
TCP performs poorly on paths that reorder packets significantly, where it misinterprets out-of-order delivery as packet loss. The sender responds with a fast retransmit though no actual loss has occurred. These repeated false fast retransmits keep the sender’s window small, and severely degrade the throughput it attains. Requiring nearly in-order delivery needlessly restricts and complicates Internet routing systems and routers. Such beneficial systems as multi-path routing and parallel packet switches are difficult to deploy in a way that preserves ordering. Toward a more reordering-tolerant Internet architecture, we present enhancements to TCP that improve the protocol’s robustness to reordered and delayed packets. We extend the sender to detect and recover from false fast retransmits using DSACK information, and to avoid false fast retransmits proactively, by adaptively varying dupthresh. Our algorithm is the first that adaptively balances increasing dupthresh, to avoid false fast retransmits, and limiting the growth of dupthresh, to avoid unnecessary timeouts. Finally, we demonstrate that TCP’s RTO estimator tolerates delayed packets poorly, and present enhancements to it that ensure it is sufficiently conservative, without using timestamps or additional TCP header bits. Our simulations show that these enhancements significantly improve TCP’s performance over paths that reorder or delay packets. 1. Introduction and
TCP-LP: A Distributed Algorithm for Low Priority Data Transfer
, 2003
"... Service prioritization among different traffic classes is an important goal for the future Internet. Conventional approaches to solving this problem consider the existing best-effort class as the low-priority class, and attempt to develop mechanisms that provide "better-than-best-effort" service. In ..."
Abstract
-
Cited by 54 (3 self)
- Add to MetaCart
Service prioritization among different traffic classes is an important goal for the future Internet. Conventional approaches to solving this problem consider the existing best-effort class as the low-priority class, and attempt to develop mechanisms that provide "better-than-best-effort" service. In this paper, we explore the opposite approach, and devise a new distributed algorithm to realize a low-priority service (as compared to the existing best effort) from the network endpoints. To this end, we develop TCP Low Priority (TCP-LP), a distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for congestion indications and a TCP-transparent congestion avoidance policy. Our simulation results show that: (1) TCP-LP is largely non-intrusive to TCP traffic; (2) both single and aggregate TCP-LP flows are able to successfully utilize excess network bandwidth; moreover, multiple TCP-LP flows share excess bandwidth fairly; (3) substantial amounts of excess bandwidth are available to low-priority class, even in the presence of "greedy" TCP flows; (4) the response times of web connections in the best-effort class decrease by up to 90% when long-lived bulk data transfers use TCP-LP rather than TCP.
TCP Performance over Satellite Links
, 1997
"... Over the past few years, we have reported on the performance issues faced by TCP/IP based applications on satellite links. Performance is limited by the delay inherent in geosynchronous systems and the probability of bit errors found in any wireless system, including satellite systems. These limitat ..."
Abstract
-
Cited by 49 (13 self)
- Add to MetaCart
Over the past few years, we have reported on the performance issues faced by TCP/IP based applications on satellite links. Performance is limited by the delay inherent in geosynchronous systems and the probability of bit errors found in any wireless system, including satellite systems. These limitations are becoming more important as new satellite systems offer much higher data transmission rates than those available in the past. While high efficiency on fast satellite links may eventually require new protocol modifications, our previous studies indicate that full link utilization may be achievable using the TCP performance enhancements that have already been approved or that are currently in the standards process. Of particular interest in the satellite environment are performance enhancements for scaled windows and timestamps (RFC 1323), fast retransmit and recovery (RFC 2001), and selective acknowledgement (RFC 2018). The paper describes each of these performance enhancements and ex...
An Application-Level Solution to TCP's Satellite Inefficiencies
, 1997
"... In several experiments using NASA's Advanced Communications Technology Satellite (ACTS), investigators have reported disappointing throughput using the TCP/IP protocol suite over T1 satellite circuits. A detailed analysis of FTP file transfers reveals that the TCP receive window size, the TCP "Slow ..."
Abstract
-
Cited by 46 (4 self)
- Add to MetaCart
In several experiments using NASA's Advanced Communications Technology Satellite (ACTS), investigators have reported disappointing throughput using the TCP/IP protocol suite over T1 satellite circuits. A detailed analysis of FTP file transfers reveals that the TCP receive window size, the TCP "Slow Start" algorithm, and the TCP acknowledgment mechanism contribute to the observed limits in throughput. To further explore TCP's limitations over satellite circuits, we developed a modified version of FTP (XFTP) that uses multiple TCP connections. By using multiple TCP connections, we have been able to simulate a large, virtual TCP receive window. Our experiences with XFTP over both actual satellite circuits and a software satellite emulator show that a utilization of better than 90% is possible. Our results also indicate the benefit of introducing congestion avoidance at the application level. 1 Introduction In several experiments using NASA's Advanced Communications Technology This wor...
Hot or not: Revealing hidden services by their clock skew
- In 13th ACM Conference on Computer and Communications Security (CCS 2006
, 2006
"... Location-hidden services, as offered by anonymity systems such as Tor, allow servers to be operated under a pseudonym. As Tor is an overlay network, servers hosting hidden services are accessible both directly and over the anonymous channel. Traffic patterns through one channel have observable effec ..."
Abstract
-
Cited by 46 (2 self)
- Add to MetaCart
Location-hidden services, as offered by anonymity systems such as Tor, allow servers to be operated under a pseudonym. As Tor is an overlay network, servers hosting hidden services are accessible both directly and over the anonymous channel. Traffic patterns through one channel have observable effects on the other, thus allowing a service’s pseudonymous identity and IP address to be linked. One proposed solution to this vulnerability is for Tor nodes to provide fixed quality of service to each connection, regardless of other traffic, thus reducing capacity but resisting such interference attacks. However, even if each connection does not influence the others, total throughput would still affect the load on the CPU, and thus its heat output. Unfortunately for anonymity, the result of temperature on clock skew can be remotely detected through observing timestamps. This attack works because existing abstract models of anonymitynetwork nodes do not take into account the inevitable imperfections of the hardware they run on. Furthermore, we suggest the same technique could be exploited as a classical covert channel and can even provide geolocation.
Measuring the evolution of transport protocols in the Internet
- ACM Computer Communication Review
, 2005
"... In this paper we explore the evolution of both the Internet’s most heavily used transport protocol, TCP, and 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 ..."
Abstract
-
Cited by 44 (5 self)
- Add to MetaCart
In this paper we explore the evolution of both the Internet’s most heavily used transport protocol, TCP, and 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.). In addition, we investigate the prevalence and correctness of implementations using proposed TCP algorithmic and protocol changes (e.g., selective acknowledgment-based loss recovery, congestion window growth based on byte counting, etc.). We present results of measurements taken using an active measurement framework to study web servers and a passive measurement survey of clients accessing information from our web server. 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. Finally, we present several lessons that will benefit others taking Internet measurements.
A receiver-centric transport protocol for mobile hosts with heterogeneous wireless interfaces
- In ACM Mobicom
, 2003
"... Numerous transport protocols have been proposed in related work for use by mobile hosts over wireless environments. A common theme among the design of such protocols is that they specifically address the distinct characteristics of the last-hop wireless link, such as random wireless errors, round-tr ..."
Abstract
-
Cited by 43 (3 self)
- Add to MetaCart
Numerous transport protocols have been proposed in related work for use by mobile hosts over wireless environments. A common theme among the design of such protocols is that they specifically address the distinct characteristics of the last-hop wireless link, such as random wireless errors, round-trip time variations, blackouts, handoffs, etc. In this paper, we argue that due to the defining role played by the wireless link on a connection’s performance, locating the intelligence of a transport protocol at the mobile host that is adjacent to the wireless link can result in distinct performance advantages. To this end, we present a receiver-centric transport protocol called RCP (Reception Control Protocol) that is a TCP clone in its general behavior, but allows for better congestion control, loss recovery, and power management mechanisms compared to sender-centric approaches. More importantly, in the context of recent trends where mobile hosts are increasingly being equipped with multiple interfaces providing access to heterogeneous wireless networks, we show that a receiver-centric protocol such as RCP can enable a powerful and comprehensive transport layer solution for such multi-homed hosts. Specifically, we describe how RCP can be used to provide: (i) a scalable solution to support interface specific congestion control for a single active connection; (ii) seamless server migration capability during handoffs; and (iii) effective bandwidth aggregation when receiving data through multiple interfaces, either from one server, or from multiple replicated servers. We use both packet level simulations, and real Internet experiments to evaluate the proposed protocol.

