[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bmwg] RFC2544 26.5 System Recovery
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: bmwg-bounces at ietf.org [mailto:bmwg-bounces at ietf.org] On Behalf Of
David Newman
Sent: Friday, August 21, 2009 12:57 PM
To: bmwg at ietf.org
Subject: Re: [bmwg] RFC2544 26.5 System Recovery
On 8/21/09 9:12 AM, Al Morton wrote:
> 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
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
>
> 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
>> bmwg at ietf.org
>> https://www.ietf.org/mailman/listinfo/bmwg
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> bmwg mailing list
> bmwg at ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg
_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www.ietf.org/mailman/listinfo/bmwg