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

[William Chan (陈智昌) <[e-mail]>]

On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl <[e-mail]> wrote:

>
> On 28. aug. 2013, at 11:53, William Chan (陈智昌) wrote:
>
> On Aug 28, 2013 4:01 PM, "Michael Welzl" <[e-mail]> wrote:
> >
> > Hi,
> >
> > I agree 100% with Michael Tuexen here... just one thing, in line:
> >
> >
> >>> 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.
> >
> >
> > Indeed that's not an argument against SCTP/UDP/IP, but I also wonder
> why, instead of saying "can't be deployed", people don't just go ahead and
> use it whenever it's there and works, with a fall-back to TCP? This could
> be done with (this version of) Happy Eyeballs:
> > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02
> >
> > Good reasons against doing this are... what? Anyone?
>
> Implementation usefulness. Why bother adding code that barely gets used
> (and that is unlikely to improve in the near future), adds complexity, code
> bloat, etc...?
>
> Fair point. That's why I think the OS should in fact do Happy Eyeballs for
> you!
>
>
I'm not sure if you're trolling me. In case you aren't, you may want to
look at the graph at: http://gs.statcounter.com/#os-ww-monthly-201207-201307.
Windows XP (released in 2001) is still around 20% of browser usage. If you
have the ability to get Microsoft to backport SCTP/IP onto their XP stack,
I'd love to know. We're not going to ignore large segments of our user base
when we could use UDP and deploy for all relevant OSes. That may be
acceptable for some applications, but not for the browser I work on.

This is why Roberto said:
"""
Wide, "safe" deployment
"""

> SCTP/UDP has a much higher likelihood of usefulness. But as Roberto has
> mentioned, it still has deficiencies, mostly around RTTs (connection + DTLS
> setup). If they can be fixed, great. Let's do it.
>
> Why shouldn't it be possible to fix SCTP to do whatever you want? Anyway
> it sounds to me like a simpler approach than building a whole new protocol.
> Of course, SCTP++ isn't the nicest acronym...  then again, RTMFP isn't
> either, if you ask me, sounds almost like RTFM...  QUIC is great though!
>

I have no attachments to the protocol name or frame format or whatever.
Look at what we're doing in HTTP/2 which was inspired by SPDY but now has
undergone substantial changes. We're serious about this. As long as the
transport provides all the features we need, we'll use it. This
conversation got started because tsvwg asked httpbis what the application
layer wants from the transport. We're telling you. I think the constructive
next step is for tsvwg folks to ask for clarification on any requirement
they don't understand, discuss whether or not the requirements are
reasonable, and discuss what may need to be done to address them.


>
> Cheers,
> Michael
>
>