[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ippm] need of sync of clocks in dup metric def
Hi Henk,
Now we have a clear picture of the reason of need of sync. So at this step I think that we have to put that in the discussion section of the singleton metric definition.
Regards
Emile
> -----Message d'origine-----
> De : Henk Uijterwaal [mailto:henk at ripe.net]
> Envoyé : vendredi 19 octobre 2007 08:43
> À : Al Morton
> Cc : Jeff W. Boote; STEPHAN Emile RD-CORE-LAN; IETF IPPM WG
> Objet : Re: [ippm] need of sync of clocks in dup metric def
>
> Al Morton wrote:
> > At 11:48 AM 10/18/2007, Jeff W. Boote wrote:
> > ...Emile wrote:
> >>> Packet duplication differs. The reference of time for waiting a copy
> is
> >>> the arrival of a first image of the packet. So it does rely on any
> >>> remote time.
> >>
> >> A lost packet, should never be counted as a duplicate. These metrics
> >> should not be looked at in isolation - they are related.
> >
> > We should be using one waiting time-out for all arrivals of
> > a packet launched at T, T+Th. That's how the ITU-T definition
> > works, and the RFC 2680 definition for loss:
>
> I agree.
>
> Henk
>
> >
> >> ...
> >> + If the packet fails to arrive within a reasonable period of time,
> >> the one-way packet-loss is taken to be one. Note that the
> >> threshold of "reasonable" here is a parameter of the methodology.
> >>
> >> {Comment: The definition of reasonable is intentionally vague,
> and
> >> is intended to indicate a value "Th" so large that any value in
> >> the closed interval [Th-delta, Th+delta] is an equivalent
> >> threshold for loss. Here, delta encompasses all error in clock
> >> synchronization along the measured path. If there is a single
> >> value after which the packet must be counted as lost, then we
> >> reintroduce the need for a degree of clock synchronization
> similar
> >> to that needed for one-way delay. Therefore, if a measure of
> >> packet loss parameterized by a specific non-huge "reasonable"
> >> time-out value is needed, one can always measure one-way delay
> and
> >> see what percentage of packets from a given stream exceed a given
> >> time-out value.}
> >
> >
> >
> >
> >
>
>
> --
> --------------------------------------------------------------------------
> ----
> Henk Uijterwaal Email:
> henk.uijterwaal(at)ripe.net
> RIPE Network Coordination Centre
> http://www.amsterdamned.org/~henk
> P.O.Box 10096 Singel 258 Phone: +31.20.5354414
> 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445
> The Netherlands The Netherlands Mobile: +31.6.55861746
> --------------------------------------------------------------------------
> ----
>
> Is one of the choices leaving the office open?
> Alan Greenspan on the next
> elections
_______________________________________________
ippm mailing list
ippm at ietf.org
https://www1.ietf.org/mailman/listinfo/ippm