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

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Michael,

Regarding one of your questions below:
My question for you is whether you think we SHOULD craft additional PDM function that  CAN be populated and/or utilized expressly for or by Middle Boxes?
This would likely involve more complexity and overhead, but may be warranted if associated value is perceived.

Yes, but it has been attempted by dedicated flow monitoring appliances.
I did some research and reading about this topic today.
Have a look at:
http://tools.ietf.org/html/draft-mornulo-ippm-registry-columns-01#section-6
and the references.

This is a case of completely passive RTT measurement on TCP(SYN/SYN_ACK)
request response pairs, but with the addition of the IPv6 PDM, one could
attribute the delay properly to network beyond the monitoring point
and server (the later doesn't change).  The main point is that it should be
do-able to do the correlations mid-path, without help from the app
(as you would have at the server end).

Of course, there's a cost for these middlebox monitoring instances,
and you have to have sufficient coverage to observe both directions
of the connection. So, what's needed is a compelling case where troubleshooting
is enhanced by the middlebox measurements, perhaps when multiple networks
are involved in the path.

hope this helps,
Al



From: Ackermann, Michael [mailto:[e-mail]]
Sent: Tuesday, October 15, 2013 12:41 PM
To: Nalini Elkins; MORTON, ALFRED C (AL); [e-mail]
Cc: Sigfrido Perdomo; [e-mail]; Bill Jouris
Subject: RE: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt

Hi Al,

Echoing Nalini's thoughts regarding  your great comments/questions and how excited we are about the potential of working with you and your teams.

Nalini's answers are great in my view and I have one comment/question on the topic of "Middle Boxes", which in my view includes Routers and Firewalls.     As Nalini said, the PDM was conceived to be populated and utilized primarily  by End Points, which will be Hosts/IP Stacks of various types.     The biggest function we had in mind for the Middle Boxes, was to just not drop or alter the PDM.      My question for you is whether you think we SHOULD craft additional PDM function that  CAN be populated and/or utilized expressly for or by Middle Boxes?
This would likely involve more complexity and overhead, but may be warranted if associated value is perceived.

I would also like endorse Nalini's answer on your great and very fascinating question about The APP, TCP and other time breakdowns.      As a lowly customer/end user (while Nalini is a Diagnostic Software Expert), I share her view on the value of the "Network Triage".     Knowing whether the time is being spent in the Host, Network and in what direction, is critically valuable.    This may tell you all you need to know, or other tools take over at that point for more granular diagnostics.    So, in my view that level of granular diagnostics is beyond the scope of the PDM, but would luv, luv, luv to talk more about this with you.

Thanks again and look forward to seeing you in Vancouver!

Mike



From: Nalini Elkins [mailto:[e-mail]]
Sent: Tuesday, October 15, 2013 9:44 AM
To: MORTON, ALFRED C (AL); [e-mail]
Cc: Sigfrido Perdomo; [e-mail]; Bill Jouris; Ackermann, Michael
Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt

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]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] On Behalf Of Nalini Elkins [[e-mail]<mailto:[e-mail]>]
Sent: Friday, October 04, 2013 9:10 AM
To: WG ([e-mail]<mailto:[e-mail]>); 6man WG; [e-mail]<mailto:[e-mail]>
Cc: Sigfrido Perdomo; [e-mail]<mailto:[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<http://www.insidethestack.com/>

----- Forwarded Message -----
From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
To: Nalini Elkins <[e-mail]<mailto:[e-mail]>>; William Jouris <[e-mail]<mailto:[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




The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.