W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

RE: Pipelining in HTTP 1.1

From: Preethi Natarajan (prenatar) <prenatar@cisco.com>
Date: Mon, 30 Mar 2009 20:49:55 -0400
Message-ID: <C14B21C3CFBE6F4C81665B29F9880D3E0758A39D@xmb-rtp-214.amer.cisco.com>
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

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).

Received on Tuesday, 31 March 2009 00:50:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:48 UTC