- From: Preethi Natarajan (prenatar) <prenatar@cisco.com>
- Date: Mon, 30 Mar 2009 20:49:55 -0400
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: <ietf-http-wg@w3.org>, "Jonathan Leighton" <leighton@cis.udel.edu>, "Paul D. Amer" <amer@cis.udel.edu>, "Fred Baker (fred)" <fred@cisco.com>
> -----Original Message----- > From: Roy T. Fielding [mailto:fielding@gbiv.com] > Sent: Monday, March 30, 2009 5:05 PM > To: Preethi Natarajan (prenatar) > Cc: ietf-http-wg@w3.org; Jonathan Leighton; Paul D. Amer; > Fred Baker (fred) > Subject: Re: Pipelining in HTTP 1.1 > > > I am somewhat surprised that your HTTP over SCTP spec allows > channels to be reused. Is there a significant cost > associated with channel allocation? SCTP end points negotiate the number of streams during connection setup. Each SCTP stream requires extra storage in the SCTP TCB for maintaining state. While the exact amount of storage per stream varies with the SCTP implementation (~32 bytes in FreeBSD), this space requirement should be significantly lower than the cost associated with setting up a new TCP TCB. The number of SCTP streams can be increased by the stream reset functionality (http://tools.ietf.org/html/draft-stewart-sctpstrrst-05). However, our current design does not include stream reset since it is still an ID proposal and is on track to become a TSVWG item soon. > TCP persistent > connections added a huge amount of complexity and > fairness/denial-of-service issues to HTTP servers just to > avoid the side-effects of TCP slow-start and connection > negotiation. With SCTP, the server can maintain a single persistent SCTP connection with the client and grant/deny subsequent client requests from the client to increase the number of SCTP streams (via stream reset mentioned above). Thanks, Preethi
Received on Tuesday, 31 March 2009 00:50:44 UTC