Subject: [quicwg/base-drafts] HTTP-31: Reserved Streams (#4221)

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 09:31:23 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4221

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 15 Oct 2020 10:14:22 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4221#issuecomment-709468630

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2020 00:55:37 -0700

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. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4221#issuecomment-709889175

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Oct 2020 04:13:47 -0700

@gloinul does the PR address your issue?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4221#issuecomment-712074440

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 19 Oct 2020 11:58:01 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4221#issuecomment-712376881

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Oct 2020 23:29:15 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4221#issuecomment-712625358

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Oct 2020 07:25:33 -0700

Closed #4221 via #4233.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4221#event-3899041844