Re: Pipelining in HTTP 1.1

Yes. It sounds like it should discuss ordering within a stream that is  
reused, and should also discuss the fact that SCTP streams (and  
therefore requests distributed among several) can be delivered in any  
order.

On Mar 30, 2009, at 3:39 PM, Preethi Natarajan (prenatar) wrote:

>
>
>> -----Original Message-----
>> From: ietf-http-wg-request@w3.org
>> [mailto:ietf-http-wg-request@w3.org] On Behalf Of David Morris
>> Sent: Monday, March 30, 2009 3:05 PM
>> To: ietf-http-wg@w3.org
>> Cc: ietf-http-wg@w3.org
>> Subject: Re: Pipelining in HTTP 1.1
>>
>>
>> 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.
>>
>
> Your understanding of SCTP streams is accurate. What you are saying
> confirms my earlier suspicions that the "pipelining" section in 2616
> actually defines "pipelining over TCP" and not "pipelining over a
> transport connection".
>
> I suppose a spec describing HTTP over SCTP should accurately define
> "pipelining over SCTP streams" and discuss how it relates to 2616.
>
> Thanks,
> Preethi

Received on Monday, 30 March 2009 22:46:46 UTC