Re: QUIC - Our schedule and scope

[Joerg Ott <[e-mail]>]

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 <[e-mail] 
>> <mailto:[e-mail]>> 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.
>>
>> 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". 
> 
> 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 <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>>     > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) <[e-mail] <mailto:[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] <mailto:[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/
>>
>>
>>
>>
>>
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
>