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

[jouni korhonen <[e-mail]>]

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, [e-mail] wrote:
> 
> Al,
> 
> Love it!!!
> 
> Jouni?   Anyone else?
> 
> Thanks so much, Al.   What would I do without you?
> 
> Nalini Elkins
> Inside Products, Inc.
> www.insidethestack.com
> [phone]
> 
> --------------------------------------------
> On Fri, 3/10/17, MORTON, ALFRED C (AL) <[e-mail]> wrote:
> 
> Subject: RE: Gen-ART review of draft-ietf-ippm-6man-pdm-option:  Minor and editorial
> To: "[e-mail]" <[e-mail]>, "jouni.nospam" <[e-mail]>
> Cc: "General Area Review Team" <[e-mail]>, "[e-mail]" <[e-mail]>, "Michael Ackermann" <[e-mail]>, "Robert Hamilton" <[e-mail]>
> 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: [e-mail]
>> [mailto:[e-mail]]
>> Sent: Friday, March 10, 2017 9:44 AM
>> To: [e-mail];
> jouni.nospam; MORTON, ALFRED C
>> (AL)
>> Cc: General Area Review Team;
> draft-ietf-ippm-6man-pdm-
>> [e-mail];
> 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) <[e-mail]>
> wrote:
>> 
>>   Subject: RE: Gen-ART review of
> draft-ietf-ippm-6man-pdm-option:  Minor
>> and editorial
>>   To: "[e-mail]"
>> <[e-mail]>,
> "jouni.nospam"
>> <[e-mail]>
>>   Cc: "General Area Review Team" <[e-mail]>,
> "draft-ietf-ippm-
>> [e-mail]"
> <draft-ietf-ippm-6man-pdm-
>> [e-mail]>,
> "Michael Ackermann" <[e-mail]>,
>> "Robert Hamilton" <[e-mail]>
>>   Date: Friday, March 10, 2017, 6:21 AM
>> 
>>   > -----Original Message-----
>>   > From: [e-mail]
>>   > [mailto:[e-mail]]
>>   > Sent: Friday, March 10, 2017 8:55 AM
>>   > To: [e-mail];
>>   jouni.nospam
>>   > Cc: General Area Review Team;
>>   draft-ietf-ippm-6man-pdm-
>>   > [e-mail];
>>   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
>>   > [phone]
>>   >
>>   >
> --------------------------------------------
>>   > On Mon, 3/6/17, jouni.nospam <[e-mail]>
>>   wrote:
>>   >
>>   >  Subject: Re: Gen-ART review of
>>   draft-ietf-ippm-6man-pdm-option:  Minor
>>   > and editorial
>>   >  To: [e-mail]
>>   >  Cc: "General Area Review Team" <[e-mail]>,
>>   "draft-ietf-ippm-
>>   > [e-mail]"
>>   <draft-ietf-ippm-6man-pdm-
>>   > [e-mail]>,
>>   "Michael Ackermann" <[e-mail]>,
>>   > "Robert Hamilton" <[e-mail]>
>>   >  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, <[e-mail]>
>>   >  <[e-mail]>
>>   >  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 <[e-mail]>
>>   >  > To: [e-mail]
>>   >
>>   >  > Cc: General Area Review Team <[e-mail]>;
>>   >  "[e-mail]"
>>   >  <[e-mail]>;
>>   >  Michael Ackermann <[e-mail]>;
>>   >  Robert Hamilton <[e-mail]>
>>   >  > 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, [e-mail]
>>   >  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
>>   >  > > [phone]
>>   >  >
>>   >
>>   >  >
>>   >
>> 
>