Subject: [Int-dir] INT dir review of draft-ietf-tictoc-multi-path-synchronization-04

From: Joe Abley <[email-masked]>
Date: Tue, 9 Aug 2016 10:04:12 -0400

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.

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 11 Aug 2016 07:03:13 +0000

Hi Joe,

Many thanks for the thorough review and detailed comments.

Please see my responses below.

Please let us know if you have further comments.
Regards,
Tal Mizrahi.

>-----Original Message-----
>From: Joe Abley [mailto:[email-masked]]
>Sent: Tuesday, August 9, 2016 7:04 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]; Richard Tse; [email-masked]
>Subject: INT dir review of draft-ietf-tictoc-multi-path-synchronization-04
>
>EXTERNAL EMAIL
>
>
>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.
>
>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.
>

[TM] Agreed. We propose to update the existing text to the following paragraph:

If possible, 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. If the load balancing rules in the network are known, it is possible to choose the IP addresses in a way that enforces path diversity. However, even if the load balancing scheme is not known, a careful choice of the IP addresses can increase the probability of path diversity. For example, choosing multiple addresses with different prefixes is likely to produce higher path diversity, as BGP routers are more likely to route these different prefixes through different routes.

>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.
>

[TM] Agreed. We have rephrased the paragraph about Traceroute, and the new proposed text is:

Traceroute-based path discovery can be used for filtering only the IP addresses that obtain diverse paths. 'Paris Traceroute' [PARIS] and 'TraceFlow' [TRACEFLOW] are examples of tools that discover the paths between two points in the network. It should be noted that this filtering approach is effective only if the Traceroute implementation uses the same IP addresses and UDP ports as the synchronization protocol packets. Since some Traceroute implementations vary the UDP ports, they may not be effective in identifying and filtering redundant 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.

[TM] Agreed, we propose to add the following paragraph:

Since network routes change over time, path discovery and redundant path filtering should be performed periodically. Two {master,slave} pairs that produce two diverse paths may be rerouted to use the same paths. Thus, the set of addresses that are used by each clock should be reassessed regularly.

---

From: Joe Abley <[email-masked]>
Date: Thu, 11 Aug 2016 09:20:36 -0400

Hi Tal!

Sounds great, glad I could be of use.

Nice document.

Joe

> On 11 Aug 2016, at 03:03, Tal Mizrahi <[email-masked]> wrote:
> 
> Hi Joe,
>