On 28. aug. 2013, at 11:53, William Chan (ιζΊζ) wrote: > On Aug 28, 2013 4:01 PM, "Michael Welzl" <michawe@ifi.uio.no> 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! > 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! Cheers, Michael
Received on Wednesday, 28 August 2013 11:53:57 UTC