Updating transport parameters

[quicwg]

Updating transport parameters

[ianswett]

For flow control, it makes sense to have an initial value in the handshake and then use the flow control frames to manage the window.

For max number of streams and similar things, I expected we'd support the SETTINGS frame, but that would be specified in the HTTP doc.

[MikeBishop]

We currently do have SETTINGS, but max number of streams is a QUIC concept, and therefore doesn't currently support changes. Do we need to?

[martinthomson]

Yes, if we are to keep modularity (application protocol can't set transport parameters), then SETTINGS won't cut it. If we're OK with the application protocol saying things not just about the local side, but the remote site, we can have SETTINGS do anything within reason. It seems like it might need an abstraction though.

[martinthomson]

See also #181.

[vasilvv]

We should not allow changing arbitrary parameter changes mid-connection, since the semantics of such change needs to be carefully thought through.

For parameters that we do want to allow changing, we can define special frame types, but we have to think through how this interacts with the fact that
(1) the new value will arrive asynchronously of the current outgoing streams, meaning that
(2) the sender cannot assume the new value is in effect until it's acknowledged.

[MikeBishop]

Yes -- at the app layer, we've had to add per-stream acknowledgement of when setting changes take effect. In h2, we also discussed (though ultimately didn't) having some settings that can only increase, never decrease. You can always choose to be more permissive, and you don't need a sync point for that.

[mnot]

Discussed in Tokyo; consensus in the room that we're comfortable with these things not being changeable after handshake.