Re: QUIC - Our schedule and scope

[Bernard Aboba <[e-mail]>]

Colin Perkins said:

"I do think that peer-to-peer uses of QUIC need attention pre-V1, if
they’re to be supported cleanly. At minimum, we need to arrange the QUIC
headers to easily demultiplex with STUN on the same UDP port, otherwise
we’ll end-up re-inventing STUN within QUIC. Focussing solely on HTTP is
going to make this difficult.

See draft-aboba-avtcore-quic-multiplexing-00 for more discussion."

[BA]  Peer-to-peer uses of QUIC are under development, and are quite likely
to be deployed in advance of a v2 specification.

 As the multiplexing draft makes clear, there is an alternative (a single
octet shim) that enables de-multiplexing of QUIC without modification (or
even consideration) of QUIC headers.  So while native demultiplexing QUIC
headers from STUN might be preferred, this probably can't be characterized
as a "must have".

Given that some of the most popular peer-to-peer uses involve unreliable
data exchange (e.g. in games), support for that is a basic requirement.  A
"quick and dirty" approach would be to utilize a QUIC stream for each
message, while setting a timer so as to approximate a data channel's
maxPacketLifetime parameter.  A more thorough solution would be to support
unreliable QUIC streams natively, allowing maxPacketLifetime or
maxRetransmits to be enforced on a per-packet basis, mimicing the behavior
of an unreliable RTCDataChannel running over SCTP/DTLS/UDP.

The problem with the "quick and dirty" approach is that many peer-to-peer
data exchange developers are obsessed with latency and therefore may prefer
no retransmissions at all.  This could lead to widespread deployment
of draft-tiesel-quic-unreliable-streams prior to standardization.



On Sun, Oct 29, 2017 at 11:08 AM, Colin Perkins <[e-mail]> wrote:

>
> > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) <[e-mail]>
> wrote:
> >
> > hi Mark, all,
> >
> > Broadly, I support Patrick's intepretation here. I'll point out that
> there seems to be some inconsistency between two points below:
> >
> >> On 27 Oct 2017, at 08:26, Mark Nottingham <[e-mail]> wrote:
> >>
> >> 2) V1 of QUIC should *only* address the use case of HTTP.
> >
> > and
> >
> >> * V1 will need to document the "invariants" of QUIC -- i.e., the parts
> on the wire that will not change -- to allow other use cases to be
> addressed by V2 and beyond.
> >
> > That QUIC's handshake, pre-version-negotiation wire image, and
> ossification-prevention features will be "baked in" in V1 is clear, and I
> thought it already had been, though thanks for calling it out here.
> >
> > Focusing on *only* addressing HTTP in this wire image, though, seems
> like it might be dangerous in ways I can't fully articulate yet... HTTP is
> an explicitly asymmetric protocol, with different roles for client and
> server well beyond the initial handshake, and as it is presently most
> commonly deployed, wildly different architectures for client-side and
> server-side implementations. Many of the things that we suspect we'll want
> to bring on top of QUIC in the future are less so; even Web protocols like
> WebSockets fit here. Will this focus lead to invariants that will make less
> asymmetric applications harder to build and deploy? Should we be concerned
> about that at this point?
>
>
> I do think that peer-to-peer uses of QUIC need attention pre-V1, if
> they’re to be supported cleanly. At minimum, we need to arrange the QUIC
> headers to easily demultiplex with STUN on the same UDP port, otherwise
> we’ll end-up re-inventing STUN within QUIC. Focussing solely on HTTP is
> going to make this difficult.
>
> See draft-aboba-avtcore-quic-multiplexing-00 for more discussion.
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>