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

[Bruce Fitzsimons]

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