Subject: RE: [bmwg] Latency Process

From: "John Dawson" <[email-masked]>
Date: Thu, 5 Jul 2001 13:56:32 -0700

David,

In response to your questions,

I believe that there is more than one data rate that should be used for
latency measurements.  These rates include latency with no-load in addition
to latency above and below the throughput rates.  Latency under load can be
tricky due to the way in which traffic generators can generate synchronized
loads.  I would like to see the measurement process include a mechanism
which can provide similar results across different test equipment sets.  For
instance, rather than setting each port to the same gap (which can cause
synchronization of traffic and skew results), by assigning ports different
gaps (possibly based upon prime numbers) the likelihood that one or more
stream of traffic can remain synchronized over the test duration is
minimized.

With respect to the meaning of Latency (a.k.a RFC-1242 definition).  I
believe that we have to be able to separate the definition from the
methodology.  I don't believe that a change in methodology necessarily
constitutes a change in terminology.  Process improvements in methodology
happen all the time, does each release of new methodology explicitly imply
that the terminology must be re-invented? I don't see this issue in the same
light as say Throughput, where many folks have wished to define acceptable
loss rates.  In this case, the terminology has not changed.  However, if the
consensus is that everyone is happy with Latency as represented by the
methodology then I would have no objections to using different terminology.

So what is the reality here, are most people happy with the latency process
as specified?

John 

-----Original Message-----
From: David Newman [mailto:[email-masked]]
Sent: Thursday, July 05, 2001 1:14 PM
To: bmwg
Subject: RE: [bmwg] Latency Process

I share John's dissatisfaction with the RFC 2544 method as the sole measure
of device delay. In addition to the single oload and buffering issues John
raises, the single-packet "blip test" described in 2544 cannot describe
jitter or delay distribution. For some applications, these metrics may be
more important than latency itself.

As we've discussed on the list before, it may be useful to plot the "hockey
stick" leading up to the throughput rate. There may also be other oloads
that produce noteworthy results.

I'd like to ask John for clarification on a couple of points:

0. Is your intent to measure delay at *any* oload, or strictly at oloads at
or below the throughput rate? The reason I ask is that as part of the
current dsterm/dsmethod effort we envision tests of delay at oloads *above*
the tput rate.

If you're contemplating rates above the tput level, we would welcome your
expertise in shaping the current dsterm document and especially the dsmethod
draft once we begin work on that one.

1. This is a just semantics, but important all the same. Currently, latency
has one very specific meaning, and one meaning only -- device delay at the
throughput rate. Does it make sense to change the definition at this late
date? Or should we instead refer to all measurements taken at non-tput
oloads (both above and below tput) as "delay"?

David Newman
Charter Member
Committee to Stamp Out HTML Email

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of John
Dawson
Sent: Thursday, July 05, 2001 11:23 AM
To: [email-masked]
Subject: [bmwg] Latency Process

I believe that the time has come to update the methodology associated with
Latency measurements.  I do not believe that the methodology contained in
RFC-2544 is appropriate for characterizing the forwarding characteristics of
a network interconnect device.  Specifically, latency measurements made at a
devices throughput rate are more likely to measure the size of output
buffers on a DUT rather than the speed at which traffic is forwarded.
I know that there has been off and on work in this area.  I do believe that
it is time to tackle the issues that are unique to latency measurements.  I
would like to see a document that provides a set of measurements that can
characterize latency (forwarding delay) and I don't believe the answer MUST
be found at the Throughput rate.
I believe that this effort is overdue for the case of multi-port switches
and routers.
I am willing to work on such a document if there are there others who agree
that this effort is needed.
Any feedback?
John

_______________________________________________
bmwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bmwg