RFC 889 (rfc889) - Page 2 of 11


Internet delay experiments



Alternative Format: Original Text Document



D.L. Mills


     The remote test hosts were selected to represent canonical paths in the
Internet system and were scattered all over the world.  They included some on
the ARPANET, MILNET, MINET, SATNET, TELENET and numerous local nets reachable
via these long-haul nets.  As an example of the richness of the Internet
system connectivity and the experimental data base, data are included for
three different paths from the ARPANET-based measurement host to London hosts,
two via different satellite links and one via an undersea cable.

2.  Packet Length Versus Delay

     This set of experiments was designed to determine whether delays across
the Internet are significantly influenced by packet length.  In cases where
the intrinsic propagation delays are high relative to the time to transmit an
individual packet, one would expect that delays would not be strongly affected
by packet length.  This is the case with satellite nets, including SATNET and
WIDEBAND, but also with terrestrial nets where the degree of traffic
aggregation is high, so that the measured traffic is a small proportion of the
total traffic on the path.  However, in cases where the intrinsic propagation
delays are low and the measured traffic represents the bulk of the traffic on
the path, quite the opposite would be expected.

     The objective of the experiments was to assess the degree to which TCP
performance could be improved by refining the retransmission-timeout algorithm
to include a dependency on packet length.  Another objective was to determine
the nature of the delay characteristic versus packet length on tandem paths
spanning networks of widely varying architectures, including local-nets,
terrestrial long-haul nets and satellite nets.

2.1.  Experiment Design

     There were two sets of experiments to measure delays as a function of
packet length.  One of these was based at DCN1, while the other was based at
NTA.  All experiments used ICMP Echo/Reply messages with embedded timestamps.
A cycle consisted of sending an ICMP Echo message of specified length, waiting
for the corresponding ICMP Reply message to come back and recording the
elapsed time (normalized to one-way delay).  An experiment run, resulting in
one line of the table below, consisted of 512 of these volleys.

     The length of each ICMP message was determined by a random-number
generator uniformly distributed between zero and 256.  Lengths less than 40
were rounded up to 40, which is the minimum datagram size for an ICMP message
containing timestamps and just happens to also be the minimum TCP segment
size.  The maximum length was chosen to avoid complications due to
fragmentation and reassembly, since ICMP messages are not ordinarily
fragmented or reassembled by the gateways.

     The data collected were first plotted as a scatter diagram on a color
bit-map display.  For all paths involving the ARPANET, this immediately
revealed two distinct characteristics, one for short (single-packet) messages
less than 126 octets in length and the other for long (multi-packet) messages



Internet Delay Experiments