Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt

From: "Schmoll, Carsten" <[email-masked]>
Date: Fri, 21 Apr 2006 11:46:26 +0200

Dear all,

please see some comments inline.

> -----Original Message-----
> From: Henk Uijterwaal [mailto:[email-masked]] 
> Sent: Friday, April 21, 2006 10:51 AM
> To: Schmoll, Carsten; stanislav shalunov; [email-masked]
> Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt
> 
> Carsten: If median cannot be used, then please explain why.

Technically median delay can of course be used, yet I don't 
see its importance, since it does capture the influence of 
dalay spikes/outliers even *less* than average delay - and a change
in those outliers, i.e. the tail of the delay distribution is
often the most significant issue to know when checking whether
some service could run with an acceptable quality. In case
I forgot about some important property of median delay, please 
let me know.

> >* duplication: just lacks definition of a default timeout value
> 
> I think we should define one time-out value for delay, loss and
> duplication.

Agree. The default value can be the same. It should be a 
safe upper limit for OWD. Those 2sec would be find with me.

> >   b) I'd personally like to see some "packet filter" added to the
> >      reporting record. Data might relate only to a fraction of all
> >      traffic, e.g. only to UDP or only to traffic from
videos.fun.org
> 
> The way I understood the set, is that this refers to 1 pair of
> source-destination, that is, you get 5 numbers for traffic 
> between src1 and dst1, then 5 other numbers for src1 to dst2.

Yes, I would say so too. This opens the question: are src+dst part of
the reported parameters, part of the request by the client, or both?

With best regards,
Carsten.

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

---

From: stanislav shalunov <[email-masked]>
Date: 25 Apr 2006 18:29:31 -0400

"Schmoll, Carsten" <[email-masked]> writes:

> dalay spikes/outliers even *less* than average delay

Exactly.  In other words, median is more robust.

> - and a change in those outliers, i.e. the tail of the delay
> distribution is often the most significant issue to know when
> checking whether some service could run with an acceptable quality.

Jitter characterizes how variable the delay is.  Delay is as robust as
possible and does not attempt to characterize micro-variation; indeed,
it avoids doing so for orthogonality reasons.

> In case I forgot about some important property of median
> delay, please let me know.

> safe upper limit for OWD. Those 2sec would be find with me.

That's what we have.

> the reported parameters, part of the request by the client, or both?

The former.  There is not necessarily anything one might call a client.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed at an angle of 45 degrees.