Draft: draft-ietf-quic-transport

Commentary: When multiple connections share the same network path or multiple connection IDs are used for the same path , using the spin bit is complicated by the difficulty in correlating forward and reverse flows . There is currently text that uses RFC 6919 language in the draft recommending coordination of the spin to avoid this problem . However , as , this coordination seems difficult and therefore unlikely . It also creates a strong signal that indicates that all the connections on the path are terminated at the same endpoint on both ends . Maybe we do n't want to be generating that signal . Also , because this coordination ca n't be guaranteed , the on - path observer is forced to build code for correlating / segregating measurements by connection ID in the case where there is no coordination . Maybe it 's best just to remove this recommendation entirely . 
 +1 to removing the recommendation , or changing the statement to just a caution ( e.g. , if you are to coalesce connections that spin , then you 'd better be aware of ... ) . FWIW I am not sure if I agree with this observation . IIUC , the connections sharing a 5 - tuple will be terminated by the same endpoint on both ends ; it is impossible for a middlebox to coalesce multiple QUIC connections . It is impossible because CIDs can change mid - connection , and a middlebox can not determine to where the packets containing the new CID must be sent . 
 There definitely needs to be a degree of coordination between the middlebox and the endpoints , but that does n't mean that you ca n't use something like the quic - lb stuff on either end ( or both ends ) . 
 Yes , I think it is better to remove that recommendation , but perhaps replace it with a note to observers . 
  says : How would that work when 1/8th of the connections are not spinning ? Would n't that either be sending a misleading signal , or violate the 1/8th rule ?
Paragraph (version A):
Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection.  Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis.  Even when the spin bit is not disabled by
the administrator, implementations MUST disable the spin bit for a
given connection with a certain likelihood.  The random selection
process SHOULD be designed such that on average the spin bit is
disabled for at least one eighth of connections.  The selection
process performed at the beginning of the connection SHOULD be
applied for all paths used by the connection.
Paragraph (version A):
In case multiple connections share the same five-tuple, that is, have
the same source and destination IP address and UDP ports, endpoints
should try to co-ordinate across all connections to ensure a clear
signal to any on-path measurement points.
Paragraph (version B):
Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection.  Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis.  Even when the spin bit is not disabled by
the administrator, implementations MUST disable the spin bit for a
given connection with a certain likelihood.  The random selection
process SHOULD be designed such that on average the spin bit is
disabled for at least one eighth of network paths.  The selection
process performed at the beginning of the connection SHOULD be
applied for all paths used by the connection.
Paragraph (version B):
In case multiple connections share the same network path, as
determined by having the same source and destination IP address and
UDP ports, endpoints should try to co-ordinate across all connections
to ensure a clear signal to any on-path measurement points.