Analysis of ISP IP/ATM network traffic measurements.
This paper presents network traffic measurements collected from a commercial Internet Service Provider (ISP) whose traffic is being carried over an ATM backbone network. Much of the aggregate traffic is Web-related, and thus represents a Web/TCP/IP/AAL-5/ATM protocol stack. Four traces have been collected at the AAL-5 frame level, using a NavTel IW95000 ATM test set. These traces provide a detailed look at protocol-level behaviours, but only for rather short time durations (e.g., 30-40 seconds per trace). Analyses focus on aggregate-level traffic characteristics, as well as host-level and TCP connection-level traffic characteristics.The main workload characteristics observed from the measurements are the burstiness of the aggregate and individual traffic flows, a non-uniform distribution of traffic amongst hosts, a trimodal packet size distribution, and the strong presence of network-level effects (e.g., client modem speed, network Maximum Transmission Unit (MTU), network round trip time, TCP slow start) in the traffic structures seen. The workload characteristics are quite consistent across the four traces studied.
Introduction
This paper presents network traffic measurements
from a commercial Internet Service Provider
(ISP) environment in western Canada. This ISP
offers Internet service (primarily Web access) to
its customers, and is using an OC-3 (155 Mbps)
ATM backbone network to carry the traffic. The
TCP/IP packet traffic is converted to ATM cells
using AAL-5 as the adaptation layer protocol,
resulting in aggregate traffic that represents a
Web/TCP/IP/AAL-5/ATM protocol stack.
The network traffic measurements have been
collected using a GN NetTest NavTel IW95000
ATM measurement device. These measurements
provide fine-grain traffic information (i.e., complete
packet payloads) over short time periods (e.g., 30-
A total of four traces have been collected to
date. These measurements provide enough information
for off-line protocol decoding at the AAL-5,
IP, and TCP layers, making possible the identification
and characterization of individual traffic flows
(i.e., TCP connections), as well as aggregate traffic
characteristics, in our analyses.
The primary purpose of our measurements is
workload characterization: trying to understand
the characteristics of end-user Web/TCP/IP/ATM
network traffic. We are especially interested in characterizing
the aggregate traffic stream as a function
of its constituent parts, since understanding statistical
multiplexing behaviours is important for net-work
traffic management.
The main highlights from our measurements
are the following:
ffl the burstiness of the aggregate and individual
traffic flows;
ffl the non-uniform distribution of the generated
traffic amongst hosts;
ffl the asymmetric nature of client-server traffic
patterns;
ffl the presence of network-level effects (e.g., client
modem speed, network Maximum Transmission
Unit (MTU), network round trip time,
slow start) in the traffic structures observed

We also find that a log-normal distribution provides
a reasonable fit for connection duration and
bytes per connection, similar to observations made
by other researchers [1, 5]. The short duration of
our traces unfortunately precludes the analysis of
heavy-tailed behaviours in the Web traffic, which
have an important impact on traffic characteristics
(e.g., network traffic self-similarity [4]).
The remainder of this paper is organized as
follows: Section 2 describes the measurement en-
vironment, and the tools used for data collection
and analysis. Section 3 presents the aggregate-level
traffic measurement results, and Section 4 presents
the TCP connection-level traffic measurement results
for the four traces. Finally, Section 5 concludes
the paper.
Measurement Methodology
The measurements reported in this paper were
collected using a NavTel IW95000 ATM test set.
This test set provides for the non-intrusive capture
of complete ATM cell-level or AAL-5 frame-level
traffic streams, including packet headers and payloads

The test set timestamps each ATM cell or
frame with a one microsecond timestamp resolu-
tion, and records the captured traffic into memory
in a compressed proprietary binary data format.
The size of the memory capture buffer on the ATM
test set (e.g., 24 Megabytes RAM on the test set
that we used) determines the maximum amount of
data that can be captured at a time. This capture
buffer size, along with the volume of the network
traffic to be measured, determines the maximum
interval of time for which traces can be collected
(e.g., several seconds at full OC-3 rates, and several
minutes at rates). For our traces, we were able
to record about 35 seconds worth of traffic data at
a time.
Once the capture buffer is full, traces can be
saved to disk or copied to another machine using
ftp, for off-line trace analysis. The analyses reported
in this paper used a C program specially
written to decode the uncompressed proprietary
data format used by the NavTel IW95000. This
program converts the binary data file into an ASCII
format with TCP/IP protocol information.
An example of the human-readable trace format
is shown 1 in Figure 1. This format includes a
timestamp (in microseconds, relative to the start of
the trace), the protocol type(s) recognized (if any),
and then selected fields from the IP and TCP packet
header (if applicable), such as IP source and destination
address, IP packet size (including TCP and
IP headers), TCP source and destination port num-
bers, and TCP sequence number information, both
for data and for acknowledgments. Once available
in this latter form, it is straightforward to construct
customized scripts to process a trace file and extract
the desired information, such as timestamp, packet
size, as well as IP and TCP protocol information.
A total of four traces were captured with the
NavTel IW95000 test set. The first trace was collected
on May 3, 1998. This trace served as the
"guinea pig" for the design and debugging of the
programs for trace decoding and trace analysis. The
next three traces were collected on May 13, 1998.
1 Note that the IP addresses in Figure 1 (and throughout the paper)
have been "sanitized" to conceal their true identities.
The traces were taken one at a time, approximately
minutes apart, in the evening hours of a single
working day, and are deemed to be representative
samples of ISP network traffic.

Table

1 provides a statistical summary of the
four traces collected. The remaining sections report
on the analysis of these traces.
3 Aggregate-Level Traffic Characteristics
This section discusses aggregate traffic characteristics
for the four traces. The analyses focus
on traffic profile, packet size distribution, and host-level
traffic characteristics.
3.1

Figure

2 shows the traffic profile for one of the
four traces of ISP network packet traffic (Trace 2).
This trace contains 45,434 packets transmitted in
36.48 seconds, for an overall mean bit rate of 4.15
Mbps. The graphs in Figure 2 show the volume of
traffic (in bits, including all protocol headers) transmitted
per time interval, for three different time interval
sizes: 1.0 seconds in Figure 2(a), 0.1 seconds
in

Figure

2(b), and 0.01 seconds in Figure 2(c).
The graphs in Figure 2 show that the network
traffic is bursty, across several time scales. The aggregate
bit rate hovers around the overall mean of
4.15 Mbps, with a low of 3.0 Mbps and a high of
6.1 Mbps during the interval measured. The burstiness
is even more pronounced at the finer-grain time
scales illustrated, for which more data points are
plotted. This burstiness across time scales is indicative
of network traffic self-similarity [11, 18], though
this trace is far too short in duration to make any
rigourous claim to this effect.
3.2 Packet Size Distribution
Further understanding of the ISP network traffic
characteristics can be gained by studying the IP
packet size distribution. Figure 3 shows the frequency
distribution of the observed IP packet sizes
(including headers), using a linear scale on the vertical
axis in Figure 3(a), and a logarithmic scale on
the vertical axis in Figure 3(b). These results are
cumulative for all four traces.

Figure

3(a) shows that the IP packet size distribution
is trimodal. The distribution is dominated
(30%) by 40-byte packets, which carry TCP acknowledgements
(and no TCP data). There is a
significant spike (12%) at 1500 bytes, which is the
Maximum Transmission Unit (MTU) size used on
14966 IP TCP 561.877.104.57 7410 427.86.12.704 80 508 410104 32779
22126 IP TCP 582.127.755.91 1291 419.74.87.6

Figure

1: An Example of a TCP/IP Trace
Bits
Transmitted
per
Interval
Time in Seconds
Traffic Profile for Web/TCP/IP/ATM Trace 2
(a)2000006000001e+06
Bits
Transmitted
per
Interval
Time in Seconds
Traffic Profile for Web/TCP/IP/ATM Trace 2
Bits
Transmitted
per
Interval
Time in Seconds
Traffic Profile for Web/TCP/IP/ATM Trace 2
(c)

Figure

2: Traffic Profile for ISP IP/ATM Trace
2: (a) Bits Transmitted per 1.0 Second Inter-
val; (b) Bits Transmitted per 0.1 Second Interval;
(c) Bits Transmitted per 0.01 Second Interval
Mbps Ethernet local area networks. 2 There are
also many TCP/IP packets in the range of 300-600
bytes, which are typical sizes for packets traversing
the wide-area Internet backbone.
There are many other PDU sizes observed (see

Figure

3(b)), though the distribution is clearly dominated
by the main peaks described above.
3.3 Host-Level Analysis
One advantage of fine-grain traffic measurements
is that it is possible to extract IP (and higher
protocol information from the traces cap-
tured. In fact, we have used this capability to identify
individual IP traffic streams in our traces, in
an attempt to characterize their behaviour in the
context of the overall traffic.
We identified over 1000 different IP source and
destination addresses in our traces (see Table 1),
indicating that there is a large user community using
this ISP's services. We have also noted that (at
least in our relatively short traces) the traffic generated
by these IP addresses is highly non-uniform.
For example, it is not uncommon for 10% of the active
IP source addresses in a trace to generate over
80% of the IP packet traffic volume. The destination
address distribution is also highly non-uniform.
Detailed statistics regarding the 10 busiest IP
source and destination addresses in one of the traces
(Trace 1) are shown in Table 2. These 10 IP addresses
in combination account for over 50% of the
2 The primary Web site hosted by the ISP is actually on a 10 Mbps
Ethernet LAN, while the collection point for our measurements is an
OC-3 backbone ATM link used by the telecommunications provider
to carry the ISP's Internet traffic.

Table

1: Summary of ISP IP/ATM Traffic Traces
Trace 0 Trace 1 Trace 2 Trace 3
Trace Date May 3/98 May 13/98 May 13/98 May 13/98
Trace Time 7:00pm 7:00pm 7:30pm 8:00pm
Trace Size (bytes) 16,876,032 22,129,152 22,129,152 22,129,152
Trace Duration (sec) 34.30 36.42 36.48 36.79
Mean packets/sec 977 1,292 1,245 1,304
Mean bit rate (Mbps) 3.38 4.11 4.15 4.05
AAL-5 PDUs 33,524 47,057 45,434 47,977
IP Packets 33,349 46,764 45,172 47,684
TCP/IP Packets 24,257 34,072 31,914 31,417
Web/TCP/IP Packets (port 80) 17,054 24,795 24,407 22,175
IP Source Addresses 616 864 953 1019
IP Destination Addresses 662 915 1002 1064
Total IP Addresses 696 954 1054 1123
Mean AAL-5 PDU size (bytes) 435 400 418 392
Mean IP packet size (bytes) 405 370 388 3635152535
Relative
Frequency
in
Percent
IP Packet Size in Bytes
IP Packet Size Distribution in Web/TCP/IP/ATM Measurements (All Traces)
(a)0.0010.1100 200 400 600 800 1000 1200 1400 1600
Relative
Frequency
in
Percent
IP Packet Size in Bytes
IP Packet Size Distribution in Web/TCP/IP/ATM Measurements (All Traces)
(b)

Figure

3: IP Packet Size Distribution for ISP
IP/ATM Traffic Measurements: (a) Linear Scale on
the Vertical Axis; (b) Logarithmic Scale on the Vertical
Axis
packet traffic in this trace. This observation is not
surprising, because of the client-server architecture
used for many Internet services. However, it is
worth noting that the traffic to and from a specific
IP address can be just as bursty, or even more
bursty, than the overall aggregate traffic flow [18].
For example, Figure 4 shows the traffic volume to
and from a selected IP address from Table 2, representing
a Web server. The traffic profile is plotted
at the 0.1 second time granularity, similar to Figure
2(b). Note that the vertical scale is different on
each of the graphs.
3.4

Summary

This section has looked at aggregate-level traffic
characteristics in the ISP network traffic mea-
surements. The analyses have identified the bursty
nature of the traffic flow, a trimodal packet size
distribution, and a non-uniform distribution of the
generated traffic amongst the hosts using the net-
work. The next section proceeds to analyze TCP
connection-level traffic characteristics in the same
four traces.
4 Connection-Level Traffic Characteristics
This section zooms in on the measurement
data to examine finer-grain connection-level and
protocol-level behaviours.
4.1 Connection-Level Characteristics

Table

3 summarizes the number of TCP connections
observed in each of the four traces, as well

Table

2: Traffic for Selected IP Addresses (Trace 1)
IP Packets % of Total Packets % of Total Total % of Total
Address Sent Packets Sent Recd Packets Recd Packets Packets
Total 17,241 36.87 8,403 17.97 25,644 54.8450001500025000
Bits
Transmitted
Per
Interval
Time in Seconds
Traffic Profile to Busy Web Server (Trace 1,
Bits
Transmitted
Per
Interval
Time in Seconds
Traffic Profile from Busy Web Server (Trace 1,
(b)

Figure

4: Traffic Profile for a Selected IP Address:
(a) Traffic to the Web Server; (b) Traffic from the
Web Server
as some statistical characteristics for these TCP
connections. A TCP connection refers to the bidirectional
exchange of TCP/IP packets between a
pair of IP host addresses, using a specific source and
destination port for the connection, and (in normal
cases) a monotonically increasing sequence number
(and acknowledgement number) for the data bytes
transferred. The establishment of a new TCP connection
is done using a three-way handshake, using
the "SYN" (Synchronize) flag in the TCP packet
header. The termination of a TCP connection is
done with a similar three-way handshake using a
"FIN" flag [17].

Table

3 shows that there are about 500 completed
connections per trace. In this table,
a "complete" TCP connection is defined as one for
which the opening "SYN" and the closing "FIN"
were seen during the trace, while an "incomplete"
TCP connection is one in which the "SYN" or the
"FIN" (or both) were not present in the trace. Note
that this definition biases our results, since only
"short-lived" TCP connections will qualify as complete
TCP connections in our analysis, and these
connections account for less than half of the total
packet volume in the traces. Nevertheless, this approach
does identify over 2000 complete connections
from the four traces, which can be used for work-load
characterization. Over 95% of these completed
connections are Web-related (i.e., TCP port 80).

Figure

5 provides a closer look at the distribution
of packets, bytes, and time per (complete) TCP
connection. These graphs show the empirically observed
PDF for each distribution (as a histogram),
as well as an approximate log-normal fit to the distribution
(as a dashed line), using the same mean

Table

3: Summary of TCP Connection-Level Characteristics
Trace 0 Trace 1 Trace 2 Trace 3
Complete TCP Connections 425 586 642 458
Total IP Packets 10,352 10,445 12,065 9,715
Min packets per connection 6 3 6 5
Mean packets per connection 24.4 17.8 18.8 21.2
Max packets per connection 2,645 380 222 288
Min data bytes per connection
Mean data bytes per connection 10,519 5,474 5,595 6,992
Max data bytes per connection 1,976,090 229,673 81,027 221,935
Min duration per connection 0.131 0.177 0.194 0.158
Mean duration per connection 4.532 5.091 5.159 5.533
Max duration per connection 29.588 33.832 33.253 33.006
Incomplete TCP Connections 579 888 919 949
Total TCP Connections 1,004 1,474 1,561 1,407
and standard deviation. Note that the horizontal
axes on all three graphs represents a logarithmic
scale (base 2). While the fit is by no means tight,
the general trend in the data suggests that a log-normal
fit for the body of the distribution is a reasonable
hypothesis.
The graphs in Figure 5 support the general
observation that most connections are short: the
average connection exchanges about 6 kilobytes of
application-level data using packets, and lasts
about 5 seconds. These observations are consistent
with other measurements of Web traffic workloads
[1, 2, 4, 5] and TCP/IP traffic characteristics
[3, 15, 16] in a variety of environments [6, 8, 10].
4.2 Asymmetry of Client-Server Traffic
Because much of the traffic in our collected
traces is Web-related, there is an asymmetric client-server
structure to the traffic. That is, the client
typically sends few data bytes (e.g., the URL for a
requested document), while the server tends to send
more data bytes (e.g., the returned document).
This asymmetric behaviour is illustrated
graphically in Figure 6. These results are reported
for Trace 1, in which a total of 586 complete TCP
connections were recognized. Figure 6(a) shows the
number of packets transmitted in each direction on
these connections, using the downward vertical axis
(i.e., negative values) to represent the number of
client packets transmitted, and the upward vertical
axis (i.e., positive values) to represent the number
of server packets transmitted. As can be seen, there
is a direct correlation between the number of packets
sent in each direction on a given connection,261014
Frequency
in
Percent
Log2(Number of Data Bytes Exchanged in Both Directions)
Distribution of Bytes per Complete TCP Connection (All Traces)
Frequency
in
Percent
Log2(Number of Packets Exchanged in Both Directions)
Distribution of Packets per Complete TCP Connection (All Traces)
Frequency
in
Percent
Log2(Number of Seconds Between Opening SYN and Closing FIN)
Distribution of Time Duration per Complete TCP Connection (All Traces)
(c)

Figure

5: Distributional Characteristics of TCP
Connections (All Traces): (a) Number of Packets
Exchanged Per Connection; (b) Number of Bytes
Exchanged Per Connection; (c) Time Duration of
Connection
Number
of
Packets
Transmitted
Connection Number
Time Series Illustration of Client/Server Packets per TCP Connection (Trace 1)
Server
Client
(a)
-5000050000150000250000
Number
of
Data
Bytes
Transmitted
Connection Number
Time Series Illustration of Client/Server Bytes per TCP Connection (Trace 1)
Server
Client
(b)

Figure

Illustration of Asymmetric Nature of
Client/Server Traffic (Trace 1): (a) Packets per
Connection; (b) Bytes per Connection
though the client in general tends to send fewer
packets. 3 One of the reasons for this is the "delayed
acknowledgement" strategy of TCP; in many cases,
the receiver of a data transfer generates one TCP
acknowledgement for every two TCP data segments
that arrive [17].
The asymmetry of traffic flows is more clearly
evident in Figure 6(b). This figure shows the number
of data bytes transmitted in each direction on
the 586 connections, using the downward vertical
axis (i.e., negative values) to represent the number
of client bytes transmitted, and the upward vertical
axis (i.e., positive values) to represent the number
of server bytes transmitted. The volume of server
bytes per connection ranges widely, from several
hundred bytes to several hundred kilobytes in this
trace. The volume of client bytes per connection
is generally low (e.g., tens of bytes to hundreds of
bytes). The most bytes transmitted on a TCP connection
by any client in this trace was 3,649 bytes.
3 There is an anomaly, however, for connection 290. Detailed analysis
of this connection shows that the client generated 340 TCP acknowledgement
packets during the 38-packet transfer of 16,253 bytes
from the server. Many of these packets were closely-spaced duplicate
acknowledgements. We attribute this anomaly to a bug in the client's
implementation, perhaps with respect to timer settings.
4.3 Detailed Connection-Level Analysis

Figure

7 presents a detailed illustration of one
particular IP host's connection activity. In partic-
ular, this graph illustrates communication between
client IP address 274.193.285.435 and server IP address
812.91.635.174 (from Table 2). The latter IP
address represents a Web server, and the packets
illustrated in Figure 7 represent Web-browsing activity
by the client.
The topmost graph, Figure 7(a), is a two-dimensional
portrayal of the packet traffic between
the client and the server. The horizontal axis represents
the time at which the packet was seen in the
trace. This time ranges from 0 to seconds. The
vertical axis represents the size of the IP packet.
With this approach, the "full" TCP data packets
generated by the server are easily distinguishable
from the TCP acknowledgement packets generated
by the client. The size of the IP packets used
(552 bytes) suggests that a TCP Maximum Segment
Size (MSS) of 512 bytes is being used, perhaps
because of a network-level constraint on the
Maximum Transmission Unit (MTU) size.
The sequence of dark vertical "bands" in Figure
7(a) represents the TCP connections used to
transfer individual documents using HTTP 1.0.
There are 11 such complete connections in this trace
(the first TCP connection is actually "joined in
progress" at time 0 in the trace). The horizontal
"white space" in the plot represents either user
"think time" between URL requests, or the processing
time between the generation of each TCP connection
to download embedded documents within a
Web page. 4

Figure

7(b) provides a more detailed look at
one particular complete TCP connection (namely,
the one that starts with a three-way SYN hand-shake
(initiated by the client) at time 2.96 seconds.
Once the connection is open, the client sends a 465-
byte IP packet carrying the information about the
requested URL. Upon receipt of this packet, the
server generates the first 1 KB of the response (im-
plying an initial TCP congestion control window
size of 1024 bytes) to the URL requested (requiring
two packets in this case, because of the MTU used,
though both packets have the same timestamp in
4 Note that the usage of TCP connections for Web document transfers
will change significantly when the "persistent connection" feature
of HTTP 1.1 is in widespread use [7, 12]. A persistent connection allows
multiple URL requests to be "pipelined" on the same TCP con-
nection. This connection is then used to return each of the requested
documents in turn. We found no evidence of persistent connections
used in our traces from May 1998.
our trace). The connection then proceeds through
the TCP slow-start algorithm [9].

Figure

7(c) provides a TCP sequence number
plot illustrating this behaviour more clearly. In
this plot, the horizontal axis represents time (us-
ing the same time scale as Figure 7(b)), and the
vertical axis represents the TCP sequence number
(in bytes). A '+' denotes a data packet transmitted
by the server, while an 'X' denotes an acknowledgement
packet transmitted by the client. The vertical
spacing between each '+' indicates the relative
size of each packet (i.e., the number of data bytes
contained within each TCP/IP packet), while the
horizontal spacing between a packet and the corresponding
acknowledgement reflects the round-trip
time (RTT) between the client and server, as observed
at the fixed measurement point. The cumulative
(and delayed) acknowledgement strategy
of TCP is clearly evident, as is the evolutionary
growth of the TCP slow-start congestion window
size. The connection terminates (shortly after time
4.0 seconds) as the final data packets are acknowl-
edged, and the FIN handshake completes. This
connection exchanges a total of 16,951 bytes using
packets (16 sent by the client, and 31 by
the server). The Web document itself accounts for
14,632 of these bytes.
The (almost constant) horizontal spacing between
the clumps of data packet transmissions in

Figure

are indicative of the round-trip time
(RTT) between the client and the server, which
is approximately 150 milliseconds in this example.
This time is a function of client modem speed (e.g.,
the transmission of two 512-byte IP packets over a
64,000 bits per second narrowband-ISDN link would
take 128 milliseconds), TCP/IP packet processing
overhead, physical propagation delay, and other
bottlenecks (e.g., queueing points at routers) in the
network between the client and the server. The fact
that the acknowledgement packet transmissions are
very close (in time) to the next data packet transmissions
merely indicates that the ATM test set was
measuring traffic at a point very close to the server
(i.e., on the server's network).
Similar analyses of other IP source addresses
and their TCP-level connection behaviours are possible
using this technique. An analysis of the inter-arrival
times between TCP connections is planned
for the near future.1003005000 5e+06 1e+07 1.5e+07 2e+07 2.5e+07 3e+07
IP
Packet
Size
in
Bytes
Time in Microseconds
Traffic Profile for a Selected IP Source-Destination Pair (Trace 1)
(a)1003005002.8e+06 3e+06 3.2e+06 3.4e+06 3.6e+06 3.8e+06 4e+06 4.2e+06
IP
Packet
Size
in
Bytes
Time in Microseconds
Traffic Profile for a Selected IP Source-Destination Pair (Trace 1)
(b)3880003920003960004000002.8e+06 3e+06 3.2e+06 3.4e+06 3.6e+06 3.8e+06 4e+06 4.2e+06
Sequence
Number
in
Bytes
Time in Microseconds
TCP Sequence Number Plot for a Selected TCP Connection (Trace 1)
TCP Sequence Number (Server)
TCP Ack Number (Client)
(c)

Figure

7: Selected IP Traffic Flow: (a) Many TCP
Connections over One TCP Connection
over 1.4 Seconds; (c) TCP Sequence Number
Plot for Selected TCP Connection
4.4

Summary

This section has presented TCP connection-level
analyses of four ISP IP/ATM traffic traces.
Because of the short duration of the traces, the completed
connections observed are "short-lived".
Many of these TCP connections represent Web
transfers, for which the numbers of bytes, packets,
and time duration per connection can be reasonably
modeled with log-normal distributions. Fine-grain
analysis of the traffic identifies protocol-specific be-
haviours, such as TCP window-based flow control,
and multiple TCP connections between client and
server for Web document transfers.
Conclusions
This paper has presented low-level measurements
of Internet traffic flowing to and from an
Internet Service Provider over an ATM backbone
network. The measurements are useful in terms
of characterizing the individual IP traffic streams
generated by Internet users, as well as for characterizing
the aggregate traffic. Analyses show that
much of the traffic in the traces is Web-related, and
that traffic is bursty both at the aggregate-level and
at the individual host-level. Furthermore, there is
significant traffic structure at fine-grain time scales
due to TCP/IP and HTTP protocol behaviours.
our measurements confirm that Internet
users generate very demanding traffic for
telecommunications networks to handle. It is reassuring
to note, however, that the burstiness of
the aggregate traffic is less than the burstiness of
a single source, indicating that there is significant
statistical multiplexing gain across sources. This
observation is consistent with earlier work assessing
the effective bandwidth requirements of multiplexed
self-similar traffic streams [6, 13, 14]. We hope that
this multiplexing gain continues as the number of
Internet subscribers increases.
Measurements of Web and IP/ATM traffic over
a longer time duration are clearly needed in order
to assess (with any statistical rigour) the presence
of heavy-tailed distributions in the traffic, as well as
the presence of long-range dependence in the traf-
fic, if any. These measurements are being pursued
in cooperation with the TeleSim project, and with
CANARIE.

Acknowledgements

The measurements presented in this paper
were collected by Telus Advanced Communications
and made available to researchers in the
project. Financial support for this re-search
was provided by Newbridge Networks, as
well as an NSERC Collaborative Research and Development
(CRD) grant to the ATM-TN TeleSim
project (CRD183839), and NSERC research grant
OGP0121969.



--R

"Workload Characterization of a Web Proxy in a Cable Modem Environment"
"Internet Web Servers: Workload Characterization and Performance Implications"
"Characteristics of Wide-Area TCP Con- versations"
"Self-Similarity in World Wide Web Traffic: Evidence and Possible Causes"
"Ef- ficient Policies for Carrying Web Traffic over Flow-Switched Networks"
"Network Traffic Measurements of IP/FrameRelay/ATM"
"Performance Interactions Between P-HTTP and TCP Im- plementations"
"Modeling the Performance of HTTP over Several Transport Protocols"
"Congestion Avoidance and Con- trol"
"A Measurement Analysis of Internet Traffic over Frame Relay"
"On the Self-Similar Nature of Ethernet Traffic (Extended Version)"
"The Case for Persistent Connection HTTP"
"On the Use of Fractional Brownian Motion in the Theory of Connectionless Networks"
"Effective Band-width of Self-Similar Traffic Sources: Theoretical and Simulation Results"
"Empir- ically Derived Analytic Models of Wide-Area TCP Connections"
"Wide Area Traffic: The Failure of Poisson Modeling"
TCP/IP Illustrated
"Self-Similarity Through High- Variability: Statistical Analysis of Ethernet LAN Traffic at the Source Level"
--TR

--CTR
Rachid Ait Yaiz , Geert Heijenk, Polling Best Effort Traffic in Bluetooth, Wireless Personal Communications: An International Journal, v.23 n.1, p.195-206, October 2002
network traffic measurement;ATM networks;TCP/IP;wworkload characterization