Re: [Last-Call] [dtn] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



One of the more enjoyable aspects of the Bundle Protocol is how you can't reliably correct a misset clock on a bundle node by using the bundle protocol itself - because the bundles containing payloads commanding the time change could well be expired and discarded before being carried out, once their timestamps are compared to the errant clock. It's a rather neat self-denial-of-service - section 5.5, and how do you know the local clock is accurate?

So, an ancillary support apparatus for communications not using the bundle protocol would be needed to update the clock behind the bundle agent's back, and that's likely an IP stack (as it happily is in most bundle implementations, where time comes from NTP. There's not that much bundling standing alone, and TCP is the convergence layer of choice, so there may not be much standalone experience with bundle node clocks).

while there is some text in the draft concerning bundles originating from a node with misset clocks, I can't see much concerning sending -to- a node with a misset clock (yes, it's relative, with just two nodes you never know the right time), what is expected to happen, and how that gets handled. More of a network administration problem...


Lloyd Wood
http://lloydwood.users.sourceforge.net/Personal/L..Wood/dtn/ 

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux