Re: [tsvwg] The List (of application-layer desired features)

On Aug 6, 2013, at 11:30 AM, Mike Belshe <mike@belshe.com> wrote:

> 
> 
> 
> On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> I think most of that is addressed in SCTP.  Except the deployment part. Standards people can’t force vendors of operating systems or Linux distributions to include any feature. So we have a lot of “version 2”s in the IETF that take a very long time to get deployed.
> 
>  
> 
> It’s also much more attractive to define a new thing (like SCTP) than to make something old work a little better. SCTP was sexier than TCPM.
> 
>  
> 
> So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all three are still used far less than IPv4, IKEv1 and TLS 1.0. SCTP is used almost never. HTTP/2 will likely fare better because the vendors are more involved and committed, but it’s hard to make predictions, especially about the future.
> 
> 
> You're right, SCTP is non-deployable, which makes it a non-starter.  SCTP also does not address handshake issues or TLS issues.
I agree that SCTP over IP can't be deployed now due to missing NAT support.
But why can't SCTP/UDP/IP (RFC 6951) be deployed now? Also SCTP as specified now
is not optimised for fast setup. It needs an RTT before it can send the first
user message. However, I think one can easily extend it to provide a fast association
setup...
> 
> I don't mean to sound inflammatory - but for all intents and purposes, the next generation transport will need to be in user space and run on top of UDP.  There simply is no other deployable option on the table.  QUIC is already reasonably far at 
And why does "be in user space and run on top of UDP" exclude SCTP? There is also a
userland implementation supporting it. It also supports SCTP/DTLS/UDP and is
included in Firefox (for RTCWeb support).

Best regards
Michael
> exploring these issues: http://en.wikipedia.org/wiki/QUIC
> 
> Mike
> 
> 
> 
> 
>  
> 
>  
> 
> Yoav
> 
>  
> 
> From: Roberto Peon [mailto:grmocg@gmail.com] 
> Sent: Tuesday, August 06, 2013 11:16 AM
> 
> 
> To: HTTP Working Group; tsvwg@ietf.org
> Subject: Re: The List (of application-layer desired features)
> 
>  
> 
> Actually sending to the right list for TSVWG...
> 
>  
> 
> -=R
> 
>  
> 
> On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com> wrote:
> 
> For those of you who missed it, at the HTTPBis/TSVG joint session, a question about what applications want from the transport (I really want to put quotes around that) came up.
> 
>  
> 
> Here is a rendition of what was on the note that I jotted down in response to this question, and which I passed to people at the mic.
> 
>  
> 
> (Apps-folks want the following) Deployed in 1996:
> 
> -----------------------------------------
> 
> - Prioritization
> 
> - Partial Reliability
> 
> - "Shared" congestion between multiple streams
> 
> - Security
> 
> - No HOL blocking on stream X when loss on stream Y
> 
> - Cheap/Fast  channel/connection setup
> 
> - Wide, "safe" deployment
> 
> - Competes with TCP/HTTP/1.1 (performance-wise)
> 
> - Multipath/roaming robustness, i.e. the "driveway" problem
> 
>  
> 
>  
> 
> I'll reiterate that by far the most important feature is "is deployed".
> 
> Nothing else matters until that is true, at least at the application-layer.
> 
> -=R
> 
>  
> 
>  
> 
>  
> 
> 
> 
> Email secured by Check Point
> 
>

Received on Tuesday, 27 August 2013 09:48:13 UTC