Re: QUIC use cases

> On 19 Jan 2018, at 10:45, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> 
>> On 19. Jan 2018, at 00:03, Justin Uberti <juberti@google.com> wrote:
>> 
>> Also:
>> 4. 6 RTTs needed to set up ICE + DTLS + SCTP, vs 2 for ICE + QUIC.
> Will this still be true with DTLS 1.3? It is not difficult to extend
> SCTP to allow 0 RTT connection setup in the context SCTP/DTLS, since
> we don't need to cookie protection.

Indeed, from my sctp4j:

    /*
     Ok - confession here - we are not following the RFC. 
     We don't encode a pile of stuff into the cookie and decode it
     when we get the cookie back, then use that data to initialize the Association.
     The rationale in the RFC is to protect the Association from resource exhaustion
     by fake cookies from bad guys - which makes sense if you are a naked SCTP stack on
     the internet accepting UDP packets (or IP ones).
     We on the other hand have already been through 2 levels of validation with ICE and DTLS,
     and have already committed a pile of resource to this connection, so 32 bytes more won't kill us.
    
     The only downside is that if the far end spams us with a pile of inits at speed, we may erase one that we've
     replied to and that was about to be a happy camper. Shrug.
     */
    private CookieHolder checkCookieEcho(byte[] cookieData) {


> 
> Best regards
> Michael
>> 
>> On Sun, Jan 14, 2018 at 9:03 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>> Lennart said:
>> 
>> "So, please, if someone tells you that data channels suck and they'd be
>> excited to get QUIC data channels, please drill them with questions what
>> sucks exactly and then post it on the mailing list or file issues."
>> 
>> [BA] The developers using SCTP for small unreliable file transfers seem satisfied overall (e.g. they just complain
>> about bugs, not issues with the specification).
>> 
>> The developers who have attempted to implement file transfers on SCTP data channels have encountered much
>> more fundamental problems, including:
>> 
>> 1. Competition between SCTP data channels and audio/video, due to building of queues.  Currently,
>> data channel implementations use the default SCTP congestion control  (loss-based, defined in RFC 4960),
>> and don't expose a way of selecting an alternative algorithm.  One developer I talked to expressed an
>> interest in being able to use an algorithm like LEDBAT for a background file transfer, so I'm not clear
>> that a new cc algorithm needs to be standardized in IETF.
>> 
>> 2. Complexity of doing large file transfers on top of RTCDataChannel message implementations.
>> You've mentioned a number of the issues with this, and most of them seem solvable by fixing issues
>> in the existing specification, and perhaps adding some tests to make sure that implementations conform
>> to the new guidance.
>> 
>> 3. Availability of multiple implementations.  I have heard complaints along the lines that Iñaki has
>> described from other sources.  This isn't something the W3C or IETF can fix, but overall the perception
>> in the developer community is that QUIC is very likely to be widely deployed and supported within
>> developer tools.  Several of the developers who had not been able to successfully utilize SCTP
>> are now considering QUIC (using the client-server approach), and seem comfortable enough with the protocol
>> and availability of tools that I doubt they would go back to considering SCTP data channels even with
>> some of the above fixes.
>> 
>> 
>> 
>> 
>

Received on Friday, 19 January 2018 10:51:53 UTC