Subject: [bmwg] Latency Process

From: "John Dawson" <[email-masked]>
Date: Thu, 5 Jul 2001 11:23:21 -0700

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

---

From: "David Newman" <[email-masked]>
Date: Thu, 5 Jul 2001 13:14:26 -0700

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

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

---

From: Kevin Dubray <[email-masked]>
Date: Thu, 05 Jul 2001 17:14:25 -0400

To split hairs a bit further: RFC 1242, where the latency metric
is DEFINED, makes no reference to binding the measurement to a
particular load point.

John's point, I believe, is to refine/repair/supplant the collection
heuristic for the latency metric, not necessarily retool the 
definition of latency. I not necessarily against this.  (In fact,
one might say I began to take similar liberties in the "alternative"
proposals for "multicast latency" that I submitted a while back.  

David Newman wrote:

> date?

---

From: "David Newman" <[email-masked]>
Date: Thu, 5 Jul 2001 18:02:12 -0700

> is DEFINED, makes no reference to binding the measurement to a

Good point! Since there's no requirement that the TERM "latency" be bound to
tput, does this mean it's OK to use the L word when referring to other
oloads?

While I personally have no problem with doing so, others might. After all,
2544 refers to the term in exactly one way and 2544 is pretty widely used.

John makes the point about the introduction of forwarding rate terminology
and methodology when throughput alone proved unsatisfactory. In this case,
will the introduction of new tests that re-use an existing term in new ways
prove confusing?

> definition of latency. I not necessarily against this.

Me neither. In fact, it's high time we begin to extend the useful but very
basic single measurement offered in 2544.

dn