Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

[Ray Hunter <[e-mail]>]

Nalini Elkins wrote:
> All,
>
> I have revised the 6man submission to take out the calculations and packet flows.  All of these are in the IPPM document.   A notation of all the usage cases that this methodology should handle has also been added to the IPPM draft.
>
> The IPPM draft is here: http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics/
>
> The 6man draft is below.
>
> I appreciate any thoughts and comments.
>
> A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-option-04.txt
> has been successfully submitted by Nalini Elkins and posted to the
> IETF repository.
>
> Filename:     draft-elkins-6man-ipv6-pdm-dest-option
> Revision:     04
> Title:         IPv6 Performance and Diagnostic Metrics Destination Option
> Creation date:     2013-10-16
> Group:         Individual Submission
> Number of pages: 12
> URL:             http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-04.txt
> Status:          http://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option
> Htmlized:        http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-elkins-6man-ipv6-pdm-dest-option-04
>
> Abstract:
>    To diagnose performance and connectivity problems, metrics on real
>    (non-synthetic) transmission are critical for timely end-to-end
>    problem resolution. Such diagnostics may be real-time or after the
>    fact, but must not impact an operational production network. The base
>    metrics are: packet sequence number and packet timestamp.  Metrics
>    derived from these will be described separately. This document solves
>    these problems with a new destination option, the Performance and
>    Diagnostic Metrics destination option (PDM).
>
>
>                                                                                   
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat

Given that it seems to me that:

1) encoding has to be fast, but decoding does not
2) a node's clock could be either in our out of synch with some notional
master clock (e.g. via NTP)
3) two clocks could be in synch to a master source, but the master
sources may themselves not share a common source (one sourced from GPS,
one from DCF77)
4) the key to being able to perform the end to end calculations is
whether two communicating nodes are synchronised to the same master
clock (within some level of error/jitter)
5) the absolute time is not particularly important

Q1. Why do you want to encode differences as deltas in the case of an
unsynchronised/ free running clock?

Isn't that slow, and difficult for hardware implementations to achieve
(e.g. TCP offload)?
Doesn't it also require maintaining large amounts of state in the
sending node.
 
Why not just encode the timestamp as-is and perform the appropriate
difference calculation during decoding?

Q2. Why do you need two separate packet formats at all?

Why not have a common format for all cases, containing a timestamp based
on the local clock, plus an optional field containing a flag that states
if the local timestamp is coordinated to some master clock, plus an
identifier for the master clock.

You could then encode whether a node had a free-running clock (case 2),
a synchronised clock (case 1), and whether it was synched via NTP to
some stratum 0 source e.g. GPS, and also some identification of the
stratum 1 source (IPv6 address).

Two communicating nodes could then use e.g. NTP trace to see if they
shared a common clock source or not, before performing their calculations.

IMHO that would then allow you to place some error bounds on your time
calculations, whilst also simplifying the implementation for the sender.

-- 
Regards,
RayH