Re: [bmwg] RFC2544 26.5 System Recovery

[David Newman <dnewman at networktest.com>]

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