You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Preethi Natarajan <pr...@gmail.com> on 2009/04/01 01:34:53 UTC
HTTP over SCTP
Hello folks,
We are trying to adapt HTTP to work over SCTP streams
(http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01). Since this
proposal was received warmly at the httpbis WG, we are contemplating on a
more formal specification of HTTP over SCTP.
The current HTTP over SCTP design exploits SCTP streams to avoid
head-of-line blocking. SCTP also offers other services unavailable in TCP
such as unordered delivery, partially reliable transmission, message based
transfer, multihoming support, more secure connection establishment with a
cookie mechanism and so on. We plan on adapting our design proposal to
leverage some/all of these SCTP services in the future.
We implemented HTTP over SCTP streams in Apache and Firefox. Experiments
show significant improvements to end user performance in networks with high
latency and/or lossy paths. (I can point you to relevant material if you are
interested in knowing more.)
We are interested in submitting our code changes to APR and httpd. We'd very
much appreciate guidance from httpd and APR developers on our mods and the
submission process.
Thanks!
Preethi
RE: HTTP over SCTP
Posted by le...@mail.eecis.udel.edu.
Just wanted to add that the ability to open an SCTP socket was added to
APR in late 2002, but without access to the sctp_sendmsg() and
sctp_recvmsg() APIs you can't take advantage of most of what SCTP has to
offer. Ideally we'd like to take an approach similar to what we're doing
in NSPR, and introduce something like apr_sctp_sendmsg() and
apr_sctp_recvmsg() as well as some SCTP related socket options.
- Jon
>> -----Original Message-----
>> From: Paul Querna [mailto:paul@querna.org]
>> Sent: Tuesday, March 31, 2009 4:54 PM
>> To: dev@httpd.apache.org
>> Cc: dev@apr.apache.org; Jonathan Leighton; Preethi Natarajan
>> (prenatar)
>> Subject: Re: HTTP over SCTP
>>
>>
>> Please post the patches, preferablly against trunk:
>> <http://httpd.apache.org/dev/patches.html>
>>
>> Once we see the patches we will be in a much better position
>> to give feedback,
>>
>
> Paul,
>
> Sometime ago, we were directed to do the same. You can find a report (and
> patch) here -- https://issues.apache.org/bugzilla/show_bug.cgi?id=37202.
>
> Breifly, the mods to httpd/APR are:
> - new Listen directive to include the transport information (I believe
> this
> piece created some discussion and we didn't arrive at any conclusion).
> - changes to configure files to detect sendmsg and recvmsg in the system
> to
> send/recv on specific SCTP streams.
>
> We would also like to explore the possibility of introducing new send and
> recv APIs that can have the SCTP stream ID as another argument -- kind of
> wrappers for sctp_sendmsg and sctp_recvmsg.
>
> Thanks,
> Preethi
>
>
>
RE: HTTP over SCTP
Posted by Preethi Natarajan <pr...@gmail.com>.
> -----Original Message-----
> From: Paul Querna [mailto:paul@querna.org]
> Sent: Tuesday, March 31, 2009 4:54 PM
> To: dev@httpd.apache.org
> Cc: dev@apr.apache.org; Jonathan Leighton; Preethi Natarajan
> (prenatar)
> Subject: Re: HTTP over SCTP
>
>
> Please post the patches, preferablly against trunk:
> <http://httpd.apache.org/dev/patches.html>
>
> Once we see the patches we will be in a much better position
> to give feedback,
>
Paul,
Sometime ago, we were directed to do the same. You can find a report (and
patch) here -- https://issues.apache.org/bugzilla/show_bug.cgi?id=37202.
Breifly, the mods to httpd/APR are:
- new Listen directive to include the transport information (I believe this
piece created some discussion and we didn't arrive at any conclusion).
- changes to configure files to detect sendmsg and recvmsg in the system to
send/recv on specific SCTP streams.
We would also like to explore the possibility of introducing new send and
recv APIs that can have the SCTP stream ID as another argument -- kind of
wrappers for sctp_sendmsg and sctp_recvmsg.
Thanks,
Preethi
RE: HTTP over SCTP
Posted by Preethi Natarajan <pr...@gmail.com>.
> -----Original Message-----
> From: Paul Querna [mailto:paul@querna.org]
> Sent: Tuesday, March 31, 2009 4:54 PM
> To: dev@httpd.apache.org
> Cc: dev@apr.apache.org; Jonathan Leighton; Preethi Natarajan
> (prenatar)
> Subject: Re: HTTP over SCTP
>
>
> Please post the patches, preferablly against trunk:
> <http://httpd.apache.org/dev/patches.html>
>
> Once we see the patches we will be in a much better position
> to give feedback,
>
Paul,
Sometime ago, we were directed to do the same. You can find a report (and
patch) here -- https://issues.apache.org/bugzilla/show_bug.cgi?id=37202.
Breifly, the mods to httpd/APR are:
- new Listen directive to include the transport information (I believe this
piece created some discussion and we didn't arrive at any conclusion).
- changes to configure files to detect sendmsg and recvmsg in the system to
send/recv on specific SCTP streams.
We would also like to explore the possibility of introducing new send and
recv APIs that can have the SCTP stream ID as another argument -- kind of
wrappers for sctp_sendmsg and sctp_recvmsg.
Thanks,
Preethi
Re: HTTP over SCTP
Posted by Paul Querna <pa...@querna.org>.
On Wed, Apr 1, 2009 at 1:34 AM, Preethi Natarajan <pr...@gmail.com> wrote:
> Hello folks,
>
> We are trying to adapt HTTP to work over SCTP streams
> (http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01). Since this
> proposal was received warmly at the httpbis WG, we are contemplating on a
> more formal specification of HTTP over SCTP.
>
> The current HTTP over SCTP design exploits SCTP streams to avoid
> head-of-line blocking. SCTP also offers other services unavailable in TCP
> such as unordered delivery, partially reliable transmission, message based
> transfer, multihoming support, more secure connection establishment with a
> cookie mechanism and so on. We plan on adapting our design proposal to
> leverage some/all of these SCTP services in the future.
>
> We implemented HTTP over SCTP streams in Apache and Firefox. Experiments
> show significant improvements to end user performance in networks with high
> latency and/or lossy paths. (I can point you to relevant material if you are
> interested in knowing more.)
>
> We are interested in submitting our code changes to APR and httpd. We'd very
> much appreciate guidance from httpd and APR developers on our mods and the
> submission process.
Please post the patches, preferablly against trunk:
<http://httpd.apache.org/dev/patches.html>
Once we see the patches we will be in a much better position to give feedback,
Thanks,
Paul
Re: HTTP over SCTP
Posted by Paul Querna <pa...@querna.org>.
On Wed, Apr 1, 2009 at 1:34 AM, Preethi Natarajan <pr...@gmail.com> wrote:
> Hello folks,
>
> We are trying to adapt HTTP to work over SCTP streams
> (http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01). Since this
> proposal was received warmly at the httpbis WG, we are contemplating on a
> more formal specification of HTTP over SCTP.
>
> The current HTTP over SCTP design exploits SCTP streams to avoid
> head-of-line blocking. SCTP also offers other services unavailable in TCP
> such as unordered delivery, partially reliable transmission, message based
> transfer, multihoming support, more secure connection establishment with a
> cookie mechanism and so on. We plan on adapting our design proposal to
> leverage some/all of these SCTP services in the future.
>
> We implemented HTTP over SCTP streams in Apache and Firefox. Experiments
> show significant improvements to end user performance in networks with high
> latency and/or lossy paths. (I can point you to relevant material if you are
> interested in knowing more.)
>
> We are interested in submitting our code changes to APR and httpd. We'd very
> much appreciate guidance from httpd and APR developers on our mods and the
> submission process.
Please post the patches, preferablly against trunk:
<http://httpd.apache.org/dev/patches.html>
Once we see the patches we will be in a much better position to give feedback,
Thanks,
Paul