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

From: Nalini Elkins <[email-masked]>
Date: Tue, 15 Oct 2013 17:03:51 -0700 (PDT)

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

---

From: Ray Hunter <[email-masked]>
Date: Wed, 16 Oct 2013 15:14:58 +0200

> until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Nalini Elkins <[email-masked]>
Date: Wed, 16 Oct 2013 06:41:08 -0700 (PDT)

>there's much more to this than is expressed in the draft.

Yes.  There is.  See below.

>has been processed: every response requires a response.

Not at all.

>sender and the receiver simply have nothing to say to each other at that

Frankly, other than keep-alives, I have not seen this.  Please correct me if I am wrong.

The logic for processing and making 'sense' of these metrics is much more complex than the fields to be sent.  This is as it should be.   The OS needs to send packets quickly.  After the fact, we can take our time and do analysis.

What needs to be handled (at a minimum) are the following cases.  You may have more.

1.   Host clocks not synchronized - done
2.   IP fragmentation 
3.   Multiple sends from one side (multiple segments) 
4.   Out of order segments (PSN will go negative)
5.   Retransmits (PSN will go negative)
6.   One–way transmit only (ex. FTP)  (server delta will continually increase)
7    Delayed acks
8.   ACKs preceeding send for another reason
9    Proxy servers
10. Full duplex traffic
11. Keep alive (0 / 1 byte segments, larger segments)
12. No response from other side (your case - which I believe to fall under Keep Alives)  
,

I have only provided the most basic case in this draft.   But, have thought a great deal about these others and how they would be handled.  I can provide packet flows for all these above to let you know how these can be handled.  Again, if you have more cases, I welcome your input.

Additionally, I am in no way suggesting that this be the ONLY metric that is used to calculate errors or performance.  For example,  if you look at my definition of the "Retransmit Duplication" metric, you will see that TCP sequence number is used in addition to the Packet Sequence Number to good effect. 

Regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Wed, 16 Oct 2013 16:14:23 +0200

> Nalini Elkins <mailto:[email-masked]>
> 16 October 2013 15:41
>> I have read this draft.
>

Then I would humbly suggest that you consider keeping this as a clean
standards track draft just defining the message formats for the
transport (in 6man WG) = Section 1 & 2, and leave the use cases,
architecture, and calculations to other informational drafts (e.g. in
ippm) = Section 3,4. c.f. SNMP
> I have only provided the most basic case in this draft.   But, have thought a great deal about these others and how they would be handled.  I can provide packet flows for all these above to let you…

6. one way transmit only (e.g.real time transports and streaming
protocols, although RTP has it's own timestamps based on NTP)

13. Drop without retransmit (real time transports)
14. Looped packets (where the same packet may pass the same point
multiple times without duplication)
15. Multihoming via Shim6

-- 
Regards,
RayH

---

From: Nalini Elkins <[email-masked]>
Date: Wed, 16 Oct 2013 07:27:55 -0700 (PDT)

Ray,

Thank you very much for your comments and your great use cases.

>ippm) = Section 3,4. c.f. SNMP
 
I will do this and provide an updated version of both IPPM and 6Man documents by end of day today.  I will also add use cases to the IPPM document.

If any others have use cases or comments, I would very much appreciate hearing from you.

Thanks,
Nalini