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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 23 Apr 2006 14:17:47 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Allman
> Sent: Saturday, April 22, 2006 10:47 PM
> To: Al Morton
> Cc: Wijnen, Bert (Bert); Romascanu, Dan (Dan); [email-masked]; 
> Mreview (E-mail)
> Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt 
> 
> 
> Al-
> 
> > Yes, but your comments on this applied to section 3.
> > 
> > We use the message number in the reordering singleton 
> definition.  We 
> > also agreed to keep SrcTime as a mandatory parameter, and 
> mention time 
> > and bytes only as secondary means to determine order.  When we 
> > discussed this in Minneapolis last year, you came to the 
> mic to agree 
> > with this, even where we did not implement your comments 
> verbatim (as 
> > with the SrcTime parameter).  A summary of comments and responses is
> > here: http://www3.ietf.org/proceedings/05mar/slides/ippm-1.pdf
> > 
> > We're discussing a later section here (4.5), and you expressed no 
> > objections about using time to quantify the extent of reordering, 
> > AFAIK.
> 
> Doh!  This is what I get for not going back and looking at the draft.
> You're right that my objection was in terms of determining 
> the out-of-orderness and not determining the extent or the 
> characteristics this dynamic created.  I do support the use 
> of time for characterizing reordering events, just not for 
> determining the event.  But, somehow I misread the context of 
> Bert's note.  In any case, sorry for the spurious chud.  I'll 
> shut up now! :)
> 
> allman
> 
> 

The context of the question is the comment made by Bert Wijnen wrt.
Section 4.5 of the document in preparation of the discussion of the
document in the IESG on 4/27. Bert is asking how 'would the metric be
comparable from one to the other measurement if one of them uses msg
sequence numbers, while the other uses "units of time". Even if two of
them use "units of time" but different units (e.g. micro seconds vs
milliseconds) even then they would not be comparable.'

I believe that his question is still pending. 

Dan

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 25 Apr 2006 18:03:35 +0200

Thanks Al, you summarized our discussion wel.

Bert

> From: Al Morton [mailto:[email-masked]]
> Sent: Tuesday, April 25, 2006 17:53
> To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); [email-masked]
> 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
>