On sön, 2008-06-01 at 10:43 -0400, Matt Benjamin wrote: > The most compelling reason to use SCTP for HTTP delivery would seem to > be the potential to improve throughput via SCTP multi-streaming.
In TCP that is done by having multiple concurrent TCP connections, which is pretty close to the same. But with SCTP it's possible to cut down on the latency overhead when one needs to start a new stream, and to get a coherent view of the path shared by all streams.. (TCP maintains a lot of that view per TCP connection.. rtt estimate, slow start, etc...) SCTP also has a potential of optimizing delivery if there is many small pieces as it can batch fragments from several streams in the same packet, but not sure how much this can buy for HTTP. The biggest mismatch for HTTP over SCTP is that there is no per-stream "ABORT" or "End-of-file" conditions in SCTP. While SCTP do provide message boundaries it's not trivial to utilize this to map to HTTP messages in the general case. Lack of per-stream "ABORT" means that the requesting client (or server) can not selectively abort some of the requests in case of error or dropped interest in the message (i.e. client moving on to another page). To abort it needs to close the SCTP association and open a new one, which aborts all streams at once. For a browser this maybe is the desired thing, but it's not the same in a proxy as proxy connection management is independent client<->proxy and proxy<->nexthop. The lack of per-stream "End-of-file" means that HTTP/1.1 chunked encoding or explicitly known content-length still needs to be used with all its framing issues, even if SCTP as such do have a concept of message boundaries. It should in theory be possible to use the SCTP message boundaries as an alternative framing mechanism, but from what I have seen so far the SCTP socket APIs places this at a too low level to be really useful, constructing the SCTP messages based on individual sendmsg calls by the application instead of allowing the application to control this. Important as quite often the whole message is not available at once.. And additionally SCTP does not allow for a 0-sized "End-Of-File" chunk making this even harder even if the api issues is eventually handled.. but for simple messages where Content-Length is known and not too large the STCP message boundaries would work (i.e. delivery of a small static file or otherwise fully buffered response of limited size). Maybe some interesting tricks can be done with the payload protocol field to overcome these limitaions without having to introduce yet another protocol layer overhead, but it's not how the payload protocol field is meant to be used. It's a pity SCTP got specified with these quite innocent limitations, as it somewhat limits it's applicability to HTTP. Regards Henrik
signature.asc
Description: This is a digitally signed message part
