Rename Slic flow control transport options

[bentoi]

We currently have two properties to control Slic flow control that matches pipe options semantics:

• PauseWriterThreshold: flush on the stream output will start blocking when the number of bytes in the output pipe writer reaches this value
• ResumeWriterTheshold: the number of bytes in the stream output pipe writer when the flush on the stream output will stop blocking

These two properties are confusing in the context of a stream:

• the PauseWriterThreshold value is not used by the local stream output. It's transmitted on connection establishment the connection server-side. It's used by the remote stream output.
• the ResumeWriterTheshold value is used by the local stream input to send the stream consumed frame.

We should probably merge these two properties into a single InitialStreamWindowSize property that matches:

• the .NET HTTP/2 window size property
• msquic StreamRecvWindowDefault (not sure however how it relates to StreamRecvBufferDefault).

Initially, the intent wasn't to make Slic an optimized transport so flow control is quite basic and relies on a fixed window side. To improve throughput, we can investigate implementing a dynamic window size algorithm (#3304). .NET HTTP/2 implementation also used a configurable fixed window size initially and later improved it to be dynamic (dotnet/runtime#54755)

Here are descriptions of HTTP/2 and Quic flow control:

• https://www.rfc-editor.org/rfc/rfc7540.html#section-6.9 and https://medium.com/coderscorner/http-2-flow-control-77e54f7fd518
• https://www.rfc-editor.org/rfc/rfc9000.html#name-flow-control

I think the stream consumed frame matches the HTTP/2 window update frame and I believe it can be used to implement other flow control strategies without changing the Slic protocol.

For 0.1.0, I suggest to only consider renaming the properties. We can investigate stream flow control for the next IceRPC version (unless we really want to make sure we won't need to release a new Slic version in case we need additional settings or frames)

One question is also why HTTP/2 provides connection based flow control given that TCP also provides flow control. Today, Slic only relies on TCP flow control... For sure, adding connection based flow control in Slic will require to support a new Slic frame.

[pepone]

For sure, adding connection based flow control in Slic will require to support a new Slic frame.

Unless I misunderstood it, Http2 doesn't use a different frame, I think it just uses stream ID 0 for connection.

It is not clear to me why there is a connection control flow with HTTP2, you have stream control flow, plus max connection streams.

[pepone]

With HTTP2 you can send a settings frame at any point, these settings allow you to reconfigure the streams, already opened and change the defaults for new streams. With Slic you can only send parameters during connection initialization as part of the initialize frame.

I guess we can add this new frame in 0.2 if required, just something to consider

[bentoi]

Unless I misunderstood it, Http2 doesn't use a different frame, I think it just uses stream ID 0 for connection.

Slic and HTTP/2 are different in this respect. HTTP/2 is kind of a mix of Slic and icerpc. Slic, like Quic, uses a number of connection level frames for control frames not related to streams (Ping, etc) and stream frames for per/stream frames. It doesn't reserve a dedicated stream for exchanging control frames like HTTP/2. icerpc does however, it reserves the first unidirectional stream for icerpc "control" frames.

It is not clear to me why there is a connection control flow with HTTP/2, you have stream control flow, plus max connection streams.

Right and the .NET HTTP/2 implementation default is to not enable it for this exact reason.

See https://github.com/dotnet/runtime/blob/6e34b5d4e9b16321f37c108fea3aa7e4e04b495a/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Connection.cs#L104