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

[Ray Hunter <[e-mail]>]

Nalini Elkins wrote:
> All,
>
> I have updated the PDM specification to add a second PDM type which requires NO time synchronization.   The draft for IPPM which describes how to calculate and use the values described in the PDM.   The IPPM draft is:
>
> http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-01
>
>
> I would appreciate any comments or feedback. 
>
>
> A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-option-03.txt
> has been successfully submitted by Nalini Elkins and posted to the
> IETF repository.
>
> Filename:     draft-elkins-6man-ipv6-pdm-dest-option
> Revision:     03
> Title:         IPv6 Performance and Diagnostic Metrics Destination Option
> Creation date:     2013-10-15
> Group:         Individual Submission
> Number of pages: 18
> URL:             http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-03.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-03
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-elkins-6man-ipv6-pdm-dest-option-03
>
> 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

I have read this draft.

All in all it seems rather simplistic, and I can't help thinking that
there's much more to this than is expressed in the draft.

For example, the server time calculation seems to assume that a response
packet has to be sent immediately by every application as soon as data
has been processed: every response requires a response.

What additional processing is required to cater for cases where the
sender and the receiver simply have nothing to say to each other at that
point in time?

e.g. a simple poll response protocol that is triggered every minute
would seem to suggest that there's a minimum of a sixty second server
processing time in the poller, when in fact it's just not doing anything
at all for this process.

Likewise, the calculations for round trip time do not seem to take into
account any packet drops or duplicates, which would seem to suggest to
me that the protocol as described would report packet drops as
additional latency, rather than any sort of protocol recovery/
retransmission timers being triggered.

Wouldn't the PDM sequence numbers have to be linked to TCP sequence
numbers when calculating stats? And for UDP you'd have no indication (or
have to use some app specific sequence number or hash to detect forward
progression of the flow)?

-- 
Regards,
RayH