qdeconinck / draft-deconinck-multipath-quic Goto Github PK

It seems logical that a MP_ACK frame should not retransmitted, but what about the UNIFLOWS frame ? It might also be good to recap which frames are ack-eliciting. Maybe all together in a table ?

In the draft you explain the format of the ADD_ADDRESS-frame, specifically the IPVersion field: "The remaining four bits in the first byte of this frame represent the version of the IP address contained in a later field." Is there a specific reason as to why four bits are used? And how are the different versions represented?

The ASCII 32-bit packet-like style has been deprecated in favor of the C struct one.

I understand that the "Sending Uniflow Info"-Section is present in the uniflows frame, because it allows an endpoint to link a private IP-address to its public counterpart.

For example:

1. A laptop could inform its peer about an additional IP-address A (addr. ID: 2), where A is a private IP address behind a NAT.
2. The laptop could later on use a sending uniflow (uni. ID: 1) where its source IP-address is A, but where the peer sees A as its public counterpart: IP-address B.
3. If the laptop then sends a UNIFLOWS-frame, the peer will identify that the laptop has sending uniflow 1 active, and is sending from an IP-address with addr. ID 2, thus the peer can make the link that the value of IP-address A, identified by addr. ID 1, should be replaced by B.

However, I do not see the use of the "Receiving Uniflow Info"-Section? Is there something that I'm missing?

Zero-length connection ID should not be enabled if a host want to advertise multipath-support. The same requirement was stated in QUIC transport draft to support connection migration, NAT rebinding, or client port reuse.

Each Address ID must have a specific sequence number to order the frames. Otherwise, we could have a case where a ADD ADDRESS is first scheduled and then the REMOVE ADDRESS one, while the receiver gets first the REMOVE ADDRESS and then the ADD ADDRESS.