Subject: Pipelining in HTTP 1.1

From: "Preethi Natarajan (prenatar)" <[email-masked]>
Date: Mon, 30 Mar 2009 17:27:16 -0400

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Mar 2009 14:36:39 -0700

I personally would agree with your viewpoint, with one caveat. The  
language of 2616 is clearly oriented towards TCP as a transport. In  
SCTP, you are doing the spirit of the recommendation with a different  
transport, which has a difference in effect - the requirement is not  
that the order of the responses must be the same as the order of the  
requests, but that the responses must be within the streams that the  
requests came in.

On Mar 30, 2009, at 2:27 PM, 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.
>
> requests and responses are sent back-to-back on a persistent  
> transport connection, the HTTP transactions are pipelined.
>
> 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
>
>

---

From: David Morris <[email-masked]>
Date: Mon, 30 Mar 2009 15:04:42 -0700 (PDT)

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

---

From: "Preethi Natarajan (prenatar)" <[email-masked]>
Date: Mon, 30 Mar 2009 18:39:13 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Morris
> Sent: Monday, March 30, 2009 3:05 PM
> To: [email-masked]
> Cc: [email-masked]
> 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

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Mar 2009 15:46:05 -0700

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.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 30 Mar 2009 17:05:03 -0700

On Mar 30, 2009, at 2:27 PM, Preethi Natarajan (prenatar) wrote:
> response). A server MUST send its responses to those requests in  
> the same order that the requests were received."
>

Yes; we already plan on making that clear in HTTPbis part 1.
This requirement should be just a statement that responses are
associated to requests by their order in an otherwise untagged
stream.  Other transport protocols might supply their own
mechanism for request-response association, or even extend HTTP
such that the request/response contains some form of matching ID.

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

I don't think you will need to worry about such conformance
except in the case where a TCP connection stream of pipelined
requests is being proxied to a set of SCTP streams.  In that case,
there is an implied expectation of ordering on the client regarding
state-changing requests that must be respected by the proxy.

The user agent needs to be in control of the order in which some
requests are handled by the origin server when there exists a
state-changing (unsafe) method in the stream because it is common
for a user agent to modify a resource and then immediately request
the resulting representation as it should appear after the modification
has been applied.  It would be annoying if that GET was reordered by
the SCTP proxy such that it was handled before the modification.

A transport change like SCTP is free to multiplex any sequence of
safe (GET/HEAD/OPTIONS/...) requests however it likes, assuming that it
has some way of re-associating the request-response pair, but it must
wait until each of the previous requests have received at least a
response status prior to initiating an unsafe request
(PUT/PATCH/DELETE/POST/...) from the same source.

I am somewhat surprised that your HTTP over SCTP spec allows channels
to be reused.  Is there a significant cost associated with channel
allocation?  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.  I was hoping that an SCTP channel could be handled
in a send-and-forget mode, since that is more efficient for servers
that aren't designed around event handlers.
Does the sctp_sendmsg/sctp_recvmsg API solve those problems?

....Roy

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Mar 2009 17:25:49 -0700

On Mar 30, 2009, at 5:05 PM, Roy T. Fielding wrote:

> I am somewhat surprised that your HTTP over SCTP spec allows  
> channels to be reused.  Is there a significant cost associated with  
> channel allocation?

At session startup, each end tells the other how many streams it wants  
to open, and either they agree on the lower number or one of them  
aborts the connection.

That's an argument for a Really Big Number :-)

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 30 Mar 2009 17:43:10 -0700

On Mar 30, 2009, at 5:25 PM, Fred Baker wrote:
>> channels to be reused.  Is there a significant cost associated  
>> with channel allocation?
>
> At session startup, each end tells the other how many streams it  
> wants to open, and either they agree on the lower number or one of  
> them aborts the connection.
>

I thought that they would only cause a limited pool size
(max open channels), but I see now that

RFC4960, sec 5.1.1:

    After the association is initialized, the valid outbound stream
    identifier range for either endpoint shall be 0 to min(local OS,
    remote MIS)-1.

effectively requires the stream identifiers to be reused.  Doh!

....Roy

---

From: "Preethi Natarajan (prenatar)" <[email-masked]>
Date: Mon, 30 Mar 2009 20:49:55 -0400

> From: Roy T. Fielding [mailto:[email-masked]] 
> Sent: Monday, March 30, 2009 5:05 PM
> To: Preethi Natarajan (prenatar)
> Cc: [email-masked]; Jonathan Leighton; Paul D. Amer; 
> Fred Baker (fred)
> 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