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

Thanks for adding our "local" references and more, David.

With many possibilities on the table, I hope we'll hear from some 
additional folks who've joined us for data center-related work...

Al
(I can say that as co-chair, so have)

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> David Newman
> Sent: Thursday, October 24, 2013 1:56 PM
> Cc: [email protected]
> Subject: Re: [bmwg] comments on draft-dcbench-def-00 (part 1)
> 
> On 10/24/13, 10:27 AM, MORTON, ALFRED C (AL) wrote:
> > 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.
> 
> I've found histograms to be very useful in lab as well as production
> settings. There's still the question of "histograms of what?" though.
> 
> My main concern is having enough specifity in the term "jitter" (and
> indeed all terms in all bmwg docs) so that everyone implementing the
> test will make the same measurement.
> 
> The current reference, to the second definition in RFC 3393 section 1.1,
> avoids giving a specific measurement (is it average or minimum?) and
> even goes on to say the term jitter should be avoided.
> 
> Though I have a bias toward the definition produced by this WG, in RFC
> 4689, I'm less concerned with what definition we choose (3393, 4689,
> 6049, other) than with having that definition clearly spelled out.
> 
> Underspecification can lead to different RFC-compliant test sets
> producing different results, and no one wants that.
> 
> dn
> 
> 
> >
> > 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
> 
> _______________________________________________
> bmwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bmwg