Re: [QUIC] Draft charter

[Jana Iyengar <[e-mail]>]

Christian, Mark,

I'll start off by agreeing with Christian that QUIC is functionally
separable into "layers" (for lack of a better word). But this is not new.
Any transport that tries to separate application semantics from
network-level functions such as loss recovery and congestion control is
bound to be complex enough to be implementing these separable functions.
SCTP, SST, QUIC, are all good examples of this general idea, and that's
because these are all relatively complex transports. They are different
however in the boundaries that they collapse. (From this point of view,
QUIC is actually closer to SST than it is to SCTP.)

Bryan Ford and I did some transport decomposition work a while ago (you may
be familiar with it), and here's a section of an architectural draft we
wrote in 2009 that is relevant here:
https://tools.ietf.org/html/draft-iyengar-ford-tng-00#section-3.
Specifically, it separates the functions you mention into multiple
connection contexts, with multiple streams stacked on top of multiple
connection contexts.

So, it seems architecturally sensible (at least to me) to think about these
functions separately. That said, any protocol instantiation of these
functions will appropriately collapse these layering boundaries for
efficiency. The real question here is whether the particular set of
transport functions that QUIC implements and the set of "layering"
boundaries that QUIC collapses result in something powerful enough to be
useful and general enough to be extensible. In other words, IMO, the
question about QUIC ought to be whether it is specific enough to provide
performance benefits for particular applications, and general enough to
allow more applications to extend it in the future.

The answer to the first question is a resounding yes. We have running
deployed code and we have presented data about the benefits of QUIC for
HTTP traffic. The answer to the second question is something we'll only
know by trying. The charter is currently scoped to pursue the first
question first -- by building QUIC for HTTP as the first application. The
QUIC wg can and should continue chasing more application mappings after
HTTP, to see how general QUIC ends up being. If  QUIC falls short of a next
application that we thought might fit, that's an argument for either
refitting QUIC, or for building a different protocol that collapses these
functional boundaries differently, and maybe even chooses different
functional components. I think this is a perfectly reasonable outcome that
we should anticipate. DPRIVE or DNS may not fit on top of QUIC, and that's
fine (*).

I think this is also exactly how we should pursue new transport work at the
IETF. I would strongly argue against generalizing QUIC too much before
building it for HTTP. I am very wary of building a "kitchen-sink" transport
that tries to satisfy several applications at once. At the same time, I
would not start by strait-jacketing QUIC to be only for HTTP. The core
primitives are not going to be universally useful, but they will be
undoubtedly more generally useful than just for HTTP. The document division
in the charter captures this thinking, and I think that it's workable.

Just my thoughts.

(*) - In principle, I think you can do this though. QUIC, like SST, has
lightweight streams. You can map a transactional app by mapping a stream to
each transaction... and this has some really nice properties for the
application. But I don't want to rathole on designing QUIC for DNS here.

- jana







On Tue, May 31, 2016 at 7:03 PM, Mark Nottingham <[e-mail]> wrote:

> Hi Christian,
>
> > On 1 Jun 2016, at 11:11 AM, Christian Huitema <[e-mail]>
> wrote:
> >
> > I think that QUIC really has two layers. There is a bottom layer that
> manages the transmission of encrypted packets, the detection of errors, and
> possibly the forward error correction. Then there is an upper layer that
> manages the multiplexing of streams, and that cooperates with the bottom
> layer to manage retransmissions.
> >
> > Currently, the two layers are tied in multiple ways. The encryption
> layer cannot function without passing the stream 1 packets to the TLS
> machinery. The stream management frames share a number space with the error
> management frames. The per connection receive window is managed as the
> aggregate of the per stream receive window. But these are in fact simple
> problems, and it should be possible to disentangle the error detection
> layer and the stream management layer.
> >
> > After that, yes, there are quite a few possible innovations. The stream
> abstraction works well for HTTP 2.0, but I would rather use a
> transaction-based logic for DPRIVE, and maybe something different still for
> real-time multi-media. Or, if we think of multi-path, I could see a stream
> layer being multiplexed over two separate lower layers, managed as two
> separate connections.
> >
> > The whole point of defining a user mode transport is to enable this kind
> of innovation!
>
> This makes me wonder if QUIC is anything but a collection of functions
> that can be assembled by an application; as it is, the charter carves off
> crypto into TLS; FEC and congestion control are defined externally;
> multi-path is an extension. If streams are also optional, what's left? Loss
> recovery?
>
> I'm not against such a modular approach, but standardising it IMO will
> present some real challenges. Enough to make me wonder if just defining
> QUIC as HTTP/2-over-UDP is better; other applications could reuse its
> primitives as they like. It might not be as tidy, but it's a lot more
> workable...
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> QUIC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/quic
>