[erlang-questions] SCTP support (was EPIPE and TCP sockets)

[G Bulmer]

Bruce

Thank you, that was a very helpful answer.

I understand the 'advertising' feature list for SCTP, but I've never  
appreciated the issue you explained.
I'd only skimmed http://tools.ietf.org/html/rfc3286, and I'd not  
noticed anything about 'heart-beating' until now either (9.1 and  
9.2e), so that was great!

I strongly agree that it's a bit early to deploy SCTP in an hostile  
environment, unless there are *critical* benefits that outweigh the  
risks (and you can manage the risks :-).

Anybody - On a related track, do all Erlang messages between two  
specific Erlang nodes go down one socket?
[I thought the response to my question would be out-of-order delivery  
being the killer SCTP feature, but maybe that isn't an issue].

Thanks again
Garry Bulmer

> Date: Sat, 13 Oct 2007 22:45:18 +1300
> From: Bruce Fitzsimons <Bruce@REDACTED>
> Subject: Re: [erlang-questions] SCTP support (was EPIPE and TCP
> 	sockets)
> To: G Bulmer <gbulmer@REDACTED>
> Cc: "Erlang-Questions \(E-mail\)" <erlang-questions@REDACTED>
> Message-ID: <471093AE.3060600@REDACTED>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> G Bulmer wrote:
>
>> Newbie question.
>>
>>
>>
>>> Date: Fri, 12 Oct 2007 12:29:41 +1300
>>> From: Bruce Fitzsimons <bruce@REDACTED>
>>> Subject: Re: [erlang-questions] EPIPE and TCP sockets
>>>
>>>
>>
>>
>>
>>> ... I'd still like to
>>> use the SCTP support in Erlang to demonstrate XMPP over SCTP and see
>>> what sort of improvements it might give, ...
>>>
>>>
>>
>> Is the "Erlang SCTP support" likely to give higher message
>> throughput, or is this really about reliability guarantees? Is this
>> OS sensitive, i.e. very much bound to the quality of SCTP
>> implementation for the underlying OS?
>>
>>
>>
> Throughput is unlikely to be a benefit; considering we have many years
> experience in TCP behaviour and tuning and not much at all with SCTP.
> SCTP is a more complex protocol, but does avoid several TCP corner  
> cases
> including head of line blocking
> http://en.wikipedia.org/wiki/Head-of-line_blocking.
>
> Given that it is most used in friendly environments, I think we are
> still to see what new DoS attacks SCTP could enable, but the TCP ones
> are fixed and thought was given to preventing new ones.
>
> I am most interested in SCTP to take advantage of the native  
> connection
> heart-beating, something commonly implemented in the application layer
> but not present as standard in XMPP. With the "standard" TCP  
> connection
> timeout at 2 hours the TX buffer can be filling on the sending host
> without the application being aware that they are not being delivered,
> and there is no way to tell what quantity of data was reliably  
> delivered
> when the connection is finally terminated (Tony's problem). This
> manifests in XMPP as messages being silently blackholed and presence
> information that is way out of date. This only occurs when the  
> recipient
> disappears rather than terminates the TCP connection but this is  
> fairly
> common on the Internet. (I'm quite likely to be corrected here, in my
> defense my Stevens is at work and the failure cases are subtle.) Most
> XMPP implementations reduce the timeout length but this can never be a
> complete solution.
>
> Regards,
> Bruce
>