Code change:
7.1.2. <ins> When sending to a zero-length CID receiver, senders may receive acknowledgements that combine packet numbers received over multiple paths.  However, even if one packet number space is used on multiple path the sender MUST maintain separate congestion control state for each path.  Therefore, senders MUST be able to infer the sending path from the acknowledged packet numbers, for example by remembering which packet was sent on what path.  The senders MUST use that information to perform congestion control on the relevant paths, and to correctly estimate the transmission delays on each path.  (See ack-delay-and-zero-length-cid-considerations for specific considerations about using the ACK Delay field of ACK frames, and ecn-handling for issues on using ECN marks.) Loss detection as specified in QUIC-RECOVERY uses algorithms based on timers and on sequence numbers.  When packets are sent over multiple paths, loss detection must be adapted to allow for different RTTs on different paths.  When sending to zero-length CID receivers, packets sent on different paths may be received out of order.  Therefore senders cannot directly use the packet sequence numbers to compute the Packet Thresholds defined in Section 6.1.1 of QUIC-RECOVERY. Relying only on Time Thresholds produces correct results, but is somewhat suboptimal.  Some implementations have been getting good results by not just remembering the path over which a packet was sent, but also maintaining an order list of packets sent on each path.  That ordered list can then be used to compute acknowledgement gaps per path in Packet Threshold tests. 7.1.3. </ins> The ACK Delay field of the ACK frame is relative to the largest acknowledged packet number (see Section 13.2.5 of QUIC-TRANSPORT). When using paths with different transmission delays, the reported

Related discussion:
text: This derives from the discussions on issue
The commit applies the changes suggested in the previous reviews. With those changes, I think we have a good basis for discussing a unified solution in the working group.
Thanks NAME for the review. I have applied the editorial changes. You are asking for something more regarding the "specific logic" required when supporting zero-length CID. There are in fact two pieces to that: logic at the receiver, i.e., the node that chose to receive packets with zero-length CID; and logic at the sender, i.e., the node that accepts to send data on multiple paths towards a node that uses zero-length CID. This is explained in details in the section "Using Zero-Length connection ID", so I guess what we need is a reference to that section.
Comment by NAME (on PR ): I think we expand this section a bit as we found getting the delay right was non-trivial. QUIC time-stamp would work for sure. But if one decides not to use QUIC timestamp, we probably want to explain what is needed to be done here.
I have submitted PR for this one.
Closing as got merged.
In section 3.1, we wrote When the multipath option is negotiated, clients that want to use an additional path MUST first initiate the Address Validation procedure with PATHCHALLENGE and PATHRESPONSE frames described in of ]. After receiving packets from the client on the new paths, the servers MAY in turn attempt to validate these paths using the same mechanisms. With multipath, we cannot simply write that the server MAY validate the new path. There is a risk of a malicious client that operates as follows: client creates path from its own address, A. Path is validate by server client starts long download from server client creates a second path to server using a spoofed address, B client starts address validation for B but does not care about the response from the server client stops acknowledging packets over the first path to force the server to move packets to the second one and then opportunistically acknowledges packets that should have been sent by the server over that second packet (SPNS would probably make such an attack simpler than MPNS) We probably need to start working on the security considerations section of the draft.
This is already covered in the QUIC threat model. The server is supposed to validate new paths by sending a "path challenge" on that path, then waiting for a challenge response.