Subject: [bmwg] RFC2544 26.5 System Recovery

From: "Dave Fenstermacher" <[email-masked]>
Date: Fri, 21 Aug 2009 08:30:19 -0700

Hello,

Does the system recovery time include the latency time thru the device
under test? I am looking for clarification on the definition of
Timestamp B: 1) is this the sender timestamp inside the last packet that
was lost, or 2) is the time in which the packet was lost, i.e. expected
to arrive at the receiver (which means the receiver hardware timestamp)?
If it is 1), then the system recovery time does not include the latency
of the DUT. If it is 2), then it does include the latency of the DUT.
Also, since the packet was lost, is this really the packet following the
last one that was lost?

Thank you,

Dave Fenstermacher

---

From: Al Morton <[email-masked]>
Date: Fri, 21 Aug 2009 12:12:11 -0400

IMO, it's 1), sender timestamp.

There's no receiver timestamp for a lost packet,

and no mention of a computed arrival time here.

others?

Al

At 11:30 AM 8/21/2009, Dave Fenstermacher wrote:

Content-class:
urn:content-classes:message

Content-Type: multipart/alternative;

boundary="----_=_NextPart_001_01CA2274.4B356605"

Hello,

Does the system recovery time include the latency time thru the device
under test? I am looking for clarification on the definition of Timestamp
B: 1) is this the sender timestamp inside the last packet that was lost,
or 2) is the time in which the packet was lost, i.e. expected to arrive
at the receiver (which means the receiver hardware timestamp)? If it is
1), then the system recovery time does not include the latency of the
DUT. If it is 2), then it does include the latency of the DUT. Also,
since the packet was lost, is this really the packet following the last
one that was lost?

Thank you,

Dave Fenstermacher

_______________________________________________

bmwg mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/bmwg

---

From: David Newman <[email-masked]>
Date: Fri, 21 Aug 2009 09:56:36 -0700

> and no mention of a computed arrival time here.

As written the 2544 recovery test cannot be conducted on DUT/SUTs with
line-rate throughput, since by definition no overload is created. At the
time of 1944's creation, line-rate devices and test tools that measure
every frame's time in flight were not yet commonplace.

A viable workaround is to use the many-to-one pattern later introduced
in 2285 to create an overload. Using a known quantity of frames offered
at some known constant rate, it's possible to derive recovery time by
dividing drop count into offered load.

For example, consider a congestion-creating oload of 1 mpps and a
DUT/SUT that drops 100k frames. Since each offered frame is equivalent
to 1 usec in time, 100k drops would be equivalent to a recovery time of
100 ms.

Also, the 2544 recovery test describes a oload reduction of 50% from the
congestion point after loss occurs. In addition to the sender timestamp
Al mentions, this would require receiver-side logic to determine when
the DUT/SUT stops forwarding all offered frames -- and that in turn
raises the question of how long to wait to make such a determination.
The only thing 2544 says about this is the general principle of waiting
2 seconds for any residual frames (section 23d). The 2-second delay may
or may not describe the system's recovery time, the nominal goal of this
test.

dn

>> Content-class: urn:content-classes:message
>> Does the system recovery time include the latency time thru the device under 
>> test? I am looking for clarification on the definition of Timestamp B: 1) is 
>> this the sender timestamp inside the last packet that was lost, or 2) is the 
>> time in which the packet was lost, i.e. expected to arrive at the receiver 
>> (which means the receiver hardware timestamp)? If it is 1), then the system 
>> recovery time does not include the latency of the DUT. If it is 2), then it 
>> does include the latency of the DUT. Also, since the packet was lost, is this 
>> really the packet following the last one that was lost?
>>  
>> Thank you,
>> Dave Fenstermacher
>>  
>>  
> ------------------------------------------------------------------------
>

---

From: "Dave Fenstermacher" <[email-masked]>
Date: Wed, 26 Aug 2009 08:59:52 -0700

There are many test equipment vendors who have "extended" the test
methodology of 2544, to be able to test links that have bandwidth
capabilities that are derived by the underlying WAN technology, i.e.
Ethernet over Sonet/SDH, etc. For example, if an EoS link supported
500Mbps, then the offered load of 110% bandwidth would be 550Mbps, and
frame loss should occur. Once the offered load is dropped to 50% of
550Mbps or 275Mbps, then no more frame loss should occur. In measuring
System Recovery of this link, if no new frames were lost after the
bandwidth is reduced to 275Mbps, would this equate to a System Recovery
time of 0 seconds, i.e. Timestamp B occurred before Timestamp A? Or is
the intent to measure the time when no more lost frames are being
observed on the receiver side?
 
Thank you,
Dave Fenstermacher

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Newman
Sent: Friday, August 21, 2009 12:57 PM
To: [email-masked]
Subject: Re: [bmwg] RFC2544 26.5 System Recovery

dn

---

From: "Dave Fenstermacher" <[email-masked]>
Date: Thu, 27 Aug 2009 07:30:12 -0700

If I interpret this test as the intent to measure the time from
bandwidth drop to when no more lost frames are being observed on the
receiver side, then System Recovery would be determined by subtracting
Timestamp A from Timestamp B, or Timestamp B - Timestamp A. Please
clarify this.

Thank you,
Dave Fenstermacher

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dave Fenstermacher
Sent: Wednesday, August 26, 2009 12:00 PM
To: David Newman; [email-masked]
Subject: Re: [bmwg] RFC2544 26.5 System Recovery

Thank you,
Dave Fenstermacher

-----Original Message-----

dn