Draft: draft-lmbdhk-quic-multipath

Commentary: This would resolve issue 
 The text about computation of RTT was copied from the " simple option " draft to section 6.2.2 .   RTT , but the issues around RTT computation are common to both single number space and multiple number spaces . Maybe move that text to a new section 6.5 ? 
 I agree . The text applies to both situations . 
 I guess could have move this in the implementation guidance section but this is fine as well .
If the peer does not carry the enable_multipath transport parameter,
which means the peer does not support multipath, endpoint MUST
fallback to QUIC-TRANSPORT with single path and MUST NOT use any
frame or mechanism defined in this document.  If endpoint receives
unexpected value for the transport parameter "enable_multipath", it
MUST treat this as a connection error of type MP_CONNECTION_ERROR and
close the connection.
If the peer does not carry the enable_multipath transport parameter,
which means the peer does not support multipath, endpoint MUST
fallback to QUIC-TRANSPORT fwith single path and MUST NOT use any
frame or mechanism defined in this document.  If endpoint receives
unexpected value for the transport parameter "enable_multipath", it
MUST treat this as a connection error of type MP_CONNECTION_ERROR and
close the connection.
Acknowledgement delays are the sum of two one-way delays, the delay
on the packet sending path and the delay on the return path chosen
for the acknowledgements.  When different paths have different
characteristics, this can cause acknowledgement delays to vary
widely.  Consider for example multipath transmission using both a
terrestrial path, with a latency of 50ms in each direction, and a
geostationary satellite path, with a latency of 300ms in both
directions.  The acknowledgement delay will depend on the combination
of paths used for the packet transmission and the ACK transmission,
as shown in fig-example-ack-delay.
Using the default algorithm specified in QUIC-RECOVERY would result
in suboptimal performance, computing average RTT and standard
deviation from series of different delay measurements of different
combined paths.  At the same time, early tests showed that it is
desirable to send ACKs through the shortest path, because a shorter
ACK delay results in a tighter control loop and better performances.
The tests also showed that it is desirable to send copies of the ACKs
on multiple paths, for robustness if a path experiences sudden
losses.
When a packet is acknowledged, the state of the congestion control
MUST be updated for the path where the acknowledged packet was
originally sent.  The RTT is calculated based on the delay between
the transmission of that packet and its first acknowledgement (see
Section compute-rtt) and is used to update the RTT statistics for the
sending path.
When a packet is acknowledged, the state of the congestion control
MUST be updated for the path where the acknowledged packet was
originally sent.  The RTT is calculated based on the delay between
the transmission of that packet and its first acknowledgement (see
compute-rtt) and is used to update the RTT statistics for the sending
path.
Acknowledgement delays are the sum of two one-way delays, the delay
on the packet sending path and the delay on the return path chosen
for the acknowledgements.  When different paths have different
characteristics, this can cause acknowledgement delays to vary
widely.  Consider for example multipath transmission using both a
terrestrial path, with a latency of 50ms in each direction, and a
geostationary satellite path, with a latency of 300ms in both
directions.  The acknowledgement delay will depend on the combination
of paths used for the packet transmission and the ACK transmission,
as shown in Table fig-example-ack-delay.
Using the default algorithm specified in QUIC-RECOVERY would result
in suboptimal performance, computing average RTT and standard
deviation from a series of different delay measurements of different
combined paths.  At the same time, early tests show that it is
desirable to send ACKs through the shortest path, because a shorter
ACK delay results in a tighter control loop and better performances.
The tests also showed that it is desirable to send copies of the ACKs
on multiple paths, for robustness if a path experiences sudden
losses.