Re: Adding SCTP support

From: Pranav Desai <pranavadesai_at_gmail.com>
Date: Mon, 2 Jun 2008 23:58:26 -0700

On Mon, Jun 2, 2008 at 11:42 PM, Mark Nottingham <mnot_at_yahoo-inc.com> wrote:
> The use case that I (and many others, I think) am interested in is where
> you're doing
>
> client <---TCP---> proxy <----SCTP---> proxy <---TCP---> origin server
>

Hmm, thats interesting. I didn't think of it this way. I was looking
more towards the wireless networks (phones, PDAs, etc.). A custom
browser and SCTP may not be very acceptable or feasible at first on
these devices, because of lack of SCTP support in mobile platforms,
but with more and more mobile platforms moving towards linux, I think
an SCTP enabled webkit based browser might be feasible. Anyway, I was
thinking of a use case like this.

   client <--------- SCTP -----------> proxy <------------ TCP ------------> OS
                  lossy/slow n/w fast backends

Although, the use case you presented seems more feasible at this time.

> Assuming that the TCP hops are short, and the SCTP is a long haul (e.g.,
> from Australia to the US).
>
>
> On 03/06/2008, at 4:35 PM, Pranav Desai wrote:
>
>>
>>
>> On Sun, Jun 1, 2008 at 5:32 PM, Mark Nottingham <mnot_at_yahoo-inc.com>
>> wrote:
>> I'm very interested in this, and would be willing to help with the spec
>> work side of things. It's also been discussed on the HTTP mailing list
>> <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
>>
>> Cheers,
>>
>> Thanks you all for your responses. So as I expected its not as trivial as
>> changing the protocol type in squid.
>>
>> From the paper mentioned in this thread by Matt, it looks like we need to
>> have a mechanism to be able to handle multiple streams in parallel, without
>> which the advantage of using SCTP wouldn't be that much. I believe that
>> would be difficult in squid, due to the single process nature? What would be
>> the right way to go about achieving this ?
>>
>> But, in general, it seems like a proxy would be a perfect place to use
>> something like SCTP, especially where the origin server may not have SCTP
>> support. It also seems like the client (browser) would be critical in how
>> efficiently they can use the key features of SCTP, multi-streaming. So a
>> combination of a custom browser (modified firefox) and squid could have some
>> good advantage over TCP.
>>
>> -- Pranav
>>
>>
>>
>>
>> On 01/06/2008, at 12:50 PM, Adrian Chadd wrote:
>>
>> Hi,
>>
>> I've spoken to some SCTP related people about this before.
>> The trouble is:
>>
>> * NOone's fleshed out how HTTP over SCTP should look;
>> * Noone's fleshed out how servers should choose HTTP over TCP vs SCTP.
>>
>> They're the much more pressing questions.
>>
>>
>>
>> Adrian
>>
>> On Sat, May 31, 2008, Pranav Desai wrote:
>> Hello All,
>>
>> What would you suggest should be the way to include SCTP support in Squid
>> 3.0 ?
>>
>> My assumption here is that SCTP would be useful for clients (which
>> support SCTP) connecting using slow/lossy wireless type networks. My
>> goal is to experiment and compare the performance against TCP for
>> wireless networks.
>>
>> So, I started with that and was easily able to add a config option for
>> client-side and change the corresponding function
>> clientHttpConnectionsOpen() to set appropriate protocol type and it
>> worked just fine. But that would make it an SCTP only proxy.
>>
>> We could also open up another listening port for SCTP, so that we can
>> have both SCTP and TCP simultaneously, where the origin server side
>> will always be TCP.
>>
>> But I feel that I am missing something here. So, I would really
>> appreciate any suggestions or comments you may have.
>>
>> Thanks for your time.
>>
>> -- Pranav
>>
>> --
>> - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid
>> Support -
>> - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
>>
>> --
>> Mark Nottingham mnot_at_yahoo-inc.com
>>
>>
>>
>
> --
> Mark Nottingham mnot_at_yahoo-inc.com
>
>
>
Received on Tue Jun 03 2008 - 06:58:28 MDT

This archive was generated by hypermail 2.2.0 : Wed Jun 04 2008 - 12:00:02 MDT