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

[Brian Trammell <[e-mail]>]

hi Michael, all,

On 28 Aug 2013, at 13:53 , 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!

My only concern here -- and I say this as someone who's a big fan of the general approach of endpoints being smart in how they work around deficiency in the network -- is that SCTP and TCP provide different services. This is unlike the case with IPv4 and IPv6, the differences between which are completely hidden behind the API (in the common case, in the modern world, anyway). 

So even if the OS handles the fallback (which it should), the application still has to determine whether the SCTP features it wants to use are available, unless the OS also provides SOCK_SEQPACKET (or equivalent) service with partial reliability and/or multihoming and/or streams over TCP.

>> 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.

This, absolutely. But in order for it to take off, we need to make it as simple as possible for application developers to adapt to the availability different transport capabilities and services, which is more an API than a protocol issue.

Cheers,

Brian