Draft: draft-ietf-taps-impl

Commentary: please take a look at the updated text ! 
 Section 4.2.1 on delayed racing : " For example , if the first child represents an IP address with a known route , and the second child represents another IP address , the delay between starting the first and second IP addresses can be based on the expected retransmission cadence for the first child 's connection ( derived from historical round - trip - time ) . Alternatively , if the first child represents a branch on a Wi - Fi interface , and the second child represents a branch on an LTE interface , the delay should be based on the expected time in which the branch for the first interface would be able to establish a connection , based on link quality and historical round - trip - time . " What the reasoning for these two recommendations ? I 'm actually not sure what exactly is meant . Is the first case 3xRTT ( -initial RTO ) and the second 1xRTT ? Why ? Also in the next paragraph : " Generally , branches between paths and protocols should have longer delays than branches between derived endpoints . " What ? Why ? And then " The maximum delay should be considered with regards to how long a user is expected to wait for the connection to complete . " How do I know this ? 
 Also , maybe it 's just me , but I ca n't parse " retransmission cadence " , and the phrase with " historical round - trip time " is 1 ) confusing ( I do n't get what it means , but maybe that 's due to me misunderstanding " cadence " ? ) , and 2 ) seems to be missing an article . 
 I read this as examples of things to consider when implementing a happy - eyeballs style algorithm , rather than explicit recommendations . Maybe this fix is to make this more vague , rather than more explicit ? 
 I think is right and the intention here is that these are just examples of things to consider . We should conclude if anything more is needed beyond making it more clear in the text that these are examples and fixing the other language issues . 
 The issue I agreed with was a desire to find simpler terms to describe these examples . 
 Refer to Happy Eyeballs for exact timing algorithm as the concrete reference ( or ICE , etc ) . 
 It would be helpful to add some of the reasoning behind , e.g. , " Generally , branches between paths and protocols should have longer delays than branches between derived endpoints . " 
 Thanks , looks good . ( Just marked a nit . )
Paragraph (version A):
Staggered racing attempts occur in parallel.  Implementations should
not terminate an earlier child connection attempt upon starting a
secondary child.
Paragraph (version A):
The delay between starting child nodes should be based on the
properties of the previously started child node.  For example, if the
first child represents an IP address with a known route, and the
second child represents another IP address, the delay between
starting the first and second IP addresses can be based on the
expected retransmission cadence for the first child's connection
(derived from historical round-trip-time).  Alternatively, if the
first child represents a branch on a Wi-Fi interface, and the second
child represents a branch on an LTE interface, the delay should be
based on the expected time in which the branch for the first
interface would be able to establish a connection, based on link
quality and historical round-trip-time.
Paragraph (version A):
Any delay should have a defined minimum and maximum value based on
the branch type.  Generally, branches between paths and protocols
should have longer delays than branches between derived endpoints.
The maximum delay should be considered with regards to how long a
user is expected to wait for the connection to complete.
Paragraph (version A):
If a child node fails to connect before the delay timer has fired for
the next child, the next child should be started immediately.
Paragraph (version B):
Staggered racing attempts can proceed in parallel.  Implementations
should not terminate an earlier child connection attempt upon
starting a secondary child.
Paragraph (version B):
If a child node fails to connect before the delay time has expired
for the next child, the next child should be started immediately.
Paragraph (version B):
Staggered racing between IP addresses for a generic Connection should
follow the Happy Eyeballs algorithm described in RFC8305.  RFC8421
provides guidance for racing when performing Interactive Connectivity
Establishment (ICE).
Paragraph (version B):
Generally, the delay before starting a given child node ought to be
based on the length of time the previously started child node is
expected to take before it succeeds or makes progress in connection
establishment.  Algorithms like Happy Eyeballs choose a delay based
on how long the transport connection handshake is expected to take.
When performing staggered races in multiple branch types (such as
racing between network interfaces, and then racing between IP
addresses), a longer delay may be chosen for some branch types.  For
example, when racing between network interfaces, the delay should
also take into account the amount of time it takes to prepare the
network interface (such as radio association) and name resolution
over that interface, in addition to the delay that would be added for
a single transport connection handshake.
Paragraph (version B):
Since the staggered delay can be chosen based on dynamic information,
such as predicted round-trip time, implementations should define
upper and lower bounds for delay times.  These bounds are
implementation-specific, and may differ based on which branch type is
being used.