Re: Unidirectional streams PR

["Charles 'Buck' Krasic" <[e-mail]>]

On Mon, Jul 10, 2017 at 9:11 AM, Lubashev, Igor <[e-mail]> wrote:

>
>    - 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.
>
>
>

This may not always be true?  A proxy that has certs might want to improve
perfromance, e.g. it might be aware of HTTP priorities and decide to
forward newer higher priority stream frames before older ones, in which
case it might even re-packetize.


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]> wrote:
>
> On Fri, Jul 7, 2017 at 9:48 AM, Martin Duke <[e-mail]>
> wrote:
>
>
>
>
>
> On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar <[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.
>
>
>
>
>



-- 
Charles 'Buck' Krasic | Software Engineer | [e-mail] | +1 (408)
412-1141