Subject: Re: QUIC - Our schedule and scope

From: Bernard Aboba <[email-masked]>
Date: Wed, 1 Nov 2017 00:16:11 -0700

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 <[email-masked]> wrote:

>
> > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) <[email-masked]>
> 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 <[email-masked]> 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/
>
>
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Nov 2017 09:50:28 +0000

> On 1 Nov 2017, at 07:16, Bernard Aboba <[email-masked]> wrote:
> 
> 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.
> 
> [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". 

There are several options for the packet format, and a shim is only one. 

Whether we define a shim, or change the QUIC header format to allow demuxing, we should do it early enough so middleboxes are aware. Otherwise, we’ll see ossification around a format that prevents peer-to-peer use.

> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> * 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.
> 
> https://csperkins.org/ <https://csperkins.org/>
> 
> 
> 
> 
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Joerg Ott <[email-masked]>
Date: Tue, 7 Nov 2017 10:06:30 +0100

I agree with Colin.  We had this discussion about the multiplexing
very briefly in Paris (if my memory works properly) and this need
was too quickly discounted.  We don't want to maneuver outselves
into a corner when applications like WebRTC are on the horizon.

Like Colin said, the mechanism is secondary but we need to act
here for v1.

Jörg

On 01.11.17 10:50, Colin Perkins wrote:
> 
>> On 1 Nov 2017, at 07:16, Bernard Aboba <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Colin Perkins said:
>>
>> 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.
>>
>> [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". 
> 
> Whether we define a shim, or change the QUIC header format to allow 
> demuxing, we should do it early enough so middleboxes are aware. 
> Otherwise, we’ll see ossification around a format that prevents 
> peer-to-peer use.
> 
>> 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.
>>
>>
>>
>>     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.
>>