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

From: Zhen Cao <[email-masked]>
Date: Thu, 11 Aug 2016 17:24:55 +0800

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

I do not see any strong reason to delay the publication of this document as
it is.  I do have some questions/comments below for discussion.

Comments:
(I am not experts of NTP/PTP exchanges, but I worked on some MIF (multiple
interface, a concluding wg) technology for a while. So the
comments./questions stem there)

1. What's the impact of NAT on the MP-NTP/PTP exchanges.  The packet from
the client will bear with an IP address that collude with some one else,
how does the server handle this solution?  If this is relevant, I would
like to see some discussion in the document.

2. What's the impact of the delay variance of multiple paths on the
combining algorithm?  Should the server wait for a while before abandoning
the message from a certain path?   Generally speaking, UDP traffic from
multiple paths have big variance.

3. The default route on the host may block the transmission of traffic
along a certain IP address that is not within the default interface.  This
is identified by RFC 6418.  A well-known problem is that a
multiple-interface host can only send packets through the one with a better
route metric.  This may have some impact to the operation of MP-NTP/PTP.
Some discussion or pointer to the this problem would help implementer to
save their digging time.

Thanks,
Zhen

---

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

Dear Zhen,

Thanks for the detailed review.

Please see my responses inline, and please let us know if there are any further comments.

Thanks,
Tal.

>From: Zhen Cao [mailto:[email-masked]]
>Sent: Thursday, August 11, 2016 12:25 PM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: INT dir review of draft-ietf-tictoc-multi-path-synchronization-04
>
>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
>
>I do not see any strong reason to delay the publication of this document as it
>is.  I do have some questions/comments below for discussion.
>
>
>Comments:
>the client will bear with an IP address that collude with some one else, how
>does the server handle this solution?  If this is relevant, I would like to see
>some discussion in the document.

[TM] Point well-taken.
We propose to add the following paragraph to Section 5:

The use of Network Address Translation (NAT) may significantly reduce the effectiveness of multi-path synchronization in some cases. For example, if a master uses multiple IP addresses that are translated to a single IP address, the path diversity is likely to be lower than in a network that does not use NAT. Thus, path discovery should be used to identify the possible paths between the master and slave. Path discovery is further discussed in Section ‎5.3.

>
>2. What's the impact of the delay variance of multiple paths on the combining
>algorithm?  Should the server wait for a while before abandoning the message
>from a certain path?   Generally speaking, UDP traffic from multiple paths
>have big variance.

[TM] Yes, indeed the delay variation is a major factor in the combining algorithm. 
The current document briefly mentions the need for a combining algorithm in Section 6, with a reference to other documents that discuss possible combining algorithms. Indeed, these other documents make use of the delay variation as one of the most important factors in the algorithm.
We believe the current text in Section 6 is sufficient, given that combining algorithms are not within the scope of this document.
Please let us know if you believe otherwise.

>
>3. The default route on the host may block the transmission of traffic along a
>certain IP address that is not within the default interface.  This is identified by
>RFC 6418.  A well-known problem is that a multiple-interface host can only
>send packets through the one with a better route metric.  This may have some
>impact to the operation of MP-NTP/PTP.  Some discussion or pointer to the
>this problem would help implementer to save their digging time.

[TM] Right. Thanks for pointing that out. We propose the following paragraph:

The concept of using multiple IP addresses or multiple interfaces is a well-established concept that is being used today by various applications and protocols, e.g., [MPTCP]. It should be noted that using multiple interfaces introduces some challenges and issues, which were presented and discussed in [RFC6418].

---

From: Zhen Cao <[email-masked]>
Date: Fri, 19 Aug 2016 08:13:14 +0800

Hello Tal,

They look good to me.

Many thanks,
zhen

On Thu, Aug 11, 2016 at 9:31 PM, Tal Mizrahi <[email-masked]> wrote:

> how
> The use of Network Address Translation (NAT) may significantly reduce the
> effectiveness of multi-path synchronization in some cases. For example, if
> a master uses multiple IP addresses that are translated to a single IP
> address, the path diversity is likely to be lower than in a network that
> does not use NAT. Thus, path discovery should be used to identify the
> possible paths between the master and slave. Path discovery is further
> discussed in Section ‎5.3.
>
>
>
> >
> combining
> The current document briefly mentions the need for a combining algorithm
> in Section 6, with a reference to other documents that discuss possible
> combining algorithms. Indeed, these other documents make use of the delay
> variation as one of the most important factors in the algorithm.
> We believe the current text in Section 6 is sufficient, given that
> combining algorithms are not within the scope of this document.
> along a
> The concept of using multiple IP addresses or multiple interfaces is a
> well-established concept that is being used today by various applications
> and protocols, e.g., [MPTCP]. It should be noted that using multiple
> interfaces introduces some challenges and issues, which were presented and
> discussed in [RFC6418].
>
>
> >
> >Thanks,
> >Zhen
>