works for me, thanks Jouni! Al > -----Original Message----- > From: jouni korhonen [mailto:[email protected]] > Sent: Friday, March 10, 2017 7:24 PM > To: [email protected] > Cc: MORTON, ALFRED C (AL); General Area Review Team; draft-ietf-ippm- > [email protected]; 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 > > 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 protected] 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 > > (831) 659-8360 > > > > -------------------------------------------- > > On Fri, 3/10/17, MORTON, ALFRED C (AL) <[email protected]> wrote: > > > > Subject: RE: Gen-ART review of draft-ietf-ippm-6man-pdm-option: Minor > and editorial > > To: "[email protected]" > <[email protected]>, "jouni.nospam" > <[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: 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 protected] > >> [mailto:[email protected]] > >> Sent: Friday, March 10, 2017 9:44 AM > >> To: [email protected]; > > jouni.nospam; MORTON, ALFRED C > >> (AL) > >> 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 > >> > >> 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 protected]> > > wrote: > >> > >> Subject: RE: Gen-ART review of > > draft-ietf-ippm-6man-pdm-option: Minor > >> and editorial > >> To: "[email protected]" > >> <[email protected]>, > > "jouni.nospam" > >> <[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: Friday, March 10, 2017, 6:21 AM > >> > >> > -----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://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 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
