Make Client TP Optional

[nibanks]

With Draft 15 all client transport parameters are now optional. I assume we will try to continue with that design as we add new ones (perhaps none in V1). Does it make sense to make inclusion of the QUIC TP extension as a whole optional, for the client?

[kazuho]

While that could be possible, I wonder what the benefit of making it optional is. I would assume that every implementation will be sending some non-default settings value (e.g., initial_max_data), which means that making TP optional is essentially adding a conditional branch that will always turn on one side.

Additionally, we would be required to revisit the following requirement in QUIC-TLS section 8.2: Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A fatal unsupported_extension alert MUST be sent if this extension is received when the transport is not QUIC.

Considering these two aspects, I prefer mandating the use of TP as we do now.

[ianswett]

Agreed, always sending it is a lot easier than sometimes sending it. Additionally, I believe it'll always end up being necessary in real applications(ie: HTTP), so there's no real-world savings in omitting it.

[martinthomson]

No mention of version negotiation depending on them. I'm a little disappointed. Of course, I agree with the other comments recommending the current mandate be retained.