- From: 陈智昌 <willchan@google.com>
- Date: Wed, 28 Aug 2013 21:44:38 +0800
- To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Cc: Michael Welzl <michawe@ifi.uio.no>, Yoav Nir <ynir@checkpoint.com>, Mike Belshe <mike@belshe.com>, HTTP Working Group <ietf-http-wg@w3.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
- Message-ID: <CAA4WUYic66HeiGOw74qLh5CP5Q0i7yf=GoRO4_6iyp24NTW4=w@mail.gmail.com>
On Wed, Aug 28, 2013 at 9:41 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On Aug 28, 2013, at 3:34 PM, William Chan (陈智昌) <willchan@google.com> > wrote: > > > On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl <michawe@ifi.uio.no> > wrote: > > > > 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! > > > > > > 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. > You can build SCTP in your browser and run it on top of UDP. This is what > is done > in RTCWeb. They use SCTP over DTLS over UDP with SCTP and DTLS running in > the > application layer. This is available in recent versions of Firefox and > running > on Windows XP... > You may have missed the fact that Michael Welzl was talking about SCTP/IP and I was responding to that. You may also have missed my note below about SCTP over UDP where I said: "SCTP/UDP has a much higher likelihood of usefulness." Cheers. > > Best regards > Michael > > > > 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 > > > > > >
Received on Wednesday, 28 August 2013 13:45:06 UTC