- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 8 Apr 2009 16:38:07 +1000
- To: leighton@mail.eecis.udel.edu
- Cc: ietf-http-wg@w3.org, fred@cisco.com, amer@cis.udel.edu, prenatar@cisco.com
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. The current proposals (AIUI) are less intrusive, because at a certain point a SCTP stream just looks like a TCP connection. 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. Perhaps this should be an open design question in a HTTP-over-SCTP draft, to try to get feedback from interested vendors... Cheers, On 02/04/2009, at 11:58 AM, leighton@mail.eecis.udel.edu wrote: > At the recent HTTP WG meeting the subject of HTTP over SCTP was > discussed, > and in particular the question was raised as to whether or not SCTP > could > be used to avoid chunked encoding. There are two ways to do this, > but one > of them (EXPLICIT_EOR socket option) conflicts with current thinking > about > how best to send HTTP over multiple SCTP streams. The other > approach is > to use the payload protocol identified or PPID. > > The PPID is an optional value that is set by the sender and read by > the > receiver. The approach would be to define two PPID values > (allocated by > IANA), say HTTP_MESSAGE_PIECE and HTTP_MESSAGE_END. The sender > would set > the PPID to HTTP_MESSAGE_END for the last sctp_sendmsg() call for the > current HTTP object, thereby allowing the receiver to identify the > end of > the current HTTP object. > > I'm far from being an expert in HTTP, and I would be grateful for > feedback > on the suitability of this mechanism. Thanks very much. > > - Jon Leighton > > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 8 April 2009 06:38:49 UTC