> -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Friday, March 10, 2017 8:55 AM > To: [email protected]; jouni.nospam > Cc: General Area Review Team; draft-ietf-ippm-6man-pdm- > [email protected]; 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://tools.ietf.org/html/rfc2330#section-10.2 IOW, we've been down this road before, Al > > Thanks, > > Nalini Elkins > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > On Mon, 3/6/17, jouni.nospam <[email protected]> wrote: > > Subject: Re: Gen-ART review of draft-ietf-ippm-6man-pdm-option: Minor > and editorial > To: [email protected] > Cc: "General Area Review Team" <[email protected]>, "draft-ietf-ippm- > [email protected]" <draft-ietf-ippm-6man-pdm- > [email protected]>, "Michael Ackermann" <[email protected]>, > "Robert Hamilton" <[email protected]> > 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 protected]> > <[email protected]> > 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 protected]> > > To: [email protected] > > > Cc: General Area Review Team <[email protected]>; > "[email protected]" > <[email protected]>; > Michael Ackermann <[email protected]>; > Robert Hamilton <[email protected]> > > 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 protected] > 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 > > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
