Subject: [bmwg] RFC 1242 and negative latencies

From: "Timmons C. Player" <[email-masked]>
Date: Thu, 08 Feb 2007 13:40:20 -0500

So, I was perusing RFC 1242 the other day and reread the discussion
section for the definition of latency in section 3.8.  I was a little
surprised by the reference to negative latency values, but after
thinking about how store and forward latency is measured, it occurred to
me that negative latencies should definitely be producible when
measuring latency using the definition for store and forward.

Now remember, store and forward is measured in the following way:  The
transmit timestamp is when the DUT receives the last bit of the frame.
The receive timestamp is when the DUT transmits the first bit of the
frame.  If our DUT is a wire, then the receive timestamp should occur
BEFORE the transmit timestamp because the time to transmit a bit across
the wire is significantly shorter than the time to put all of the bits
on the wire.  Thus, the test box should receive the first bit before it
transmits the last bit, and should thus report a negative latency value.

I also calculated this nifty table that shows store and forward latency
values for a 1 meter long cable assuming a propagation delay of 59%
found that number at of the speed of light (I found the 59% number on a
website somewhere, however, using 1 or 100 doesn't really make much of a
difference at < gig speeds) at various frame sizes.

Calculated Store and Forward Latency (ns)
Frame Size	10Mbps	100Mbps	1000Mbps	10000Mbps
64	-51194.35028	-5114.350282	-506.3502825	-45.55028249
128	-102394.3503	-10234.35028	-1018.350282	-96.75028249
256	-204794.3503	-20474.35028	-2042.350282	-199.1502825
512	-409594.3503	-40954.35028	-4090.350282	-403.9502825
1024	-819194.3503	-81914.35028	-8186.350282	-813.5502825
1280	-1023994.35	-102394.3503	-10234.35028	-1018.350282
1518	-1214394.35	-121434.3503	-12138.35028	-1208.750282
9016	-7212794.35	-721274.3503	-72122.35028	-7207.150282

Anyway, I'm curious as to other people's opinions on negative latency.
Yes, I realize that correctly setup measurements of a DUT probably
should not produce negative latencies, however a loopback test using an
arbitrary length of cable SHOULD.  However, I haven't found any test box
that will report them. :(

Also, if anyone can find a fallacy in either my logic or my math, I
would appreciate it.

Timmons

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

---

From: "McQuaid, Jim" <[email-masked]>
Date: Thu, 8 Feb 2007 12:52:56 -0600

The "wire" concept is interesting, but the negative latency is an
artifact of the difference between typical router and switche
architectures, more or less.  Any network device could be expected to
fully receive a packet before sending it out (on another interface,
presumably).  After all, logically, you have to process the checksum at
the end of the frame to know if it is a valid frame and can be
forwarded.

The early LAN switch designers took advantage of the nature of Ethernet
to short cut this.  They begin emitting the packet on the outbound
interface before they fully received the packet on the inbound
interface.  This creates negative latency compared to the typical router
handling.  IF the packet did have a defect, revealed when the checksum
was examined, they would use the Ethernet "jam / collision" signal to
trash the partially emitted packet.  Clever and screwy by the
definitions developed for a pure store & forward world.  Hence, negative
latency.

(Then there's the einstein switch which sends the entire packet before
receiving it....)

cheers,

Jim McQuaid

NetQoS

-----Original Message-----
From: Timmons C. Player [mailto:[email-masked]] 
Sent: Thursday, February 08, 2007 1:40 PM
To: [email-masked]
Subject: [bmwg] RFC 1242 and negative latencies

Timmons

---

From: Al Morton <[email-masked]>
Date: Thu, 08 Feb 2007 14:41:14 -0500

The "wire" DUT isn't really a store and forward device.
It's not quite a bit-forwarding DUT either, but you're better
off using the latency definition for bit forwarding:

                 For bit forwarding devices:
                 The time interval starting when the end of the first
                 bit of the input frame reaches the input port and
                 ending when the start of the first bit of the output
                 frame is seen on the output port.

First bit to first bit latency should be positive, even with a wire.
Al

At 01:52 PM 2/8/2007, McQuaid, Jim wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.3 (MingW32)
>
>iD8DBQFFy26UPps6tU0vhXERAlYQAJ47HYR8Xnp5bfjUAZ0X+6xVsnpJLgCgsUBk
>miZm1bGa6lNFXkdndhxqSw8=
>=PC2d
>-----END PGP SIGNATURE-----
>

---

From: Al Morton <[email-masked]>
Date: Thu, 08 Feb 2007 14:56:12 -0500

>                 frame is seen on the output port.

Hmmm, reading this again more closely, a negative reading could
result because different significant instants of the first bit are used,
and they overlap by the time interval of a bit.

Al

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 08 Feb 2007 17:51:25 -0500

In message <[email-masked]>
> that will report them. :(

FWIW - since you asked.

If you measure the delay through a peice of store and forward gear
such as most routers and there are no queueing delays, then your
measurements will generally be a fairly fixed time plus packet
serialization delay.  It makes more sense to report it as this delay
plus the serialization delay which is dependent on packet size.

In some cases there are internal serialization delays but the internal
pipes are usually much faster so it is a small packet size dependent
delay.  If packets are chopped into parts this small delay may be a
sawtooth and look like a constant (small enough that it gets lost in
the noise of the measurement).

If measuring delay on a wire (fiber, circuit, pipe, whatever) and
there is no serialization delay, then it makes more sense to just
measure the delay.  For simple wires (fibers, whatever) delay should
be dominated by speed of light delay and there is no serialization
delay that would be dependent on packet size.

Converting from one type of measurement to the other is easy as long
as you know the packet size.

For WANs the speed of light delays are measured in msec, with about
60-70 msec round trip delays for US coast to coast, 100 msec across
the Atlantic, etc.  Round trip times (RTT) can be well over 200 msec
from traffic from Asia to Europe by way of the US.  Delay is speed of
light delay RTT and queueing delay for WANs.  Serialization delay
doesn't matter.  Forwarding latency doesn't matter unless the
equipment is truly broken.

For data centers speed of light delay across the data center floor is
very small.  Serialization delay matters.  Latency matters.  If
equipment can reduce or nearly eliminate serialization delay by
starting to forward out before the last bit arrives it makes a
difference for some applications, such as database access.  Some
ethernet switches do that.

For Internet geeks concerned about WANs any discussion of latency and
serialization delay is mostly a big yawn.  For data center geeks it
may be a big deal.

Curtis

---

From: David Newman <[email-masked]>
Date: Thu, 08 Feb 2007 21:21:54 -0800

> The "wire" DUT isn't really a store and forward device.

Ah, but the test instrument doesn't know that.

Implementers of 1242/2544/2285/2889-compliant test tools treat s&f and
bit forwarding (aka cut-through) as methods rather than device types,
regardless of which type of DUT the tester puts between the tx and rx
ports. The RFC says there are two measurement methods; ergo, the
measurement instrument supports both methods.

Even though 1242 clearly states that negative values are possible with
the s&f method, the danger arises when a tester uncrates a shiny new
instrument and runs a loopback latency test. Upon seeing negative
numbers, I'm pretty sure the first words coming out of the tester's
mouth will not be "ah, RFC-compliant!"

> First bit to first bit latency should be positive, even with a wire.

Based on what 1242 says about negative values, I believe Timmons is
correct about how much delay a *really* fast device would introduce,
even with s&f measurements of 0 or less. I'm less sure it's appropriate
to report this as "latency" since it may imply the DUT exceeds c.

dn