search

martinthomson / train-protocol

Choo Choo!
Other
0 stars 1 forks source link

Source Connection ID value #13

Closed martinthomson closed 3 months ago

martinthomson commented 3 months ago

What do we set this to? I've suggested that this be empty, but that might be inconsistent with other packets in the same datagram.

kazuho commented 3 months ago

We have two contracts that have different properties.

One is the three-party contract between the endpoints and the network device. I think we are in agreement that network devices must take the version number field (which will be vTRAIN) and the first byte into consideration, and may also take DCID into consideration. IMO, the flip side is that there is no necessity to be specific about how the SCID field is used between the endpoints.

The second contract is the two-party contract between the endpoints. As the RFCs state, QUIC connections are identified using CIDs.

The two contracts are going to be inherently different in the details. The three-party contract will allow CIDs as large as 2040 bits, because that's the Invariant. The two-party contract of QUIC v1 forbids use of CIDs longer than 160 bits.

I think this is a precedence that we have set. Nodes that work in a way that is neutral to QUIC versions have to work within the room defined by RFC 8999. Actual encoding of CID fields are governed by each QUIC version, which is a two-party contract.

martinthomson commented 3 months ago

One alternative we have here is to let SCID be set to match the value from other long header packets in the datagram, if there are other long header packets present, but to require it to be empty otherwise.

kazuho commented 3 months ago

@martinthomson

One alternative we have here is to let SCID be set to match the value from other long header packets in the datagram, if there are other long header packets present, but to require it to be empty otherwise.

I think this works.

In the case of coalescing with long header packets, this approach has the least impact to existing implementations and to future versions of QUIC. In the case of coalescing with short header packets, any QUIC version only needs DCID to route the packet; that is a property of Invariants.

huitema commented 3 months ago

+1 on matching other long headers in the packet, empty if only short headers.

It is the right compromise between compatibility and privacy. If there are only short header packets in the datagram, adding a source CID leaks information, enables correlation of flows, etc. But if there are long headers, there is no info leaks, and compatibility requires adding a matching source ID.