Re: Pipelining in HTTP 1.1

[David Morris <[e-mail]>]

Use caution for anything which might re-order processing of transactions 
which are not idempotent. Pipelining includes some rules regarding
waiting for responses in those cases. I think you are attempting to mix 
apples and oranges and are going to confuse the reader. If I understand 
SCTP correctly, each SCTP stream is equivalent to a unique TCP connection
in terms of packet flow management. So your different streams  is 
equivalent to multiple connections under classic HTTP/TCP. That being the 
case, HTTP pipelining rules and discussion applies to each individual SCTP
stream and anything below that layer shouldn't be considered by HTTP.

Pipelining retains the order of requests within a TCP connection. Again 
per my understanding SCTP retains the order within the SCTP stream but
not between streams so to compare behavior at the SCTP transport level
with behavior at the TCP connection level makes no sense to me.

David Morris

On Mon, 30 Mar 2009, Preethi Natarajan (prenatar) wrote:

> Hello folks,
>
> I would like your comments on the following. This is w.r.t. HTTP over
> SCTP (draft-natarajan-http-over-sctp-01) and I am trying to comprehend
> "pipelining" in the context of HTTP 1.1.
>
>> From Section 8.1.2.2 of RFC2616:
>
> "A client that supports persistent connections MAY "pipeline" its
> requests (i.e., send multiple requests without waiting for each
> response). A server MUST send its responses to those requests in the
> same order that the requests were received."
>
> We (SCTP folks) assume that "persistent connection" in this section
> refers to a persistent _transport_connection. When multiple HTTP
> requests and responses are sent back-to-back on a persistent transport
> connection, the HTTP transactions are pipelined.
>
> In our HTTP over SCTP streams design, we recommend transmitting HTTP
> requests/responses over different SCTP streams, but note that these
> reqeusts/responses are transmitted back-to-back within an SCTP transport
> connection. I.e., the HTTP transactions are pipelined across multiple
> streams of an SCTP transport connection but are not pipelined within an
> SCTP stream. I am tempted to say that this design still confirms to the
> "pipelining" definition as per RFC2616.
>
> Thoughts?
> Preethi
>
>
>
>