To efficiently transfer diverse traffic over highspeed links, modern integrated networks require more efficient packet-switching techniques that can capitalize on recent advances in switch hardware. Several promising approaches attempt to improve performance by creating dedicated "shortcut" connections for long-lived traffic flows, at the expense of the network overhead for establishing and maintaining these shortcuts. The network can balance these cost-performance tradeoffs through three tunable parameters: the granularity of flow end-point addresses, the timeout for grouping related packets into flows, and the trigger for migrating a long-lived flow to a shortcut connection. Drawing on a continuous one-week trace of Internet traffic, we evaluate the processor and switch overheads for transferring HTTP server traffic through a flow-switched network. In contrast to previous work, we focus on the full probability distributions of flow sizes and cost-performance metrics to highlight the ...

this paper. The software described in this paper runs on the PacketScope monitor developed by AT&T Labs[1]. The PacketScope is deployed at several different locations within AT&T WorldNet, a production IP network, and AT&T Labs-Research. One PacketScope monitors T3 backbone links, another PacketScope may monitor traffic generated by a large set of modems on a FDDI ring or traffic on other FDDI rings, another PacketScope monitors traffic between AT&T Labs-Research and the Internet. First deployed in Spring 1997, the software has run without interruption for weeks at a time collecting and reconstructing detailed logs of millions of Web downloads with less than a worst case of 0.3% packet loss. The rest of this paper is organized as follows. Section 2 discusses the advantages of packet sniffing and Section 3 outlines some of the difficulties of extracting HTTP data from packet traces. The overall software architecture is described in Section 4. Our solution is presented in Section 5 and finally Section 6 briefly summarizes some of the lessons learned. 2 Strength of packet monitoring

We describe BLT, a tool for extracting full HTTP level as well as TCP level traces via packet monitoring. This paper presents the software architecture that allows us to collect traces continuously, online, and at any point in the network. The software has been used to extract extensive traces within AT

When monitoring network traffic, a flow measurement approach can provide the advantage of data reduction in near real-time. RTFM, the IETF's standard, generalised architecture for measuring traffic flows, and NeTraMet, an open-source implementation of that architecture, are introduced. The results of a NeTraMet usage survey are presented, together with a detailed description of the NeTraMet components and the ways they can be used to construct traffic flow measurement systems for any particular network. Nifty, an X Window near-real-time traffic flow analyser, is also described. Experiences with NeTraMet are summarised, highlighting its usefulness in building customised flow measurement systems.

To efficiently transfer large amounts of diverse traffic over high-speed links, modern integrated networks require more efficient packet-switching techniques that can capitalize on recent advances in switch hardware. Several promising approaches attempt to improve performance by creating dedicated "shortcut" connections for long-lived traffic flows, at the expense of the network overhead for establishing and maintaining these shortcuts. The network can balance these cost-performance tradeoffs through three tunable parameters: the granularity of flow end-point addresses, the timeout for grouping related packets into flows, and the trigger for migrating a long-lived flow to a shortcut connection. Drawing on a continuous one-week trace of Internet traffic, we evaluate the processor and switch overheads for transferring HTTP server traffic through a flow-switched network. In contrast to previous work, we focus on the full probability distributions of flow sizes and cost-performance metrics...

Traffic, usage, and performance measurements are crucial to the design, operation and control of Internet Protocol (IP) networks. This paper describes a prototype infrastructure for the measurement, storage and correlation of network data of different types and origins from AT&T’s commercial IP network. We focus first on some novel aspects of the measurement infrastructure, then describe analyses that illustrate the power of joining different measured data sets for network planning and design. 1

Traffic, usage, and performance measurements are crucial to the design, operation and control of Internet Protocol (IP) networks. This paper describes a prototype infrastructure for the measurement, storage and correlation of network data of different types and origins from AT&T's commercial IP network. We focus first on some novel aspects of the measurement infrastructure, then describe analyses that illustrate the power of joining different measured data sets for network planning and design.

Our research focuses on end-to-end congestion avoidance algorithms that use round trip time (RTT) fluctuations as an indicator of the level of congestion. The algorithms are referred to as delay-based congestion avoidance or DCA. Due to the economics associated with deploying change within an existing network, we are interested in an incrementally deployable enhancement to the TCP/Reno protocol. TCP/Vegas, which is a DCA algorithm, has been proposed as an incremental enhancement. Requiring relatively minor modifications to a TCP sender, TCP/Vegas has been shown to increase end-to-end TCP throughput primarily by avoiding packet loss. We study DCA in today's best effort Internet where IP switches are subject to thousands of TCP flows resulting in congestion with time scales that span orders of magnitude. Our results suggest that RTT-based congestion avoidance may not be reliably incrementally deployed in this environment. Through extensive measurement and simulation, we find that when TCP/DCA (i.e., a TCP/Reno sender that is extended with DCA) is deployed over a high speed Internet path, the flow generally experience degraded throughput compared to an unmodified TCP/Reno flow. We show that the congestion information contained in RTT samples is not sufficient to reliably predict packet loss and that the congestion reaction by a DCA flow, assuming that the flow consumes a small fraction of the resources at the bottleneck, has minimal impact on the congestion level over the path when the total DCA traffic at the bottleneck consumes less than 10% of the bottleneck bandwidth.