RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt

Thanks Al, you summarized our discussion wel.

Bert

> -----Original Message-----
> From: Al Morton [mailto:acmorton@att.com]
> Sent: Tuesday, April 25, 2006 17:53
> To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); ippm@ietf.org
> Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt
> 
> 
> IPPM,
> 
> After several off-list exchanges with Bert and Dan, we have a better
> statement of the issues Bert raised w.r.t. reordering metrics Sec 4.5:
> 
> 1. Metrics with multiple output parameters are somewhat problematic
> for NM systems, and a simple MetricName:value relationship is desired.
> 
> If we defined two metrics in Sec 4.5, they could be called:
>       Type-P-Packet-Reordering-Gap-Stream
>       Type-P-Packet-Reordering-GapTime-Stream
> and then we could easily refer to them in the IANA section,
> and get a metric number assigned to each one in the registry.
> 
> However, I see that we would have to do the same thing in Sec 4.6.
> There are four output parameters that we defined, so we would
> need a new metric name for each one:
>       Type-P-Packet-Reordering-Free-Run-x-numruns-Stream
>       Type-P-Packet-Reordering-Free-Run-q-squruns-Stream
>       Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream
>       Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream
> 
> An alternative to adding all these new metric names would
> be to simply revise the (new) IANA section to reflect the existence
> of output parameters, but this seems less straightforward.
> 
> So the current plan is to add the new metric names and corresponding
> entries in the IANA section. (Also, it's possible to revise the
> text of section 4.5 to make it more clear the GapTime is optional,
> and we'll make those changes while in that neighborhood.)
> 
> 
> Back to Bert's Issues:
> 2. When a metric is reported in units of time, it's much easier
> to compare the results between systems if the same resolution
> is used, and some standard solution should be developed.
> 
> My conclusion is that all the "time" metrics in the current
> IPPM registry RFC 4148 would not necessarily be reported
> with a standard resolution because IPPM has allowed flexibility
> in this area (and even the units might differ: seconds vs. millisec).
> In order for the registry to be useful, more standardization
> is needed, and the need is larger than the reordering draft.
> I believe we need an agreement/solution that covers all
> our metrics as pertains to their values stored and reported in the
> context of the metric registry.
> 
> Also, Randy Presuhn observed that we have have not explicitly
> specified the units of time in the reordering draft, possibly
> because we been using the word "time" synonymously with "seconds".
> This is easily corrected in sections 4.3 and 4.5, where we
> would specify units of seconds explicitly.
> 
> Constructive comments on any of these issues would be welcome.
> 
> Al
> 

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm