- From: <leighton@mail.eecis.udel.edu>
- Date: Thu, 25 Jun 2009 16:53:13 -0400 (EDT)
- To: "Henrik Nordstrom" <henrik@henriknordstrom.net>
- Cc: "Mark Nottingham" <mnot@mnot.net>, ietf-http-wg@w3.org, fred@cisco.com, amer@cis.udel.edu, prenatar@cisco.com
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