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

Serge Aleynikov saleyn@REDACTED
Sat Oct 13 16:01:43 CEST 2007


Per Hedeland wrote:
> Bruce Fitzsimons <Bruce@REDACTED> wrote:
>>>   
>> 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.
> 
> Hm, I can't quite see how that relates to TCP vs SCTP. Presumably you're
> not actually referring to the situation in a network switch (i.e. layer
> 2 device), since the upper-layer protocol won't make a difference there?
> I can see how this phenomenon could occur with "naive" multiplexing of
> multiple "channels" on a single TCP session, like, um, the Erlang
> distribution does (though I can't see it happening with Erlang
> distribution since the "channels", i.e. inter-process messages, won't be
> blocked at the receiving end) - is that the connection?

I also think that Head-of-line blocking (HOLB) wiki description is not 
very representative in regards to TCP/SCTP.  The HOL means that if you 
have consecutive packets 1,2,3 sent from A to B, and packet 3 is lost, 
then B holds 1 and 2 until it gets 3 retransmitted, so that it would 
preserve the byte ordering.  In SCTP this may not be a problem because 
packet 3 could belong to a different stream.

> Of course this can be handled by per-channel flow control (like e.g. SSH
> does) when using TCP, but I guess this user-level complexity can be
> avoided by using SCTP instead.

Hmm, will the session-level per-channel flow control resolve the issue 
above?  At the transport (TCP) layer it would still have to guarantee 
the proper byte ordering, therefore forcing HOLB.

Serge



More information about the erlang-questions mailing list