Curtis,
Lots of thanks for a prompt and delayed response.
Please see some comments inline below. I've shipped the next that is not
related to these comments.
Regards,
Sasha
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, March 09, 2011 2:06 AM
> To: Alexander Vainshtein
> Cc: [email protected]; [email protected]; Zhao, Peng (NSN - CN/Shanghai);
> Pietilainen, Antti (NSN - FI/Espoo); [email protected];
> [email protected]; Mallette, Edwin
> Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp
>
--- snipped ---
> > 2. The "timestamp capture point in the data path" was not about the
> > timestamp location in the message. It is about the stage of the data
> > processing when the timestamp can be captured. E.g., some designs use
> > commercial HW that captures the timestamps between PHY and MAC. This
> > is OK for PTP and NTP, but excludes the time spent in the egress
> queue
> > of the node from delay measurement.
>
> That is why in NTP, PTP, and draft-ietf-mpls-loss-delay there are four
> timestamps. The total round trip delay subtracts the third and second
> to eliminate queuing and turn around.
[[[Sasha]]] Please consider the following use case:
- I am going to use a certain LSP as a tunnel for TDM PWs
- I would like to measure packet delay *variation* (PDV) introduced by this LSP
in order to configure the jitter buffer of these TDM PWs. I expect to do that
by measuring delay for multiple samples and computing the PDV as (Max. measured
delay - Min. measured delay)
- If queuing delay at the LSP head- and tail-nodes is not accounted in my delay
measurements, my PDV estimation will not account for that also (because queuing
only increases Max. measured delay)
- As a consequence, my PDV estimation may be not suitable for configuring the
jitter buffer correctly. As a consequence, my TDM customers will see errors in
their traffic when TDM PW packets that arrive too late to be accommodated into
the jitter buffer are discarded and their payload replaced with "all ones".
Do I miss something here?
>
> > 3. You have said that 20 microseconds look to you as very good
> > accuracy for delay measurements. This probably depends on the
> > application. E.g., if we must synchronize two base stations within 2-
> 3
> > microseconds of relative ToD error, this accuracy will hardly help
> you
> > to understand why your synchronization mechanisms do not work:-). I
> > am somewhat suspicious about a measurement procedure that does not
> > specify accuracy explicitly. But I understand the position taken by
> > the draft authors.
>
> 20 usec is OK for draft-ietf-mpls-loss-delay type measurements.
[[[Sasha]]] I would be happy to accept that. But the draft does not yield this
(or any other) number.
--- snipped to the end ---
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
