Subject: [QUIC] Where does this effort stand wrt webrtc data channels?

From: Paul Kyzivat <[email-masked]>
Date: Sat, 7 May 2016 10:47:32 -0400

I just found the announcement of this list, and it raised more questions 
than answers. If this were a wg list then I could look at the charter to 
get an idea of what it is about, but it seems there is nothing.

The announcement says:

> QUIC is a UDP-based transport protocol that provides multiplexed
> streams over an encrypted transport. While QUIC has been described
> externally in the context of an HTTP-focused deployment, this mailing
> list will discuss standardizing QUIC’s core transport protocol and
> separately specify the mapping of the transport protocol to the
> facilities of TLS. An additional work item of will be to describe how
> to map specific application semantics onto the transport, starting with
> the semantics of HTTP/2

ISTM the webrtc data channel mechanism, using SCTP over DTLS over UDP, 
satisfies the description of what this is looking for.

I'm sure the organizers here are aware of that, so there must be some 
reason for discussing something that is presumably different.

Can somebody explain the thinking here?

	Thanks,
	Paul

---

From: Ted Hardie <[email-masked]>
Date: Sat, 7 May 2016 18:24:05 -0700

Hi Paul,

The BoF request is in TRAC now.  The mailing list request went in first, so
the BoF request could include the mailing list information. As a result,
the mailng list got announced before the BoF request was posted; sorry for
any confusion from the race condition. The URL, for your convenience, is:

https://tools.ietf.org/bof/trac/

> reason for discussing something that is presumably different.
QUIC is an existing protocol, see
https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02  for a
description.  As you'll see from the BoF description, the proposal is to
split the current omnibus description into multiple pieces, so that the
core transport protocol can be used in systems that aren't based on HTTP/2
semantics.

> I hope that gave some context,

regards,

Ted

>         Thanks,
>         Paul
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 8 May 2016 14:30:25 -0400

Thanks Ted.

I think I get it, that this is really starting on optimization of 
http(s), and so that dominates the engineering decisions. Any functional 
equivalence to data channels is entirely coincidental.

	Thanks,
	Paul

On 5/7/16 9:24 PM, Ted Hardie wrote:
> Hi Paul,
>
> The BoF request is in TRAC now.  The mailing list request went in first,
> so the BoF request could include the mailing list information. As a
> result, the mailng list got announced before the BoF request was posted;
> sorry for any confusion from the race condition. The URL, for your
> convenience, is:
>
> On Sat, May 7, 2016 at 7:47 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I just found the announcement of this list, and it raised more
>     questions than answers. If this were a wg list then I could look at
>     the charter to get an idea of what it is about, but it seems there
>     is nothing.
>
>     The announcement says:
>
>     ISTM the webrtc data channel mechanism, using SCTP over DTLS over
>     UDP, satisfies the description of what this is looking for.
>
>     I'm sure the organizers here are aware of that, so there must be
>     some reason for discussing something that is presumably different.
>
>
> core transport protocol can be used in systems that aren't based on
> HTTP/2 semantics.
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Erik Nygren <[email-masked]>
Date: Thu, 12 May 2016 21:54:33 -0400

On Sun, May 8, 2016 at 2:30 PM, Paul Kyzivat <[email-masked]> wrote:

> I think I get it, that this is really starting on optimization of http(s),
> and so that dominates the engineering decisions. Any functional equivalence
> to data channels is entirely coincidental.
>

Mike Bishop's draft on Decomposing/Disentangling HTTP may provide some very
helpful context:

      https://tools.ietf.org/html/draft-bishop-httpbis-decomposing-http-00

In particular, "HTTP" logically has multiple layers and HTTP/2 specifies a
binding
of HTTP semantics onto a new multiplexed framing layer.

QUIC is a secure transport protocol with a multiplexed stream abstraction.
One of its design trade-offs is to integrate the security mechanism (now
QUIC_Crypto,
hopefully TLS 1.3 in the future) in fairly tightly.  For better or worse,
the result
is more integrated than SCTP-over-DTLS-over-UDP.

The binding of HTTP onto it in the initial draft is not much different from
(and heavily leverages)
the HTTP/2 framing layer using one of the QUIC stream pairs for
metadata/headers
and additional QUIC stream pairs for request/response message bodies.
There's a fairly clear separation.

I think one of the interesting topics in standardization is what hooks make
sense
to add to QUIC to cover additional general-purpose use-cases.
For example, having a lossy stream/frame type with no error recovery
but still convered under the QUIC flow-control is a primitive that
likely makes sense to add in but which is very much not HTTP-specific.

  Erik