Re: comments on draft-dcbench-def-00 (part 1)

I can make a little time to pick-up this discussion again,
so maybe we can close on some advice for the draft authors.

If as David agreed below, the e2e jitter estimation is a valuable feature,
then it helps to narrow the field of applicable definitions for 
delay variation.  We know how to do this (albeit with some mathematical
complexity) for the form of delay variation distribution that is essentially
the histogram of delays with the minimum delay subtracted from all values.
http://tools.ietf.org/html/rfc6049#section-6

We don't know how to do comparable e2e estimation math for an alternate form 
of delay variation, usually called jitter, which emphasizes the change in delay
between successive packets.

Both these forms are defined and compared in 
http://tools.ietf.org/html/rfc5481#section-4
as PDV and IPDV, respectively.

Over the last two months, I've had some discussions with folks who want
to support Data Center trouble-shooting with IPv6 optional header time-stamp
assistance. These folks have worked to broadly inform various IETF working 
groups of their goals and proposed solutions (v6ops, ippm, and even tictoc
for some synchronization related aspects). One thing I've learned from the
exchange is that the histogram view of delay variation can assist their 
efforts. This may be more of an operational aspect than something we
need to measure in device benchmarking, but the synergy with e2e estimation
is worth noting.

regards,
Al
(as a participant)


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> David Newman
> Sent: Wednesday, July 31, 2013 2:38 PM
> Cc: [email protected]
> Subject: Re: [bmwg] comments on draft-dcbench-def-00 (part 1)
> 
> On 7/31/13 11:07 AM, MORTON JR., ALFRED C (AL) wrote:
> 
> > I assumed we have benchmarked a single device, and wanted to
> > estimate how some number of these devices would affect delay
> > variation when deployed on the path. Clearly, if we can benchmark
> > a particular black-box SUT with a specific combination of these devices,
> > there's no need to do the estimation for that case.
> > But having the ability to estimate e2e variation for an unknown number
> on the path
> > seems valuable to me, and I wonder if Data Center Engineers agree.
> >
> > it's been a long day here, hope this makes sense,
> 
> Mostly. Agreed 100 percent on the requirement for e2e estimation.
> 
> Unclear how that estimate would differ from a single-box estimate times
> some number of identical boxes, modulo cable lengths.
> 
> And regardless of box count, there's still the question of which  method
> of jitter measurement to use.
> 
> That was my original point: Given so many definitions to choose from,
> it'd be nice to spell out one definition in this document, either
> referencing something else, or defining something new (as in the use of
> FILO for latency measurement).
> 
> dn
> 
> _______________________________________________
> bmwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bmwg