Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ippm-6man-pdm-option: Minor and editorial

From: <[email-masked]>
Date: Fri, 10 Mar 2017 15:13:55 +0000 (UTC)

Al,

Love it!!!

Jouni?   Anyone else?

Thanks so much, Al.   What would I do without you?

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

--------------------------------------------
On Fri, 3/10/17, MORTON, ALFRED C (AL) <[email-masked]> wrote:

 Subject: RE: Gen-ART review of draft-ietf-ippm-6man-pdm-option:  Minor and editorial
 To: "[email-masked]" <[email-masked]>, "jouni.nospam" <[email-masked]>
 Cc: "General Area Review Team" <[email-masked]>, "[email-masked]" <[email-masked]>, "Michael Ackermann" <[email-masked]>, "Robert Hamilton" <[email-masked]>
 Date: Friday, March 10, 2017, 7:05 AM
 
 Hi Nalini,
 
 Let me suggest a few quick clarifications in a top-post:
 
 I liked your original first sentence, with the SHOULD,
 that's really all we can ask. The last sentence was 
 quite practical, too.
 
 Also, wiretime is a concept/notion, the ideal we try
 to get close to achieving in practice. And we need to 
 say what H and L are, so, here's my proposal...
 
 Re-Revised Section 3.5.2
 ----------------------------
 
 3.5.2  PDM Timestamps
  
 The PDM timestamps SHOULD be taken as close to the
 network interface as possible.
 The PDM timestamps are intended to isolate wire time from
 server or host time, but may necessarily attribute some
 host processing time to network latency.
 
 RFC2330 [RFC2330] "Framework for IP Performance Metrics"
 describes two notions of wire time in section 10.2.
 These notions are only defined in terms of an Internet host
 H 
 observing an Internet link L at a particular location:
 
  +    For a given packet P, the 'wire arrival
 time' of P at H on L is
       the first time T at which any bit of P
 has appeared at H's
       observational position on L.
 
  +    For a given packet P, the 'wire exit time'
 of P at H on L is the
       first time T at which all the bits of P
 have appeared at H's
       observational position on L."
 
 Not all implementations will be able to achieve the
 ideal level of measurement.
 
 Al
 
 > -----Original Message-----
 > From: [email-masked]
 > [mailto:[email-masked]]
 > Sent: Friday, March 10, 2017 9:44 AM
 > To: [email-masked];
 jouni.nospam; MORTON, ALFRED C
 > (AL)
 > Cc: General Area Review Team;
 draft-ietf-ippm-6man-pdm-
 > [email-masked];
 Michael Ackermann; Robert Hamilton
 > Subject: RE: Gen-ART review of
 draft-ietf-ippm-6man-pdm-option: Minor
 > and editorial
 > 
 > Al,
 > 
 > I should have remembered that from RFC2330!
 > 
 > Thanks for pointing that out.  My revised wording
 inline.
 > 
 > Nalini
 > 
 > --------------------------------------------
 > On Fri, 3/10/17, MORTON, ALFRED C (AL) <[email-masked]>
 wrote:
 > 
 >  Subject: RE: Gen-ART review of
 draft-ietf-ippm-6man-pdm-option:  Minor
 > and editorial
 >  To: "[email-masked]"
 > <[email-masked]>,
 "jouni.nospam"
 > <[email-masked]>
 >  Cc: "General Area Review Team" <[email-masked]>,
 "draft-ietf-ippm-
 > [email-masked]"
 <draft-ietf-ippm-6man-pdm-
 > [email-masked]>,
 "Michael Ackermann" <[email-masked]>,
 > "Robert Hamilton" <[email-masked]>
 >  Date: Friday, March 10, 2017, 6:21 AM
 > 
 >  > -----Original Message-----
 >  > From: [email-masked]
 >  > [mailto:[email-masked]]
 >  > Sent: Friday, March 10, 2017 8:55 AM
 >  > To: [email-masked];
 >  jouni.nospam
 >  > Cc: General Area Review Team;
 >  draft-ietf-ippm-6man-pdm-
 >  > [email-masked];
 >  Michael Ackermann; Robert Hamilton
 >  > Subject: Re: Gen-ART review of
 >  draft-ietf-ippm-6man-pdm-option: Minor
 >  > and editorial
 >  >
 >  > Jouni,
 >  >
 >  > Our team has been discussing this.   So,
 >  please let us know what you
 >  > think about the wording below:
 >  >
 >  >
 >  > Wording to be added to section 3.5
 Implementation
 >  Considerations (will
 >  > make the current considerations 3.5.1)
 >  >
 > 
 >
 ************************************************************************
 >  >
 *************************************************
 >  >
 >  > 3.5.2  PDM Timestamps
 >  >
 >  > The PDM timestamps SHOULD be taken as close
 to the
 >  network interface as
 >  > possible.   This will ensure the most
 >  accurate measurements.
 >  >
 >  > The ideal PDM reference plane or timestamp
 location
 >  is:
 >  >
 >  > - Send direction: when the first bit of the
 first octet
 >  of the IP header
 >  > is received for output by the network
 interface
 >  >
 >  > -  Receive direction when the first bit of
 the
 >  first octet of the IP
 >  > header is received for input by the network
 interface.
 >  >
 >  > Not all implementations will be able to
 achieve the
 >  ideal level of
 >  > measurement.
 >  >
 >  [ACM]
 > 
 >  >Hi Nalini,
 > 
 > > It just occurred to me that your IPPM draft can
 reference
 > > the IPPM Framework RFC 2330, especially the
 section on
 > > clocks and Wiretime:
 > > https://urldefense.proofpoint.com/v2/url?u=https-
 >
 3A__tools.ietf.org_html_rfc2330-23section-2D10.2&d=DwIFaQ&c=LFYZ-
 o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=IPrnGy4K3nr5XaQh24815q0ZAYu
 LInXigPyegsEXaM0&s=3hPio_KWWSEZw3NhtTfAbT1mXSXhz_I2yP-WEL58K8I&e=
 > 
 > > IOW, we've been down this road before,
 > 
 > Revised Section 3.5.2
 > ----------------------------
 > 
 > 3.5.2  PDM Timestamps
 > 
 > The PDM timestamps are intended to isolate wire time
 from
 > server or host time.
 > 
 > RFC2330 [RFC2330] "Framework for IP Performance
 Metrics"
 > discusses measurement of wire time in section 10.2.
 > 
 > " +    For a given packet P, the 'wire
 arrival time' of P at H on L is
 >       the first time T at
 which any bit of P has appeared at H's
 >       observational position
 on L.
 > 
 >  +    For a given packet P, the 'wire
 exit time' of P at H on L is the
 >       first time T at which
 all the bits of P have appeared at H's
 >       observational position
 on L."
 > 
 > The timestamping methods used in a PDM implementation
 > MUST follow the guidelines provided by RFC2330.
 > 
 > 
 > 
 >  >
 >  > Thanks,
 >  >
 >  > Nalini Elkins
 >  > Inside Products, Inc.
 >  > www.insidethestack.com
 >  > (831) 659-8360
 >  >
 >  >
 --------------------------------------------
 >  > On Mon, 3/6/17, jouni.nospam <[email-masked]>
 >  wrote:
 >  >
 >  >  Subject: Re: Gen-ART review of
 >  draft-ietf-ippm-6man-pdm-option:  Minor
 >  > and editorial
 >  >  To: [email-masked]
 >  >  Cc: "General Area Review Team" <[email-masked]>,
 >  "draft-ietf-ippm-
 >  > [email-masked]"
 >  <draft-ietf-ippm-6man-pdm-
 >  > [email-masked]>,
 >  "Michael Ackermann" <[email-masked]>,
 >  > "Robert Hamilton" <[email-masked]>
 >  >  Date: Monday, March 6, 2017, 11:15 AM
 >  >
 >  >  Hi Nalini,
 >  >
 >  >  Thank you. Accurate
 >  >  timestamping is a non-trivial goal to
 achieve.
 >  You should
 >  >  have the “ideal” reference plane
 described
 >  (this usually
 >  >  is located close or within the network
 interface
 >  PHY) and
 >  >  the exact packet location described what
 >  constitutes the
 >  >  point that timestamp refers to (*). While
 most
 >  existing
 >  >  systems plain have no access to required
 >  resources/functions
 >  >  to do the timestamping “properly” you
 try
 >  your best and
 >  >  adjust the timestamp with the time you
 predict it
 >  takes to
 >  >  reach the “ideal” reference plane.
 This of
 >  course adds
 >  >  certain amount of error (just check the
 typical
 >  operating
 >  >  system context switch times) but you can
 get
 >  around it just
 >  >  by acknowledging the fact or the trying
 to
 >  describe your
 >  >  acceptable maximum error tolerance.. like
 +-1ms
 >  from the
 >  >  ideal timestamp if the packet were
 timestamped at
 >  the PDM
 >  >  defined reference plane and at the PDM
 defined
 >  message
 >  >  timestamping point. The former is
 obviously
 >  easier
 >  >  approach.
 >  >
 >  >  - JOuni
 >  >
 >  >  (*) example: when the first
 >  >  bit of the first octet of the IP header
 (i.e.,
 >  the first bit
 >  >  of IP version field) gets output by the
 PHY to
 >  the physical
 >  >  link. And to the receive direction when
 the first
 >  bit of the
 >  >  IP header is received by the network
 interface
 >  PHY.. or
 >  >  something similar. It does not be this
 strict as
 >  long as
 >  >  there is clear understanding what is going
 on.
 >  >
 >  >
 >  >  > On Mar 6, 2017, at
 >  >  6:41 AM, <[email-masked]>
 >  >  <[email-masked]>
 >  >  wrote:
 >  >  >
 >  >  > Jouni,
 >  >  >
 >  >  > OK.   I
 >  >  will look.   We are also working with a
 very
 >  well
 >  >  respected FreeBSD developer to create a
 version
 >  of FreeBSD
 >  >  which has PDM in it.
 >  >  >
 >  >  > We need to know exactly what choices
 one
 >  >  has in the OS stack itself.
 >  >  >
 >  >  > Thanks,
 >  >  >
 >  >  > Nalini Elkins
 >  >  > Inside
 >  >  Products, Inc.
 >  >  >
 >  >  www.insidethestack.com
 >  >  > (831)
 >  >  659-8360
 >  >  >
 >  >  >
 >  >  > From: jouni.nospam <[email-masked]>
 >  >  > To: [email-masked]
 >  >
 >  >  > Cc: General Area Review Team <[email-masked]>;
 >  >  "[email-masked]"
 >  >  <[email-masked]>;
 >  >  Michael Ackermann <[email-masked]>;
 >  >  Robert Hamilton <[email-masked]>
 >  >  > Sent: Sunday, March 5, 2017 4:54 PM
 >  >  > Subject: Re: Gen-ART review of
 >  >  draft-ietf-ippm-6man-pdm-option: Minor
 and
 >  editorial
 >  >  >
 >  >  > Hi,
 >  >  >
 >  >  > Thank you for the
 >  >  updates. I am fine with them.
 >  >  >
 >  >  > I still have one fundamental
 complaint.
 >  >  There is no discussion or definition of
 the
 >  message
 >  >  timestamp points. All this nanosecond or
 better
 >  accuracy,
 >  >  and the concern of truncation inaccuracy
 do not
 >  really
 >  >  matter if the message timestamp point
 varies node
 >  to node or
 >  >  even within the node. I suggest taking a
 look at
 >  standards
 >  >  like IEEE 802.1AS, IEEE 1588v2 or IEEE
 1722 for
 >  discussions
 >  >  of this topic. You really need to have a
 good
 >  definition
 >  >  & discussion of the message timestamp
 point,
 >  or justify
 >  >  that in the text why it is not there.
 >  >  >
 >  >
 >  >  > Regards,
 >  >  >
 >  >     Jouni
 >  >  >
 >  >  >
 >  >  >
 >  >  > > On Feb 28, 2017, at 7:04 AM, [email-masked]
 >  >  wrote:
 >  >  > >
 >  >  > >
 >  >
 >  >  > >
 >  >  > >
 >  >  Jouni,
 >  >  > >
 >  >  > >
 >  >  We have posted a new version which
 addresses the
 >  minor and
 >  >  editorial comments. It is below.  I am
 waiting
 >  for your
 >  >  response to the major comments & then
 I will
 >  >  integrate.  As far as I know now, I have
 >  addressed all
 >  >  outstanding issues.  My comments to your
 >  editorial / minor
 >  >  is below.
 >  >  > >
 >  >  >
 >  >  > https://urldefense.proofpoint.com/v2/url?u=https-
 >  >
 > 
 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2D6man-2Dpdm-
 >  > 2Doption_&d=DwIFaQ&c=LFYZ-
 >  >
 > 
 o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=cYzACikChPQGF4cm8f-
 >  >
 wBWGYz8GduHbmLA55dmSpsuM&s=2eDvhYB5jPh66D2Mj4HHXH6UcQuJtuyffJfrrcNdiyw&e
 >  > =
 >  >  > >
 >  >  > >
 >  >  > > Nits/editorial comments:
 >  >  > >
 >  >  > >> 1)
 >  >  Section 1.4 numbered list: add missing
 full
 >  stops.
 >  >  > >
 >  >  > > Actually,
 >  >  I think it is better to remove the full
 stops
 >  from the two
 >  >  that have it.  These are sentence
 >  >  >
 >  >  > fragments.
 >  >  > >
 >  >  > >> 2) Section 3.2: remove
 >  >  > >
 >  >  > >>
 >  >  "The 5-tuple consists of
 >  >  > >
 >  >  > >>  the source and destination
 IP
 >  >  addresses, the source and destination
 >  >  >
 >  >  >
 >  >  > >>  ports, and the upper
 >  >  layer protocol (ex. TCP, ICMP, etc)."
 >  >  > >
 >  >  > >> since
 >  >  this is unnecessary repetition.
 >  >  > >
 >  >
 >  >  > >
 >  >  > > This
 >  >  is in the section below:
 >  >  > >
 >  >  > > Old
 >  >  > > ----
 >  >
 >  >  > > Packet Sequence Number This
 >  >  Packet (PSNTP)
 >  >  > >
 >  >  > > 16-bit unsigned integer.  This
 field
 >  >  will wrap. It is intended for
 >  >  > > use
 >  >  while analyzing packet traces.
 >  >  > >
 >  >
 >  >  > > Initialized at a random number
 >  >  and incremented monotonically for each
 >  >  >
 >  >  > packet of the session flow of the
 5-tuple.
 >  The
 >  >  5-tuple consists of
 >  >  > > the source
 >  >  and destination IP addresses, the source
 and
 >  destination
 >  >  > > ports, and the upper layer
 protocol
 >  >  (ex. TCP, ICMP, etc).  The
 >  >  > >
 >  >  random number initialization is intended
 to make
 >  it harder
 >  >  to spoof
 >  >  > > and insert such packets.
 >  >
 >  >  > >
 >  >  > > New
 >  >
 >  >  > > ----
 >  >  > >
 >  >  Packet Sequence Number This Packet
 (PSNTP)
 >  >  > >
 >  >  > > 16-bit
 >  >  unsigned integer.  This field will wrap.
 It is
 >  intended for
 >  >
 >  >  > > use while analyzing packet
 >  >  traces.
 >  >  > >
 >  >  >
 >  >  > Initialized at a random number and
 >  incremented
 >  >  monotonically for each
 >  >  > > packet of
 >  >  the session flow of the 5-tuple.
 >  >  > >
 >  >
 >  >  > >
 >  >  > >> 3)
 >  >  Section 3.2: remove
 >  >  > >
 >  >  > >> "Operating systems MUST NOT
 >  >  implement a single
 >  >  > >
 >  >  > >> counter for all
 >  >  connections."
 >  >  > >
 >  >  > >> Seems again like
 unnecessary
 >  >  repetition to previous sentence.
 >  >  > >
 >  >
 >  >  > >
 >  >  > > This
 >  >  is in the section on "Packet Sequence
 Number
 >  This
 >  >  Packet (PSNTP)"
 >  >  > >
 >  >  > > Old
 >  >  > > ---
 >  >
 >  >  > > Operating systems MUST
 implement
 >  >  a separate packet sequence number
 >  >  > >
 >  >  counter per 5-tuple. Operating systems
 MUST NOT
 >  implement a
 >  >  single
 >  >  > > counter for all
 >  >  connections.
 >  >  > >
 >  >  > > New
 >  >  > > ---
 >  >
 >  >  > > Operating systems MUST
 implement
 >  >  a separate packet sequence number
 >  >  > >
 >  >  counter per 5-tuple.
 >  >  > >
 >  >  > >
 >  >  > >> 4)
 >  >  Section 3.2 again unnecessary repetition
 of IPv6
 >  basics that
 >  >  can be read from RFC2460. Suggest strongly
 to
 >  remove:
 >  >  > >
 >  >  > >>
 >  >  "This indicates the following processing
 >  requirements:
 >  >
 >  >  > >
 >  >  > >>
 >  >  00 - skip over this option and continue
 >  processing the
 >  >  header.
 >  >  > >
 >  >  >
 >  >  >>  RFC2460 [RFC2460] defines other
 values
 >  for the
 >  >  Option Type field.
 >  >  > >
 >  >  > >> These MUST NOT be used in
 the
 >  >  PDM."
 >  >  > >
 >  >  >
 >  >  >> and
 >  >  > >
 >  >  > >> "The possible values are as
 >  >  follows:
 >  >  > >
 >  >  >
 >  >  >> 0 - Option Data does not change
 >  en-route
 >  >  > >
 >  >  > >>  1 -
 >  >  Option Data may change en-route
 >  >  > >
 >  >
 >  >  > >>  The three high-order bits
 >  >  described above are to be treated as part
 >  >  > >
 >  >  > >>  of
 >  >  the Option Type, not independent of the
 Option
 >  Type.  That
 >  >  is, a
 >  >  > >
 >  >  >
 >  >  >> particular option is identified
 by a
 >  full 8-bit
 >  >  Option Type, not just
 >  >  > >
 >  >  > >> the low-order 5 bits of an
 Option
 >  >  Type."
 >  >  > >
 >  >  >
 >  >  >
 >  >  > > Old
 >  >  >
 >  >  > ----
 >  >  > > Option Type
 >  >  > >
 >  >  > > The two
 >  >  highest-order bits of the Option Type
 field are
 >  encoded to
 >  >
 >  >  > > indicate specific processing of
 >  >  the option; for the PDM destination
 >  >  >
 >  >  > option, these two bits MUST be set to
 00.
 >  This
 >  >  indicates the
 >  >  > > following
 >  >  processing requirements:
 >  >  > >
 >  >  > > 00 - skip over this option and
 >  >  continue processing the header.
 >  >  > >
 >  >
 >  >  > > RFC2460 [RFC2460] defines other
 >  >  values for the Option Type field.
 >  >  > >
 >  >  These MUST NOT be used in the PDM.
 >  >  >
 >  >  >
 >  >  > > In keeping with RFC2460
 >  >  [RFC2460], the third-highest-order bit of
 the
 >  >  > > Option Type specifies whether or
 not
 >  >  the Option Data of that option
 >  >  > >
 >  >  can change en-route to the packet's final
 >  destination.
 >  >
 >  >  > >
 >  >  > > In the
 >  >  PDM, the value of the third-highest-order
 bit
 >  MUST be 0.
 >  >  The
 >  >  > > possible values are as
 >  >  follows:
 >  >  > >
 >  >  >
 >  >  > 0 - Option Data does not change
 en-route
 >  >  > >
 >  >  > > 1 - Option
 >  >  Data may change en-route
 >  >  > >
 >  >  > > The three high-order bits
 described
 >  >  above are to be treated as part
 >  >  > >
 >  >  of the Option Type, not independent of the
 Option
 >  Type.
 >  >  That is, a
 >  >  > > particular option is
 >  >  identified by a full 8-bit Option Type,
 not just
 >  >  > > the low-order 5 bits of an
 Option
 >  >  Type.
 >  >  > >
 >  >  > >
 >  >
 >  >  > >
 >  >  > > New
 >  >
 >  >  > > ----
 >  >  > >
 >  >  Option Type
 >  >  > >
 >  >  >
 >  >  > In keeping with RFC2460[RFC2460], the
 two
 >  high order
 >  >  bits of the Option Type field are encoded
 to
 >  >  > > indicate specific processing of
 the
 >  >  option; for the PDM destination
 >  >  > >
 >  >  option, these two bits MUST be set to 00.
 >  >  > >
 >  >  > > The third
 >  >  high order bit of the Option Type
 specifies
 >  whether or not
 >  >  the Option Data of that option
 >  >  > >
 >  >  can change en-route to the packet's final
 >  destination.
 >  >
 >  >  > >
 >  >  > > In the
 >  >  PDM, the value of the third high order bit
 MUST
 >  be 0.
 >  >  > >
 >  >  > >
 >  >  > >
 >  >  > > 5) Section
 >  >  3.3 same as in comment 4). Suggest
 strongly
 >  removing:
 >  >  > >
 >  >  > >>
 >  >  "This follows the order defined in
 RFC2460
 >  [RFC2460]
 >  >
 >  >  > >
 >  >  > >>
 >  >              IPv6 header
 >  >  > >
 >  >  > >>             
 Hop-by-Hop
 >  >  Options header
 >  >  > >
 >  >  > >>           
 Destination
 >  >  Options header  <--------
 >  >  > >
 >  >  > >>            Routing
 header
 >  >
 >  >  > >
 >  >  > >>
 >  >          Fragment header
 >  >  > >
 >  >  > >>         
 Authentication
 >  >  header
 >  >  > >
 >  >  >
 >  >  >>        Encapsulating
 Security
 >  Payload header
 >  >
 >  >  > >
 >  >  > >>
 >  >        Destination Options header
 >  <------------
 >  >  > >
 >  >  > >>
 >  >    upper-layer header"
 >  >  > >
 >  >  > >
 >  >  > >
 >  >  > >> 6) Suggest removing entire
 >  >  Section 3.4 and moving the following text
 to
 >  Section 3.3:
 >  >
 >  >  > >
 >  >  > >>
 >  >  "PDM MUST be placed before the ESP header
 in
 >  >  > >
 >  >  > >> order
 >  >  to work.  If placed before the ESP
 header, the
 >  PDM header
 >  >  will
 >  >  > >
 >  >  >
 >  >  >> flow in the clear over the
 network thus
 >  allowing
 >  >  gathering of
 >  >  > >
 >  >  > >> performance and diagnostic
 data
 >  >  without sacrificing security."
 >  >  >
 >  >  >
 >  >  > >
 >  >  > >
 >  >  ESP processing with PDM was changed
 because of
 >  comments from
 >  >  security reviewer.
 >  >  > >
 >  >  > >
 >  >  > >
 >  >  > >> 7) Section 3.6 suggest
 removing
 >  >  the following text. I see no value it
 would add
 >  to what has
 >  >  already been said:
 >  >  > >
 >  >  > >> "As with all other
 >  >  destination options extension headers, the
 PDM
 >  is
 >  >  > >
 >  >  > >>  for
 >  >  destination nodes only. As specified
 above,
 >  intermediate
 >  >  devices
 >  >  > >
 >  >  >
 >  >  >>  MUST neither set nor modify
 this
 >  field."
 >  >  > >
 >  >  > >
 >  >  > > Done
 >  >  > >
 >  >  > >
 >  >  > >> 8)
 >  >  Section 3.6 suggest removing the
 following
 >  5-tuple text as
 >  >  it has already been described earlier in
 Section
 >  2:
 >  >  > >
 >  >  > >>
 >  >  "The 5-tuple is:
 >  >  > >
 >  >  > >>  SADDR : IP address of the
 >  >  sender SPORT : Port for sender DADDR : IP
 >  >  > >
 >  >  > >>
 >  >  address of the destination DPORT : Port
 for
 >  destination
 >  >  PROTC :
 >  >  > >
 >  >  >
 >  >  >>  Protocol for upper layer (ex.
 TCP,
 >  UDP,
 >  >  ICMP)"
 >  >  > >
 >  >  >
 >  >  > Done
 >  >  > >
 >  >  >
 >  >  >
 >  >  > >> 9) Sections 4.2 and 4.3
 >  >  suggest removing them entirely. I see what
 value
 >  these
 >  >  sections add. I acknowledge they are good
 >  >  > >> to know information of
 timer
 >  >  hardware implementation difference but do
 not
 >  really add
 >  >  value on the on-wire encoding of the PDM
 option.
 >  >  > >
 >  >  > >> 10)
 >  >  Section 4.4 suggest removing the entire
 section.
 >  Time Base
 >  >  was already described in detail enough in
 Section
 >  3.2.
 >  >  > >
 >  >  > >> 11)
 >  >  Section 4.5 time base for picoseconds is
 11 not
 >  00.
 >  >  > >
 >  >  > >> 12)
 >  >  Section 4.5 suggest removing the following
 text,
 >  since it
 >  >  does not add any more clarity to what has
 already
 >  been said
 >  >  in my opinion. This is because all the
 examples
 >  follow nice
 >  >  nybble increment in scaling:
 >  >  > >
 >  >  > >> "Sample binary values (high
 >  >  order 16 bits taken)
 >  >  > >
 >  >  > >>  1 psec            1
 >  >
 >  >    0001
 >  >  > >
 >  >  >
 >  >  >>  1 nsec          3E8
 >  >                      0011 1110
 1000
 >  >  > >
 >  >  > >>  1
 >  >  usec        F4240
 >  >  1111 0100 0010 0100 0000
 >  >  > >
 >  >  > >>  1 msec    3B9ACA00
 >  >    0011 1011 1001 1010 1100 1010 0000
 0000
 >  >  > >
 >  >  > >>  1
 >  >  sec    E8D4A51000 1110 1000 1101 0100
 1010 0101
 >  0001 0000
 >  >  0000 0000"
 >  >  > >
 >  >  > >> 12) Section 4.6 I do not
 >  >  understand why this section is here. I
 strongly
 >  suggest
 >  >  removing it. Sections 4.5 and 3.2 already
 >  describe how I
 >  >  would encode the delta time using scaling
 as a
 >  separate
 >  >  fields not embedded (option fields
 ScaleDTLR and
 >  ScaleDTLS).
 >  >  Did I misunderstand something here?
 >  >  >
 >  >  >
 >  >  > >
 >  >  > >
 >  >  Points 9 - 12 refer to the timing
 calculations.
 >  The
 >  >  timebase has been fixed to be
 attoseconds.
 >  >  > > The entire timing section has
 been
 >  >  re-written.  It has also been moved to
 an
 >  appendix.
 >  >  > > Please let us know if it this
 >  >  addresses your concerns.
 >  >  > >
 >  >  > >
 >  >  > >
 >  >  > >> 13) Section 5 suggest
 removing
 >  >  the following text because of it repeating
 what
 >  has already
 >  >  been said earlier:
 >  >  > >
 >  >  > >> "Each packet, in addition
 to
 >  >  the PDM contains information on the
 >  >  >
 >  >  >
 >  >  > >> sender and receiver. As
 >  >  discussed before, a 5-tuple consists of:
 >  >  > >
 >  >  > >>
 >  >  SADDR : IP address of the sender
 >  >  > >
 >  >
 >  >  > >>  SPORT : Port for sender
 >  >  > >
 >  >  > >>
 >  >  DADDR : IP address of the destination
 >  >  >
 >  >  >
 >  >  > >>  DPORT : Port for
 >  >  destination
 >  >  > >
 >  >  >
 >  >  >>  PROTC : Protocol for upper
 layer (ex.
 >  TCP, UDP,
 >  >  ICMP)
 >  >  > >
 >  >  >
 >  >  >> It should be understood that the
 packet
 >  >  identification information is
 >  >  > >
 >  >  > >> in each packet. We will not
 >  >  repeat that in each of the following
 >  >  >
 >  >  >
 >  >  > >> steps."
 >  >  > >
 >  >  > >
 >  >  > > This is now in Appendix B.  It
 has
 >  >  been removed from that section.
 >  >  > >
 >  >
 >  >  > >
 >  >  > >
 >  >  > >> 14) Section 5.3 suggest
 merging
 >  >  the following text into one example and
 do
 >  necessary
 >  >  rewording. There is no need to do the
 same
 >  >  > >>  calculation twice on
 almost
 >  >  adjacent lines:
 >  >  > >
 >  >  > >> "Sending time : packet 2 -
 >  >  receive time : packet 1
 >  >  > >
 >  >  > >> We will call the result of
 this
 >  >  calculation: Delta Time Last Received
 >  >  >
 >  >  >
 >  >  > >> (DELTATLR)
 >  >  > >
 >  >  > >> That
 >  >  is:
 >  >  > >
 >  >  >
 >  >  >> Delta Time Last Received =
 (Sending
 >  time: packet 2
 >  >  - receive time: packet 1)"
 >  >  > >
 >  >
 >  >  > > Done
 >  >  > >
 >  >
 >  >  > >
 >  >  > >>
 >  >  15) Expand RTT and PSN on their first
 use.
 >  >  > >
 >  >  > > Done
 >  >  > >
 >  >  > > Thanks,
 >  >  > >
 >  >  > > Nalini
 >  >  Elkins
 >  >  > > Inside Products, Inc.
 >  >  > > www.insidethestack.com
 >  >  > > (831) 659-8360
 >  >  >
 >  >
 >  >  >
 >  >
 >

---

From: jouni korhonen <[email-masked]>
Date: Fri, 10 Mar 2017 16:24:15 -0800

Hi,

The text with Al’s revisions are looking good. I did some further editing & proposals to it - see below. The text is not exactly to a precision I was hoping for but I guess that when PDM gets used the actual test setup/profile would define & mandate a certain observing location.

3.5.2  PDM Timestamps

The PDM timestamps are intended to isolate wire time from server or host time, but may necessarily attribute some
host processing time to network latency.

RFC2330 [RFC2330] "Framework for IP Performance Metrics” describes two notions of wire time in section 10.2.
These notions are only defined in terms of an Internet host H observing an Internet link L at a particular location:

 +    For a given IP packet P, the 'wire arrival time' of P at H on L is
      the first time T at which any bit of P has appeared at H's
      observational position on L.

 +    For a given IP packet P, the 'wire exit time’ of P at H on L is the
      first time T at which all the bits of P have appeared at H's
      observational position on L.”

This specification does not define the exact H’s observing position on L. That is left for the deployment setups to define. However, the position where PDM timestamps are taken SHOULD be as close to the physical network interface as possible.  Not all implementations will be able to achieve the ideal level of measurement.

- Jouni

> On Mar 10, 2017, at 7:13 AM, [email-masked] wrote:
> 
> Al,
> 
> Love it!!!
> 
> Jouni?   Anyone else?
> 
>>   > Sent: Friday, March 10, 2017 8:55 AM
>>   > Subject: Re: Gen-ART review of
>>   > Jouni,
>>   > Our team has been discussing this.   So,
>>   > think about the wording below:
>>   >
>>   >
>>   > Wording to be added to section 3.5
> Implementation
>>   Considerations (will
>>   > make the current considerations 3.5.1)
>>   >
>> 
>> 
>>   > possible.   This will ensure the most
>>   accurate measurements.
>>   >
>>   > The ideal PDM reference plane or timestamp
> location
>>   is:
>>   >
>>   > - Send direction: when the first bit of the
> first octet
>>   of the IP header
>>   > is received for output by the network
> interface
>>   >
>>   > -  Receive direction when the first bit of
> the
>>   first octet of the IP
>>   > header is received for input by the network
> interface.
>>   >
>>   > measurement.
>>   > Thanks,
>>   > On Mon, 3/6/17, jouni.nospam <[email-masked]>
>>   wrote:
>>   >
>>   >  Subject: Re: Gen-ART review of
>>   >  To: [email-masked]
>>   >  Date: Monday, March 6, 2017, 11:15 AM
>>   >
>>   >  Hi Nalini,
>>   >
>>   >  Thank you. Accurate
>>   >  timestamping is a non-trivial goal to
> achieve.
>>   You should
>>   >  have the “ideal” reference plane
> described
>>   (this usually
>>   >  is located close or within the network
> interface
>>   PHY) and
>>   >  the exact packet location described what
>>   constitutes the
>>   >  point that timestamp refers to (*). While
> most
>>   existing
>>   >  systems plain have no access to required
>>   resources/functions
>>   >  to do the timestamping “properly” you
> try
>>   your best and
>>   >  adjust the timestamp with the time you
> predict it
>>   takes to
>>   >  reach the “ideal” reference plane.
> This of
>>   course adds
>>   >  certain amount of error (just check the
> typical
>>   operating
>>   >  system context switch times) but you can
> get
>>   around it just
>>   >  by acknowledging the fact or the trying
> to
>>   describe your
>>   >  acceptable maximum error tolerance.. like
> +-1ms
>>   from the
>>   >  ideal timestamp if the packet were
> timestamped at
>>   the PDM
>>   >  defined reference plane and at the PDM
> defined
>>   message
>>   >  timestamping point. The former is
> obviously
>>   easier
>>   >  approach.
>>   >
>>   >  - JOuni
>>   >
>>   >  (*) example: when the first
>>   >  bit of the first octet of the IP header
> (i.e.,
>>   the first bit
>>   >  of IP version field) gets output by the
> PHY to
>>   the physical
>>   >  link. And to the receive direction when
> the first
>>   bit of the
>>   >  IP header is received by the network
> interface
>>   PHY.. or
>>   >  something similar. It does not be this
> strict as
>>   long as
>>   >  there is clear understanding what is going
> on.
>>   >
>>   >
>>   >  > On Mar 6, 2017, at
>>   >  6:41 AM, <[email-masked]>
>>   >  <[email-masked]>
>>   >  wrote:
>>   >  >
>>   >  > Jouni,
>>   >  >
>>   >  > OK.   I
>>   >  will look.   We are also working with a
> very
>>   well
>>   >  respected FreeBSD developer to create a
> version
>>   of FreeBSD
>>   >  which has PDM in it.
>>   >  >
>>   >  > We need to know exactly what choices
> one
>>   >  has in the OS stack itself.
>>   >  >
>>   >  > Thanks,
>>   >  >
>>   >  > Nalini Elkins
>>   >  > Inside
>>   >  Products, Inc.
>>   >  >
>>   >  www.insidethestack.com
>>   >  > (831)
>>   >  659-8360
>>   >  >
>>   >  >
>>   >  > From: jouni.nospam <[email-masked]>
>>   >  > To: [email-masked]
>>   >
>>   >  > Cc: General Area Review Team <[email-masked]>;
>>   >  "[email-masked]"
>>   >  <[email-masked]>;
>>   >  Michael Ackermann <[email-masked]>;
>>   >  Robert Hamilton <[email-masked]>
>>   >  > Sent: Sunday, March 5, 2017 4:54 PM
>>   >  > Subject: Re: Gen-ART review of
>>   >  > Hi,
>>   >  > Thank you for the
>>   >  updates. I am fine with them.
>>   >  >
>>   >  > I still have one fundamental
> complaint.
>>   >  There is no discussion or definition of
> the
>>   message
>>   >  timestamp points. All this nanosecond or
> better
>>   accuracy,
>>   >  and the concern of truncation inaccuracy
> do not
>>   really
>>   >  matter if the message timestamp point
> varies node
>>   to node or
>>   >  even within the node. I suggest taking a
> look at
>>   standards
>>   >  like IEEE 802.1AS, IEEE 1588v2 or IEEE
> 1722 for
>>   discussions
>>   >  of this topic. You really need to have a
> good
>>   definition
>>   >  & discussion of the message timestamp
> point,
>>   or justify
>>   >  that in the text why it is not there.
>>   >  >
>>   >
>>   >  > Regards,
>>   >  >
>>   >     Jouni
>>   >  >
>>   >  >
>>   >  >
>>   >  > > On Feb 28, 2017, at 7:04 AM, [email-masked]
>>   >  wrote:
>>   >  > >
>>   >  > >
>>   >
>>   >  > >
>>   >  > >
>>   >  Jouni,
>>   >  > >
>>   >  > >
>>   >  We have posted a new version which
> addresses the
>>   minor and
>>   >  editorial comments. It is below.  I am
> waiting
>>   for your
>>   >  response to the major comments & then
> I will
>>   >  integrate.  As far as I know now, I have
>>   addressed all
>>   >  outstanding issues.  My comments to your
>>   editorial / minor
>>   >  is below.
>>   >  > >
>>   >  >
>>   > 2Doption_&d=DwIFaQ&c=LFYZ-
>>   >
>>  
>>   > =
>>   >  > > Nits/editorial comments:
>>   >  > >> 1)
>>   >  Section 1.4 numbered list: add missing
> full
>>   stops.
>>   >  > >
>>   >  > > Actually,
>>   >  I think it is better to remove the full
> stops
>>   from the two
>>   >  that have it.  These are sentence
>>   >  >
>>   >  > fragments.
>>   >  > >
>>   >  > >> 2) Section 3.2: remove
>>   >  > >
>>   >  > >>
>>   >  "The 5-tuple consists of
>>   >  > >
>>   >  > >>  the source and destination
> IP
>>   >  addresses, the source and destination
>>   >  >
>>   >  >
>>   >  > >>  ports, and the upper
>>   >  layer protocol (ex. TCP, ICMP, etc)."
>>   >  > >
>>   >  > >> since
>>   >  this is unnecessary repetition.
>>   >  > >
>>   >
>>   >  > >
>>   >  > > This
>>   >  is in the section below:
>>   >  > >
>>   >  > > Old
>>   >  > > ----
>>   >
>>   >  > > Packet Sequence Number This
>>   >  Packet (PSNTP)
>>   >  > >
>>   >  > > 16-bit unsigned integer.  This
> field
>>   >  will wrap. It is intended for
>>   >  > > use
>>   >  while analyzing packet traces.
>>   >  > >
>>   >
>>   >  > > Initialized at a random number
>>   >  and incremented monotonically for each
>>   >  >
>>   >  > packet of the session flow of the
> 5-tuple.
>>   The
>>   >  5-tuple consists of
>>   >  > > the source
>>   >  and destination IP addresses, the source
> and
>>   destination
>>   >  > > ports, and the upper layer
> protocol
>>   >  (ex. TCP, ICMP, etc).  The
>>   >  > >
>>   >  random number initialization is intended
> to make
>>   it harder
>>   >  to spoof
>>   >  > > and insert such packets.
>>   >
>>   >  > >
>>   >  > > New
>>   >
>>   >  > > ----
>>   >  > >
>>   >  Packet Sequence Number This Packet
> (PSNTP)
>>   >  > >
>>   >  > > 16-bit
>>   >  unsigned integer.  This field will wrap.
> It is
>>   intended for
>>   >
>>   >  > > use while analyzing packet
>>   >  traces.
>>   >  > >
>>   >  >
>>   >  > Initialized at a random number and
>>   incremented
>>   >  monotonically for each
>>   >  > > packet of
>>   >  the session flow of the 5-tuple.
>>   >  > >
>>   >
>>   >  > >
>>   >  > >> 3)
>>   >  Section 3.2: remove
>>   >  > >
>>   >  > >> "Operating systems MUST NOT
>>   >  implement a single
>>   >  > >
>>   >  > >> counter for all
>>   >  connections."
>>   >  > >
>>   >  > >> Seems again like
> unnecessary
>>   >  repetition to previous sentence.
>>   >  > >
>>   >
>>   >  > >
>>   >  > > This
>>   >  is in the section on "Packet Sequence
> Number
>>   This
>>   >  Packet (PSNTP)"
>>   >  > >
>>   >  > > Old
>>   >  > > ---
>>   >
>>   >  > > Operating systems MUST
> implement
>>   >  a separate packet sequence number
>>   >  > >
>>   >  counter per 5-tuple. Operating systems
> MUST NOT
>>   implement a
>>   >  single
>>   >  > > counter for all
>>   >  connections.
>>   >  > >
>>   >  > > New
>>   >  > > ---
>>   >
>>   >  > > Operating systems MUST
> implement
>>   >  a separate packet sequence number
>>   >  > >
>>   >  counter per 5-tuple.
>>   >  > >
>>   >  > >
>>   >  > >> 4)
>>   >  Section 3.2 again unnecessary repetition
> of IPv6
>>   basics that
>>   >  can be read from RFC2460. Suggest strongly
> to
>>   remove:
>>   >  > >
>>   >  > >>
>>   >  "This indicates the following processing
>>   requirements:
>>   >
>>   >  > >
>>   >  > >>
>>   >  00 - skip over this option and continue
>>   processing the
>>   >  header.
>>   >  > >
>>   >  >
>>   >  >>  RFC2460 [RFC2460] defines other
> values
>>   for the
>>   >  Option Type field.
>>   >  > >
>>   >  > >> These MUST NOT be used in
> the
>>   >  PDM."
>>   >  > >
>>   >  >
>>   >  >> and
>>   >  > >
>>   >  > >> "The possible values are as
>>   >  follows:
>>   >  > >
>>   >  >
>>   >  >> 0 - Option Data does not change
>>   en-route
>>   >  > >
>>   >  > >>  1 -
>>   >  Option Data may change en-route
>>   >  > >
>>   >
>>   >  > >>  The three high-order bits
>>   >  described above are to be treated as part
>>   >  > >
>>   >  > >>  of
>>   >  the Option Type, not independent of the
> Option
>>   Type.  That
>>   >  is, a
>>   >  > >
>>   >  >
>>   >  >> particular option is identified
> by a
>>   full 8-bit
>>   >  Option Type, not just
>>   >  > >
>>   >  > >> the low-order 5 bits of an
> Option
>>   >  Type."
>>   >  > >
>>   >  >
>>   >  >
>>   >  > > Old
>>   >  >
>>   >  > ----
>>   >  > > Option Type
>>   >  > >
>>   >  > > The two
>>   >  highest-order bits of the Option Type
> field are
>>   encoded to
>>   >
>>   >  > > indicate specific processing of
>>   >  the option; for the PDM destination
>>   >  >
>>   >  > option, these two bits MUST be set to
> 00.
>>   This
>>   >  indicates the
>>   >  > > following
>>   >  processing requirements:
>>   >  > >
>>   >  > > 00 - skip over this option and
>>   >  continue processing the header.
>>   >  > >
>>   >
>>   >  > > RFC2460 [RFC2460] defines other
>>   >  values for the Option Type field.
>>   >  > >
>>   >  These MUST NOT be used in the PDM.
>>   >  >
>>   >  >
>>   >  > > In keeping with RFC2460
>>   >  [RFC2460], the third-highest-order bit of
> the
>>   >  > > Option Type specifies whether or
> not
>>   >  the Option Data of that option
>>   >  > >
>>   >  can change en-route to the packet's final
>>   destination.
>>   >
>>   >  > >
>>   >  > > In the
>>   >  PDM, the value of the third-highest-order
> bit
>>   MUST be 0.
>>   >  The
>>   >  > > possible values are as
>>   >  follows:
>>   >  > >
>>   >  >
>>   >  > 0 - Option Data does not change
> en-route
>>   >  > >
>>   >  > > 1 - Option
>>   >  Data may change en-route
>>   >  > >
>>   >  > > The three high-order bits
> described
>>   >  above are to be treated as part
>>   >  > >
>>   >  of the Option Type, not independent of the
> Option
>>   Type.
>>   >  That is, a
>>   >  > > particular option is
>>   >  identified by a full 8-bit Option Type,
> not just
>>   >  > > the low-order 5 bits of an
> Option
>>   >  Type.
>>   >  > >
>>   >  > >
>>   >
>>   >  > >
>>   >  > > New
>>   >
>>   >  > > ----
>>   >  > >
>>   >  Option Type
>>   >  > >
>>   >  >
>>   >  > In keeping with RFC2460[RFC2460], the
> two
>>   high order
>>   >  bits of the Option Type field are encoded
> to
>>   >  > > indicate specific processing of
> the
>>   >  option; for the PDM destination
>>   >  > >
>>   >  option, these two bits MUST be set to 00.
>>   >  > >
>>   >  > > The third
>>   >  high order bit of the Option Type
> specifies
>>   whether or not
>>   >  the Option Data of that option
>>   >  > >
>>   >  can change en-route to the packet's final
>>   destination.
>>   >
>>   >  > >
>>   >  > > In the
>>   >  PDM, the value of the third high order bit
> MUST
>>   be 0.
>>   >  > >
>>   >  > >
>>   >  > >
>>   >  > > 5) Section
>>   >  3.3 same as in comment 4). Suggest
> strongly
>>   removing:
>>   >  > >
>>   >  > >>
>>   >  "This follows the order defined in
> RFC2460
>>   [RFC2460]
>>   >
>>   >  > >
>>   >  > >>
>>   >              IPv6 header
>>   >  > >
>>   >  > >>             
> Hop-by-Hop
>>   >  Options header
>>   >  > >
>>   >  > >>           
> Destination
>>   >  Options header  <--------
>>   >  > >
>>   >  > >>            Routing
> header
>>   >
>>   >  > >
>>   >  > >>
>>   >          Fragment header
>>   >  > >
>>   >  > >>         
> Authentication
>>   >  header
>>   >  > >
>>   >  >
>>   >  >>        Encapsulating
> Security
>>   Payload header
>>   >
>>   >  > >
>>   >  > >>
>>   >        Destination Options header
>>   <------------
>>   >  > >
>>   >  > >>
>>   >    upper-layer header"
>>   >  > >
>>   >  > >
>>   >  > >
>>   >  > >> 6) Suggest removing entire
>>   >  Section 3.4 and moving the following text
> to
>>   Section 3.3:
>>   >
>>   >  > >
>>   >  > >>
>>   >  "PDM MUST be placed before the ESP header
> in
>>   >  > >
>>   >  > >> order
>>   >  to work.  If placed before the ESP
> header, the
>>   PDM header
>>   >  will
>>   >  > >
>>   >  >
>>   >  >> flow in the clear over the
> network thus
>>   allowing
>>   >  gathering of
>>   >  > >
>>   >  > >> performance and diagnostic
> data
>>   >  without sacrificing security."
>>   >  >
>>   >  >
>>   >  > >
>>   >  > >
>>   >  ESP processing with PDM was changed
> because of
>>   comments from
>>   >  security reviewer.
>>   >  > >
>>   >  > >
>>   >  > >
>>   >  > >> 7) Section 3.6 suggest
> removing
>>   >  the following text. I see no value it
> would add
>>   to what has
>>   >  already been said:
>>   >  > >
>>   >  > >> "As with all other
>>   >  destination options extension headers, the
> PDM
>>   is
>>   >  > >
>>   >  > >>  for
>>   >  destination nodes only. As specified
> above,
>>   intermediate
>>   >  devices
>>   >  > >
>>   >  >
>>   >  >>  MUST neither set nor modify
> this
>>   field."
>>   >  > >
>>   >  > >
>>   >  > > Done
>>   >  > >
>>   >  > >
>>   >  > >> 8)
>>   >  Section 3.6 suggest removing the
> following
>>   5-tuple text as
>>   >  it has already been described earlier in
> Section
>>   2:
>>   >  > >
>>   >  > >>
>>   >  "The 5-tuple is:
>>   >  > >
>>   >  > >>  SADDR : IP address of the
>>   >  sender SPORT : Port for sender DADDR : IP
>>   >  > >
>>   >  > >>
>>   >  address of the destination DPORT : Port
> for
>>   destination
>>   >  PROTC :
>>   >  > >
>>   >  >
>>   >  >>  Protocol for upper layer (ex.
> TCP,
>>   UDP,
>>   >  ICMP)"
>>   >  > >
>>   >  >
>>   >  > Done
>>   >  > >
>>   >  >
>>   >  >
>>   >  > >> 9) Sections 4.2 and 4.3
>>   >  suggest removing them entirely. I see what
> value
>>   these
>>   >  sections add. I acknowledge they are good
>>   >  > >> to know information of
> timer
>>   >  hardware implementation difference but do
> not
>>   really add
>>   >  value on the on-wire encoding of the PDM
> option.
>>   >  > >
>>   >  > >> 10)
>>   >  Section 4.4 suggest removing the entire
> section.
>>   Time Base
>>   >  was already described in detail enough in
> Section
>>   3.2.
>>   >  > >
>>   >  > >> 11)
>>   >  Section 4.5 time base for picoseconds is
> 11 not
>>   00.
>>   >  > >
>>   >  > >> 12)
>>   >  Section 4.5 suggest removing the following
> text,
>>   since it
>>   >  does not add any more clarity to what has
> already
>>   been said
>>   >  in my opinion. This is because all the
> examples
>>   follow nice
>>   >  nybble increment in scaling:
>>   >  > >
>>   >  > >> "Sample binary values (high
>>   >  order 16 bits taken)
>>   >  > >
>>   >  > >>  1 psec            1
>>   >
>>   >    0001
>>   >  > >
>>   >  >
>>   >  >>  1 nsec          3E8
>>   >                      0011 1110
> 1000
>>   >  > >
>>   >  > >>  1
>>   >  usec        F4240
>>   >  1111 0100 0010 0100 0000
>>   >  > >
>>   >  > >>  1 msec    3B9ACA00
>>   >    0011 1011 1001 1010 1100 1010 0000
> 0000
>>   >  > >
>>   >  > >>  1
>>   >  sec    E8D4A51000 1110 1000 1101 0100
> 1010 0101
>>   0001 0000
>>   >  0000 0000"
>>   >  > >
>>   >  > >> 12) Section 4.6 I do not
>>   >  understand why this section is here. I
> strongly
>>   suggest
>>   >  removing it. Sections 4.5 and 3.2 already
>>   describe how I
>>   >  would encode the delta time using scaling
> as a
>>   separate
>>   >  fields not embedded (option fields
> ScaleDTLR and
>>   ScaleDTLS).
>>   >  Did I misunderstand something here?
>>   >  >
>>   >  >
>>   >  > >
>>   >  > >
>>   >  Points 9 - 12 refer to the timing
> calculations.
>>   The
>>   >  timebase has been fixed to be
> attoseconds.
>>   >  > > The entire timing section has
> been
>>   >  re-written.  It has also been moved to
> an
>>   appendix.
>>   >  > > Please let us know if it this
>>   >  addresses your concerns.
>>   >  > >
>>   >  > >
>>   >  > >
>>   >  > >> 13) Section 5 suggest
> removing
>>   >  the following text because of it repeating
> what
>>   has already
>>   >  been said earlier:
>>   >  > >
>>   >  > >> "Each packet, in addition
> to
>>   >  the PDM contains information on the
>>   >  >
>>   >  >
>>   >  > >> sender and receiver. As
>>   >  discussed before, a 5-tuple consists of:
>>   >  > >
>>   >  > >>
>>   >  SADDR : IP address of the sender
>>   >  > >
>>   >
>>   >  > >>  SPORT : Port for sender
>>   >  > >
>>   >  > >>
>>   >  DADDR : IP address of the destination
>>   >  >
>>   >  >
>>   >  > >>  DPORT : Port for
>>   >  destination
>>   >  > >
>>   >  >
>>   >  >>  PROTC : Protocol for upper
> layer (ex.
>>   TCP, UDP,
>>   >  ICMP)
>>   >  > >
>>   >  >
>>   >  >> It should be understood that the
> packet
>>   >  identification information is
>>   >  > >
>>   >  > >> in each packet. We will not
>>   >  repeat that in each of the following
>>   >  >
>>   >  >
>>   >  > >> steps."
>>   >  > >
>>   >  > >
>>   >  > > This is now in Appendix B.  It
> has
>>   >  been removed from that section.
>>   >  > >
>>   >
>>   >  > >
>>   >  > >
>>   >  > >> 14) Section 5.3 suggest
> merging
>>   >  the following text into one example and
> do
>>   necessary
>>   >  rewording. There is no need to do the
> same
>>   >  > >>  calculation twice on
> almost
>>   >  adjacent lines:
>>   >  > >
>>   >  > >> "Sending time : packet 2 -
>>   >  receive time : packet 1
>>   >  > >
>>   >  > >> We will call the result of
> this
>>   >  calculation: Delta Time Last Received
>>   >  >
>>   >  >
>>   >  > >> (DELTATLR)
>>   >  > >
>>   >  > >> That
>>   >  is:
>>   >  > >
>>   >  >
>>   >  >> Delta Time Last Received =
> (Sending
>>   time: packet 2
>>   >  - receive time: packet 1)"
>>   >  > >
>>   >
>>   >  > > Done
>>   >  > >
>>   >
>>   >  > >
>>   >  > >>
>>   >  15) Expand RTT and PSN on their first
> use.
>>   >  > >
>>   >  > > Done
>>   >  > >
>>   >  > > Thanks,
>>   >  > >
>>   >  > > Nalini
>>   >  Elkins
>>   >  > > Inside Products, Inc.
>>   >  > > www.insidethestack.com
>>   >  > > (831) 659-8360
>>   >  >
>>   >
>>   >  >
>>   >
>> 
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 11 Mar 2017 00:36:43 +0000

works for me, thanks Jouni!
Al

> From: jouni korhonen [mailto:[email-masked]]
> Sent: Friday, March 10, 2017 7:24 PM
> Cc: MORTON, ALFRED C (AL); General Area Review Team; draft-ietf-ippm-
> [email-masked]; Michael Ackermann; Robert Hamilton
> Subject: Re: Gen-ART review of draft-ietf-ippm-6man-pdm-option: Minor
> and editorial
> 
> Hi,
> 
> The text with Al’s revisions are looking good. I did some further
> editing & proposals to it - see below. The text is not exactly to a
> precision I was hoping for but I guess that when PDM gets used the
> actual test setup/profile would define & mandate a certain observing
> location.
> 
> 3.5.2  PDM Timestamps
> 
> These notions are only defined in terms of an Internet host H observing
> an Internet link L at a particular location:
> 
> This specification does not define the exact H’s observing position on
> L. That is left for the deployment setups to define. However, the
> position where PDM timestamps are taken SHOULD be as close to the
> physical network interface as possible.  Not all implementations will be
> able to achieve the ideal level of measurement.
> 
> - Jouni
> 
> 
> <[email-masked]>, "jouni.nospam"
> <[email-masked]>
> > Cc: "General Area Review Team" <[email-masked]>, "draft-ietf-ippm-
> [email-masked]" <draft-ietf-ippm-6man-pdm-
> [email-masked]>, "Michael Ackermann" <[email-masked]>,