Hi, > Wishful thinking alert! -- If it wasn't designed for a particular goal, it likely doesn't solve that particular goal. And no, SCTP was not designed for low-latency web transactions. Low-latency signaling messages (which it was designed for) don't strike me as being extremely different from low-latency web transactions... well, maybe the devil is in the detail. > Don't let me discourage you too much, I'd love to see what you say here turn out to be true. But if these protocols worked as you say, they'd be deployed already. You think nobody tried HTTP over SCTP? Of course we did! It's a Just curious, which implementation did you test? This group had posted pretty good results achieved with HTTP over SCTP long ago: http://www.eecis.udel.edu/~amer/PEL/index.html - although the only paper I can dig up from their page about this now is this one: http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SIGCOMM-NSDR2008-NatarajanMultistreamed-transport-developing-regions.pdf and now their page mentions a "SPDY over SCTP project supported by Google". So are you saying that the outcome of this project is disappointing already? > marginal improvement at best, after you get past all the complexity and bugginess of protocols that were not designed for this purpose. > > I hope this doesn't come across too harsh. No it doesn't - it's interesting and makes me want to dig deeper into QUIC and RTFMP to better understand what makes it perform so much better than SCTP. ( I figured that multi-streaming at the transport layer would be the big win, and since SCTP already gives you that, well... though I did notice the mention of e.g. lack of per-stream flow control in SCTP, which I also found to be a problem long ago... I had thought that this might have been fixed by now? Shouldn't be too hard to fix. ) Cheers, Michael
Received on Friday, 30 August 2013 07:29:53 UTC