Hi Robert, agreed. Thank you for your thorough review and the most helpful comments. I'll upload the update shortly.
Regards, Greg On Wed, Feb 22, 2017 at 1:09 AM, Robert Sparks <rjspa...@nostrum.com> wrote: > I would simply delete "To ensure precise accuracy in time determination" > and start the sentence at "These actions" > > RjS > > On 2/15/17 9:40 PM, Greg Mirsky wrote: > > Hi Robert, > safe travel and here's another version for your consideration. The point > I'm trying to convey is that the jitter is real but must be accounted not > as part of propagation delay but as residence time. Hope I'm getting close. > > Each RTM-capable > node on the explicit path receives an RTM packet and records the time > at which it receives that packet at its ingress interface as well as > the time at which it transmits that packet from its egress interface. > To ensure precise accuracy in time determination these actions should > be done as close to the physical layer as possible at the same point > of packet processing striving to avoid introducing the appearance of > jitter in propogation delay whereas it should be accounted as > residence time. > > Regards, > > Greg > > > On Wed, Feb 15, 2017 at 11:15 AM, Robert Sparks <rjspa...@nostrum.com> > wrote: > >> >> >> On 2/15/17 11:20 AM, Greg Mirsky wrote: >> >> Hi Robert, >> yes, you've absolutely correct in your example. The importance of RTM is >> to exclude and quantify, as much as possible, jitter from propagation >> delay. I've updated the wording to reflect that. Below is new text I >> propose, please let me know if it makes it clearer. >> >> Each RTM-capable >> node on the explicit path receives an RTM packet and records the time >> at which it receives that packet at its ingress interface as well as >> the time at which it transmits that packet from its egress interface. >> These actions should be done as close to the physical layer as >> possible at the same point of packet processing striving to avoid >> introduction of jitter in propogation delay to ensure precise >> accuracy in time determination. >> >> perhaps change "avoid introduction of jitter" to "avoid introducing the >> appearance of jitter that's not really there"? >> >> (I'm about to board a plane, so further responses will be very delayed). >> >> Regards, >> >> Greg >> >> >> On Wed, Feb 15, 2017 at 7:43 AM, Robert Sparks <rjspa...@nostrum.com> >> wrote: >> >>> >>> >>> On 2/14/17 10:06 PM, Greg Mirsky wrote: >>> >>> Hi Robert, >>> Section 5 Data Plane Theory of Operation has the following >>> recommendation on reading time value at ingress and egress: >>> >>> Each RTM-capable >>> node on the explicit path receives an RTM packet and records the time >>> at which it receives that packet at its ingress interface as well as >>> the time at which it transmits that packet from its egress interface; >>> this should be done as close to the physical layer as possible to >>> ensure precise accuracy in time determination. >>> >>> Do you find the text sufficient in providing guidance to an implementer of >>> RTM? >>> >>> Well, no - that was point in the text from my review of -12 that caused >>> me to make comment in the first place. >>> >>> What does "precise accuracy" even _MEAN_? You're waving your hands with >>> words that don't help the reader guess what you mean at the moment. The >>> subsequent email exchange said the important part was that you measure >>> _precisely_ (in that the measurements are always taken the same way), but >>> accuracy isn't that important (you've (and here by "you" I mean the set of >>> people that have responded to the review") told me it's not important >>> whether the reading is taken at the beginning of the bit-stream, the end, >>> or several 1000 nanoseconds after the last bit came off the physical media >>> as long as it's done the same way for each packet). The fact that you're >>> carrying a measurement that can talk about times smaller than the >>> interarrival time for individual bits for some real world line speeds says >>> that different implementations taking the measurement different ways is >>> going to result in different residence time measurements, even if the >>> residence time was really identical. You've told me that's not important to >>> the protocol using the measurement as long as the an individual >>> implementation doesn't introduce something that will look to the using >>> protocol like jitter that's not really there. >>> >>> The text does not say that to an implementer right now. >>> >>> To restate that long paragraph with maybe a longer one, assume a >>> simplified world where everything is perfectly constant. Packets are all >>> flowing at the same size and same rate. For reference, I assert that the >>> time between the first bit of a packet entering the system taking the >>> measurement and the first bit of that packet leaving the system is exactly >>> T (every time). You are telling me that if the system returns cT for some >>> constant T other than 1 (and not necessarily close to 1), everything is >>> fine. You're also telling me that if you replace the system with another >>> that preserves T, but measures differently so that it returns c'T where c' >>> != c, everything is fine. The important part to you is that c and c' don't >>> change for their respective systems. (That surprises me, I can see how the >>> way the clocks are going to use this will do the right thing, but I can't >>> help but think someone later will look at the difference between the two >>> systems and say something is wrong with one of them). What you've told me >>> is not fine is that if you drop i a third system that also preserves T but >>> reports aT where a _varies_ over some range. >>> >>> Have I heard you correctly? >>> >>> Regards, >>> >>> Greg >>> >>> >>> On Mon, Feb 13, 2017 at 1:51 PM, Robert Sparks <rjspa...@nostrum.com> >>> wrote: >>> >>>> Reviewer: Robert Sparks >>>> Review result: Ready >>>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please wait for direction from your >>>> document shepherd or AD before posting a new version of the draft. >>>> >>>> For more information, please see the FAQ at >>>> >>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>>> >>>> Document: draft-ietf-mpls-residence-time-13 >>>> Reviewer: Robert Sparks >>>> Review Date: 2017-02-13 >>>> IETF LC End Date: 2017-01-17 >>>> IESG Telechat date: 2017-03-02 >>>> >>>> Summary: Ready for publication as PS >>>> >>>> Thanks for addressing my comments. >>>> (I still think some discussion about taking arrival and departure time >>>> measurements would be helpful, even if it only said "do it >>>> consistently so you don't indicate jitter that's not really there".) >>>> >>>> >>> >>> >> >> > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
