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

Ray Hunter <> Wed, 16 October 2013 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAC7F11E82A7; Wed, 16 Oct 2013 06:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h3cjMEz5564x; Wed, 16 Oct 2013 06:15:10 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f14:62e::2]) by (Postfix) with ESMTP id B3F7B11E82AB; Wed, 16 Oct 2013 06:15:05 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF19687007F; Wed, 16 Oct 2013 15:15:00 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4-eHjwW1gte4; Wed, 16 Oct 2013 15:15:00 +0200 (CEST)
Received: from Rays-iMac-2.local (unknown []) (Authenticated sender: by (Postfix) with ESMTPA id 915A9870073; Wed, 16 Oct 2013 15:15:00 +0200 (CEST)
Message-ID: <>
Date: Wed, 16 Oct 2013 15:14:58 +0200
From: Ray Hunter <>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: Nalini Elkins <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops WG <>, 6man WG <>, "" <>
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Oct 2013 13:15:11 -0000

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:
> 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:   
> Status:
> Htmlized:
> Diff:  
> 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
> 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)?