Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt

[Nalini Elkins <[e-mail]>]

Al,

Thanks for your thorough examination and great comments.  My responses are inline.   Also, if you have time in Vancouver, Mike & I would like to ask you to have lunch or dinner on us.   It is the least we can do for all your help!  Please let us know if you have a free day.


>Early in the Intro, the various time/number fields are referred to as "base metrics" themselves.
>I know you'll want to clarify that (they are just fields).

Sure.

>In section 1.2: in addition to time and seq number for current packet:

 >                PSNLR : Packet Sequence Number Last Received
 >               TSLR  : Timestamp Last Received

>the device supplying the header appears to need to maintain flow state to add
>these "last packet" fields. A very strong justification is probably needed. 
>Later, I see that the Server host essentially has to store the fields across 
>request-response pairs. Lower and higher layers need to work together,
>somehow.

The Destination Options Header is created only by the OS's at the end points.  That is, the Microsofts, linuxes, and IBM's of the world.  The OS at the end point already maintains state.   If you think of TCP TimeWait status for example.   The connection is in TimeWait status for 2 * MSL.  So, obviously state is being maintained.  Anyway, all the OS's have control blocks associated with each active connection.

Now, there is going to be some discussion by the OS vendors about non-TCP protocols!  I have participated in those discussions with IBM in a former life (when they OEMed a product of mine & I wanted them to do something!)  but I believe that they are persuadable.   I am guessing that this information is already being maintained.  All we are asking for is for it to be exposed.

Our header is not for middle boxes.  We are not asking for router, etc. to maintain state in this way.


>In Section 3.1 and 3.2, it's not clear which PDM time-stamps support the (round-trip delay
>and server delay) metrics. When you look at  RFC2681, it should be fairly clear where 
>the time stamps are applied, and that needs to carry though here (though I see it later
>in the example).

I will clarify.

>Looking at the example in section 4, there can be a significant delay between when
>the application layer transfers packets to TCP's send buffer and when the packets are
>actually sent "on the wire" (as we say in IPPM), which happens after the IP header is
>applied (or most of the header, in some cases). How would accuracy be maintained
>across all the different layers? 

>Maybe another way to phrase the question is this:
>How does the process that adds the PDM header (with last Seq number 25) know 
>which packet to add it to? 

There are 2 questions here.  First, it will be the IP layer adding the times.  Yes, I know that it is a "gross" measurement comprising of a number of components.  But, then so is one-way delay.  That is,  there are multiple components within the path.   The purpose of our measurements is to allow the diagnostician to do very quick triage.  That is, to say, is the problem in the network or the server?  Then, we hand the problem off to the right group who can runmore detailed diagnostic tests.   

In our experience, this is a very valuable kind of measurement to have.  A great deal of time, effort and money is spent at large end user sites to determine just this.   Anecdotal evidence tells me that this is true for home users of the Internet also.   My working life has been spent at large data centers, so that I can answer to without any hesitation.

> I note that there is IPR declared on this draft, and licensing is not clear.

Yes, we do have IPR.  I hope I have declared it properly!  Please let me know if I have not.  We have not decided on the exact nature of the licensing but it will be very reasonable.  We want the technology adopted.    There are
more advanced metrics which can be created from these which is the primary reason for the IPR.

BTW, we are starting to engage in discussions also with folks looking at a new WG. https://sites.google.com/site/transportprotocolservices/home/charter-proposal-before-bof
We feel our metrics / header can help with a unified Simple Congestion Control (SCC) and Inter-Layer Communication (ILC).   That is some of our other work.   The above group seems to feel that work would fit in with their efforts!  I feel that the fields we propose are simple yet very powerful.  Many uses can be made of them.   I can tell you more on this, if you have interest.


________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Nalini Elkins [[e-mail]]
Sent: Friday, October 04, 2013 9:10 AM
To: WG ([e-mail]); 6man WG; [e-mail]
Cc: Sigfrido Perdomo; [e-mail]; Bill Jouris; Ackermann Michael
Subject: [ippm] Fw: New Version Notification for        draft-elkins-ippm-pdm-metrics-00.txt

We have submitted a number of drafts.  Some are new and some are updates to our existing PDM proposal.  We would appreciate any comments, questions, and corrections from the lists.


The new ones are:

1.  In IPPM:

http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt

This describes the base and derived metrics which can be obtained from the IPv6 PDM DO Extension Header.


2.  In TicToc:

http://www.ietf.org/internet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00.txt

This describes how NTP may be implemented to support PDM.


The updates are as follows

1.  In 6man:

http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt

This is the layout of the PDM DO header.


2.  In v6ops:

http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-packet-sequence-needed-01.txt

http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pdm-recommended-usage-01.txt

http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-end-to-end-rt-needed-01.txt

These are background for the proposal.


Thanks,

Nalini Elkins
Inside Products, Inc.
[phone]
www.insidethestack.com

----- Forwarded Message -----
From: "[e-mail]" <[e-mail]>
To: Nalini Elkins <[e-mail]>; William Jouris <[e-mail]>
Sent: Thursday, October 3, 2013 8:04 PM
Subject: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt


A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt
has been successfully submitted by Nalini Elkins and posted to the
IETF repository.

Filename:    draft-elkins-ippm-pdm-metrics
Revision:    00
Title:        IPPM Considerations for the IPv6 PDM Extension Header
Creation date:    2013-10-03
Group:        Individual Submission
Number of pages: 14
URL:            http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt
Status:          http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics
Htmlized:        http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-00


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. These
  metrics are defined in the IPv6 Performance and Diagnostic Metrics
  Destination Option (PDM). The base metrics are: packet sequence
  number and packet timestamp. Other metrics may be derived from these
  for use in diagnostics.  This document specifies such metrics, their
  calculation, and usage.





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<http://tools.ietf.org/>.

The IETF Secretariat