On 2009-11-13, at 10:09 AM, Roberto Peon wrote:
Speaking as the person who would be responsible for much of the work of sticking sctp in for google, the greatest challenges are seemingly the home routers/nat devices. Both server and client-side changes are trivial when using the sockets API.
Start by tunnelling SCTP over UDP? Home users would be willing to open a UDP port on their router if it improved their browsing experience.
Note that our research Haas found that multiplexing itself may actually be harmful... it is multiplexing plus client assigned priorities that seems to be the winning combination.
A priority header could also be added alongside an HTTP request identifier.
If all my wishes came true tomorrow, Sctp would be widely deployed, would give userspace applications easy access to a representation of bytes in flight, cwnd, and other important connection properties...and would support channel bases priorities.The connection properties are interesting for varying server and client behavior to better serve the user. I really want to send data to someone using a satellite uplink fir data differently than a mobile user, or someone with a nearly lossless 100 Mb link!
That's true, the application should react differently depending on the capacity. Discovering the capacity quickly would seem to require a combination of client and server hints together with feedback from the connection. The application-level API for this might not be simple -- it may be analogous to the transition from single threaded to multi-threaded APIs. Do you have a version of this in a SPDY API? Ted.
On Nov 13, 2009 8:47 AM, "Ted Goddard" <ted.goddard at icesoft.com> wrote:On 2009-11-12, at 7:45 PM, Thomson, Martin wrote:I’m also increasingly of the view that channels-based protocols aren’t necessarily the right way to solve head-of-line blocking problems. There are other methods that do not demand the same overheads. For instance, a simple request identifier can be used for request-response correlation.A request identifier (say, as an HTTP header) appears to have a number of useful properties: - it can be optionally specified, so only clients supporting the feature need be aware of it - it can be ignored by the server, so server implementation is also optional - there is no latency for channel setup; uniqueness of the identifier can be a client responsibility, so there is no negotiation cost - the same identifier can be applied to chunked responses, allowing large responses to be interleaved Would an existing HTTP proxy be confused by interleaved, "identified" chunks?I’m actually more excited about the prospect of getting HTTP over SCTP.What if google began providing their current services over SCTP? This will need a critical mass to get started. (There is also the small problem of missing SCTP client stacks.) Ted. _______________________________________________ hybi mailing list hybi at ietf.org https://www.ietf.org/mailman/listinfo/hybi
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.