Re: HTTP over SCTP without chunked encoding

Henrik -

Can you elaborate on your comment about trying to map multiple pipelined
TCP connections to a single SCTP association not working out well? 
Thanks.

- Jon


> Sorry for the late response.
>
> ons 2009-04-08 klockan 16:38 +1000 skrev Mark Nottingham:
>> I'm far from an expert in SCTP, but at first glance, this is
>> potentially attractive, but slightly more intrusive in the HTTP stack,
>> because it's introducing a new way to frame messages, rather than
>> reusing exising code to do so.
>
> Both yes and no.
>
> In terms of specification chunked encoding is a transport feature,
> independent of messaging semantics. But some implementations mixes the
> two a bit (quite natually).
>
> I am of the opinion that both modes should be specified from start, with
> receivers supporting both.  It's fairly trivial (with a little overhead)
> to rewrite a SCTP structured stream into chunked encoding if needed even
> without parsing so the implementation cost in supporting this at the
> receiver is minimal.
>
> Mapping chunked to SCTP PPID requires a little more than what was
> described earlier.
>
> A chunked HTTP message consists of the following parts
>
> * Initial header
> * Some data chunks
> * last-chunk
> * trailer
> * END [CRLF]
>
> Allowing this to be mapped cleanly to SCTP messages would provide a
> better SCTP transport for http with
>
> * less overhead, by reusing the length & ppid fields already present in
> SCTP.
> * if the same mapping is used for Content-Length messages as well then
> the parsing problems outlined in the response (and request) splitting
> attacks can be avoided
>
> This requires a bit more than the two mentioned PPID definitions
> mentioned earlier. In SCTP discussions I proposed a mapping of in total
> 4 PPID values I think, or to be exact 2 values + 1 bit signalling END.
>
>   HTTP Header  (also reused for the trailer portion)
>   HTTP Data payload
>
>
> Which would compose a HTTP message into the following SCTP messages
>
> chunked response with trailer:
>
>   1. HTTP Header
>   2. HTTP Data payload*N
>   3. HTTP Header + END
>
> In addition to this there needs to be some way to indicate per-stream
> error conditions, in both directions. At least until SCTP supports such
> notifications per-stream rather than on an association as a whole.
>
>
> On a related note it's worth mentioning that SSL imposes it's own
> interesting issues in this.. the above scheme only works for plain HTTP,
> not when wrapped in SSL. For SSL wrapped requests I see no option but to
> use chunked encoding within SSL as done today.
>
>> Now, whether this trade-off is worth it or not is an open question, of
>> course. I think most people are focused on the aspects of SCTP that
>> relieve the problems experienced with pipelining, and while having a
>> more efficient framing mechanism is interesting, it's not low-hanging
>> fruit.
>
> Actually the two is quite related.. at least in my eyes working at a
> proxy level were you have to deal with a high level of concurrency.
>
> For a single-user-agent it's not as complicated however. There the
> proposed simple SCTP trabsoirt provides a reasonably close resemblance
> to requests pipelined over a single TCP connections. But trying to map
> multiple pipelined TCP connections to a single SCTP association do not
> work out well in the proposed simple form, at least not yet.
>
> Regards
> Henrik
>
>

Received on Thursday, 25 June 2009 20:53:51 UTC