Clarify normative language for Transport Parameter omit_connection_id

[igorlord]

Presently, there is no normative language for Transport Parameter omit_connection_id.

I would like to propose replacing "can" with a normative "MAY". It is important that this MAY is specified, so the endpoints do not consider it an error (or even a warning), when their omit_connection_id is ignored.

Servers that identify connections using Connection ID (and not a 4-tuple) need to send that Connection ID, so they can attribute an ICMP Error with the correct connection. (While IPv4 ICMP Error definition makes including UDP packet data optional, many routers still include it, and it is mandatory in IPv6 ICMPv6.)

[martinthomson]

I think that we're headed for a different design. One that needs a write-up and a bunch of discussion. So hold that thought.

In short, the idea would be to define a new transport parameter for connection ID that determines what connection ID (if any) is used for packets with the short header. Long header packets would use the client-chosen value.

[igorlord]

That's fine. In this case, please, take this as an input for the updated write-up. Any endpoint that identifies connections using a Connection ID requires that Connection ID in packets, including ICMP Error packets. Hence, that endpoint will not only request the peer to send Connection IDs but will also include Connection IDs on outgoing packets (in case they result in an ICMP Error packet). Such ICMP Error packets are required for PMTU discovery, among other things,.

[martinthomson]

The ICMP thing is new. Can you raise that as an issue? The thinking thus far has been that servers could send packets without a connection ID. But if it is important for the server to receive (and match) ICMP, then it will want to send with a connection ID (it's still something that a server could unilaterally decide to do, even if the client allowed the server to omit a connection ID).

[igorlord]

Hm. That was the point of this Issue -- to declare that sending a Connection ID despite of a permission not to do so is something that a server MAY do via normative language. The goal is to make sure that clients are not surprised at all by this behavior (i.e. do not log warnings, etc).

An issue about this is more of an issue for the applicability draft. I'll raise it there.

[ianswett]

My experience is that ICMP is typically implemented by 5-tuple and given 5-tuples are usually stable over a short period of time, so nothing special needs to be done there.

For example, in GQUIC, we do see write errors on the server side when we write a packet that's too large, and those appear to be caused by the Linux kernel converting the ICMP message into a constraint on the max packet size.

[igorlord]

If you are routing by ConnectionID, you need to deliver that ICMP to the server that sent the QUIC packet that caused the ICMP error packet. The 5-tuple will not help w/o a ConnectionID in the message.

[ianswett]

Can you not fall back to 5-tuple routing when connection ID is not present?

[janaiyengar]

I don't see a problem with saying that a server MAY include connection ID even if the client says omit_connection_id, so this is reasonable to do. However, I don't understand the motivating use case. ICMP includes only 8 bytes of the IP datagram, which is basically the UDP header. The connection ID will not be echoed even if it is present in the offending packet. How do you get the connection ID in the ICMP message?

[martinthomson]

There is an extended ICMP unreachable that includes more, but I doubt that's deployed widely enough to rely on. @igorlord, how do you believe that this would be helpful?

[igorlord]

@janaiyengar and @martinthomson, ICMPv6 includes a lot more bytes, so it can be used; some routers include more bytes for ipv4, so that can be used as well. It is true that most often you will not see the connection ID in ICMP (ipv4), but I want to make use of that connection ID in cases when it is useful. Hence, I want to be absolutely sure that clients are ready for the server ignoring omit_connection_id.

[martinthomson]

@igorlord, would you mind creating a PR that clarifies this point?

[igorlord]

Sure, @martinthomson. Would you expect the PR to include just the normative language, or the justification for it as well?

[martinthomson]

The text should say that if the parameter is present, the recipient MAY omit the connection ID from packets it sends with the short header. I don't think we need anything else.

[janaiyengar]

Yup, agree with @martinthomson

[martinthomson]

Closed by #980.