It would be nice to have timestamps on every packet but, for whatever reason, this is not how most existing 1588 hardware works. Current hardware keys off specific protocol identifier fields in packets and takes a timestamp on match. There's some small amount of hardware buffer dedicated to holding timestamps.
On Wed, Oct 19, 2011 at 9:41 AM, Nico Williams <n...@cryptonector.com>wrote: > On Wed, Oct 19, 2011 at 6:57 AM, Danny Mayer <ma...@ntp.org> wrote: > >> The problem with this is once the packets have been encrypted, it is > >> not possible for the femtocell to timestamp them on reception because it > >> doesn't recognise them until after decryption, which is what this draft > >> tries to address. > > > > You could always timestamp all packets and then worry about whether or > > not you need the timestamp or is this prohibitive in cost? > > That's my take as well. If you can timestamp some packets, you can > timestamp them all. Perhaps the reading of a hi-res timer is a slow > operation, or perhaps it can have deleterious effects. For example, a > hi-res timer might be available only w/o reference to a single clock, > with each hi-res timer being CPU core-/thread-specific, in which case > the system would have to arrange for the packet to continue to be > processed on the same core/thread even if it'd be better not to for > other reasons. Modern CPUs can count CPU cycles though, which can be > used as a good proxy for hi-res timers for relatively short runs of > code, but perhaps tracking CPU cycles used to process a packet might > require extensive changes to an implementation. Or perhaps some > femtocells are implemented almost entirely in HW whose architecture > makes it expensive to timestamp every packet. Details would be nice. > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
