RE: Unidirectional streams PR

["Lubashev, Igor" <[e-mail]>]

  *   I guess one question is if passing STREAM frames whole (at most changing the stream ID) is stateless for the middlebox.

Just passing frames may be mostly stateless (in far as streams are concerned) – it is just transient RAM to buffer and account for the streams before the frames are delivered.  In fact, the proxy may not need to strictly pass the STREAM frames but can re-frame the data it has buffered.  One thing the proxy would not be able to do is stream state validation and would pass on invalid frames to endpoints.


A related question is how would a proxy (or a middlebox) identify QUIC traffic as QUIC and not some random UDP traffic?  We’ve had a magic byte in the header but lost it in the header update.  We still have a port number, but that is likely application-specific, unless we add something to ClientInitial to identify an application.


From: Martin Duke [mailto:[e-mail]]
Sent: Friday, July 07, 2017 4:45 PM
To: Jana Iyengar <[e-mail]>
Cc: Subodh Iyengar <[e-mail]>; Mike Bishop <[e-mail]>; Dmitri Tikhonov <[e-mail]>; Ian Swett <[e-mail]>; Lubashev, Igor <[e-mail]>; Jo Kulik <[e-mail]>; Mikkel Fahnøe Jørgensen <[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>; Swindells, Thomas (Nokia - GB/Cambridge, UK) <[e-mail]>; Kazuho Oku <[e-mail]>
Subject: Re: Unidirectional streams PR

As I understand it, QUIC's contract with the upper layer includes streams, so any such middlebox would maintain state for each stream. In general, these middleboxes will support awareness of most L7s, and users will turn it on.

The exceptions are probably kind of corner-case-ish. Perhaps there's a new application directly on top of QUIC that the middlebox doesn't understand natively. In that case, with no FIN the middlebox would be forced to hold stream state until the end of the connection.  I guess one question is if passing STREAM frames whole (at most changing the stream ID) is stateless for the middlebox.

Also, I'm not clear where we ended up on silent close. If we're indeed expecting endpoints to see that all the streams are closed to begin the shutdown, then we have to see that all the streams are closed.

On Fri, Jul 7, 2017 at 9:58 AM, Jana Iyengar <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Jul 7, 2017 at 9:48 AM, Martin Duke <[e-mail]<mailto:[e-mail]>> wrote:


On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar <[e-mail]<mailto:[e-mail]>> wrote:
> Without such a signal, a generic proxy that is not aware of your application internals is not able to know when to send the FIN
I see, this use case does make somewhat sense, however I'm curious if someone has a concrete use case for a generic QUIC proxy which is not aware of the application protocol at all. In TCP this was more common for middleboxes to do because there was no end to end encryption of the transport, however QUIC is encrypted. Even with cases when we tunneling protocols at our end, we usually have some knowledge of the app that we are running because we need to route them differently to different backends. I was mostly thinking that proxies would at least have some knowledge about HTTP/2 or app protocols.

Some load balancers (including ours) terminate the transport connection. Being trusted middleboxes, they have the certificates and this sort of thing works in principle.

That said, in such a case it's entirely feasible to implement HTTP/2 on the middlebox as well.

If these middleboxes terminate the transport connection for QUIC, would they need to understand stream semantics? Or would they simply terminate the QUIC connection, but relay the STREAM frames without any changes?
I'll note that all transports after TCP have two general parts to them -- the packet transport part, and the application semantics part. Middleboxes are usually interested in the "lower half" of the transport - the packet transport part.

That said, I'm not opposed to having an explicit bit. I'm also wondering if there's a real use case, or if we're provisioning for the future here.

- jana

However, I think we should look forward to the day where QUIC is implemented in kernel space and HTTP/2 (and everything else) remains an application. I imagine counting on all applications to do this kind of garbage collection could cause problems.