HTTP-31: Reserved Streams

[gloinul]

Section 6.2.3: https://www.ietf.org/archive/id/draft-ietf-quic-http-31.html#name-reserved-stream-types

These streams have no semantics, and can be sent when application-layer padding is desired.

So although a bit unclear I assume the intention here is that one can grab the next available unidirectional stream, send the stream type with a reserved value. After that that endpoint may send arbitrary data at any time while the connection lasts and close it down. I think that could be slightly more explained.

What is the cause of this issue is the "Application-layer padding". So I assume that an HTTP/3 implementation could have certain API to request this padding and what behavior it has. However, can this be anything other than generally padding out the QUIC connection. I think from this level it might be hard to have any more detailed control over where the padding data goes. The QUIC scheduler will do what it is programmed to do when it has multiple streams to send and split that into different packets in an implementation dependent fashion. So I wonder what impression people get of this padding feature? It appears hard to use for privacy preserving features as that needs to more consistently ensure that an outside observer can't detect patterns. So it will basically be for keep-alive and consuming more bits, possibly to probe if the application can take the step to the next quality level.

So I would think the properties of this should be slightly more explained to not give false hopes.

[LPardue]

HTTP traffic patterns can be quite bursty with a lot of cessation. The possible privacy preserving feature comes from an endpoint that can continue to drive application traffic over some time window. Allowing an application to pump the QUIC connection, and have the transport just deal with it without any special configuration seems attractive. In other words, if the transport is not application-limited then it can always keep the congestion window full. A scheduler can always demote such streams to behind all other streams. However, a receiver that doesn't immediately drain such streams will cause app limitation, which could affect the privacy targets. We might want to document that.

[gloinul]

Ok that is one aspect that would benefit from clarification. I think some words on the properties that application level requested usage of reserved stream has would also be good.

[larseggert]

@gloinul does the PR address your issue?

[LPardue]

This is editorial because we're just explaining a bit more how an endpoint might use what HTTP/3 provides.

[gloinul]

@larseggert Yes, this I think provides sufficient context for the padding and combined with the risks of applying it badly. So resolved.