Early Review of draft-ietf-tictoc-multi-path-synchronization-04

Request Review of draft-ietf-tictoc-multi-path-synchronization
Requested rev. no specific revision (document currently at 07)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-09-27
Requested 2016-08-03
Authors Alex Shpiner, Richard Tse, Craig Schelp, Tal Mizrahi
Draft last updated 2016-08-12
Completed reviews Genart Last Call review of -05 by Joel Halpern (diff)
Secdir Last Call review of -05 by Watson Ladd (diff)
Intdir Early review of -04 by Joe Abley (diff)
Intdir Early review of -04 by Zhen Cao (diff)
Assignment Reviewer Zhen Cao
State Completed
Review review-ietf-tictoc-multi-path-synchronization-04-intdir-early-cao-2016-08-12
Reviewed rev. 04 (document currently at 07)
Review result Ready
Review completed: 2016-08-12


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 <





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. 


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