When can the connection ID be omitted?

[larseggert]

The current draft doesn't really talk much about when the connection ID can be omitted. Is this a unilateral unidirectional decision by a sender? Is it negotiated somehow? How are connections being identified in the absence of a connection ID? Are there cases when connection IDs need to be sent again after having been omitted? Etc., etc.

[mikkelfj]

See Transport parameters

An endpoint MAY use the following transport parameters:
truncate_connection_id (0x0004):

The truncated connection identifier parameter indicates that packets sent to the peer can omit the connection ID. This can be used by an endpoint where the 5-tuple is sufficient to identify a connection. This parameter is zero length. Omitting the parameter indicates that the endpoint relies on the connection ID being present in every packet.

See also #645

Note that as long as the SCID cannot be mapped to CCID, then 5-tuple uniqueness is necessary, and addding the connection ID is of limited value to end-points, but may help middle boxes. If SCID were mapped to CCID, the connection ID could be used to associate connection state on any transport, but this not currently possible:
https://tools.ietf.org/html/rfc2549

[larseggert]

So how does an endpoint know that its five tuple is sufficient to identify the connection at the peer? When a bunch of clients behind a CGN get mapped to the same source IP and port, and they decide to omit the CID, the server can't tell them apart.

[ianswett]

Every NAT I'm aware of gives each flow a different port, otherwise there's no way to know what IP/port to send the packet to inside the NAT. Given that, omitting the connection ID in the server to client direction seems quite safe.

It's when an IP/port is not sufficiently identifying(usually clusters of servers) when connection id becomes critical.

[larseggert]

Sure, so the assumption is that client <IP, port> pairs are unique. So what guidance do we give server implementations about omitting CIDs? Should they be aggressive about it? Should they only do it in some case; and which? Separately, what about clients? Are there cases when then MUST/SHOULD/MAY omit CIDs?

I'm missing guidance text in the document. At the moment, the draft specifies the possibility to omit and a bit, but not much more.

[chocis]

i imagine that one type of communication is that client always sends CID, so that packet can be forwarded to correct backend server instance, but the response in server's response CID can be omitted.

[larseggert]

That's a reasonable assumption, but the text in the draft at the moment permits either side to omit or not omit CIDs on most packets without any guidance.

[mirjak]

I guess we could add more guidance in the applicability statement because this is rather a configuration question when you deploy quic on your servers than an implementation questions. And I guess we need a configuration knob for this.