Early Review of draft-ietf-tictoc-multi-path-synchronization-04
review-ietf-tictoc-multi-path-synchronization-04-intdir-early-abley-2016-08-08-00

I am an assigned INT directorate reviewer for this draft. These
comments were written primarily for the benefit of the Internet
Area Directors. Document editors and shepherds should treat these
comments just like they would treat comments from any other IETF
contributors and resolve them along with any other Last Call comments
that have been received. For more details of the INT directorate,
see <

http://www.ietf.org/iesg/directorate.html

>.

Summary

This document is clearly-written and informative. I identified a
couple of areas where some additional discussion might be useful,
but no glaring ommission or other problem that would be a reason
not to publish as-is, if the authors prefer.

Suggestions for Section 5

The document says, reasonably, that "the set of IP addresses for
each clock should be chosen in a way that enables the establishment
of paths that are the most different."

This is sensible advice, and I understand the generality of the
recommendation since it is difficult to provide detailed advice for
the many component networks of the Internet, many of which are
presumably operated differently from each other in this regard.

However, I think it might be worth giving an easy example derived
from global routing operations with BGP.

For example, choosing multiple addresses for a clock that are covered
by the same prefix exported from the local autonomous system (AS)
is likely to yield fewer candidate return paths than choosing
addresses covered by different exported prefixes, since the former
can only provide a single exit for all addresses from a remote AS
while the latter potentially can provide more.

Other examples are no doubt possible. I think it would be useful
to include at least one example, however, since the advice might
otherwise be overlooked.

Suggestions for Section 5.3

1. Header parameters used for flow hashing in traceroute vs. clock
protocol

It was observed earlier in the document that in some networks flow
buckets are associated with a tuple of packet headers that includes
transport protocol identifiers (e.g. UDP) and transport layer
addresses (e.g. UDP port numbers).

A traceroute implementation that wants to identify the path used
by the timing protocol would need to take care to use the same
values in the headers of its probe packets as is used by the network
timing protocol, to the extent that routers in the intermediate
networks between master and slave use those values to identify
individual packets that will be forwarded along congruent paths.

However, some or even most implementations (e.g. the original Van
Jacobsen traceroute that continues to ship with BSD variants) vary
some of these parameters in order to support concurrent operation
by multiple users of the same system, or to allow multiple probe
packets to be in flight simultaneously to speed up the process of
mapping a path. VJ traceroute varies the destination UDP port number,
for example.

I think it is worth noting in this section that if the particular
algorithm employed for traceroute is not identical to the clock
protocol being used, as seen by the network, it is entirely possible
that the paths taken by traceroute probe packets and packets
associated with the clock protocol will be different. The extent
to which traceroute will be useful in the identification of identical
paths for the clock protocol will vary in practice, and in applications
where the possibility of path diversity is more important than the
cost of identical paths is high it might be better to forego identical
path identification and instead acknowledge that some work will
likely be wasted.

2. Temporal stability of paths

Some networks might re-route individual flows over time. The path
(A, B) and the path (C, D) might be different at time T0, but the
same at T1, then different again at T2, as individual routers in
the path experience topology changes (e.g. interfaces come up and
down, or a routing protocol reacts to an LSA received from a
neighbour).  I think it is worth mentioning that if paths are to
be compared to assess whether they are identical, that assessment
needs to be repeated regularly in order to be useful over the
lifetime of an association between a clock master and slave, which
is presumed to be long compared to the expected stability of an
arbitrary path over the Internet.