Re: Adding SCTP support

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