SCTP has some other interesting problems with multiplexing large datagrams
- in particular it requires that the fragment sequence numbers (TSNs) for
each SCTP datagram be sequential.
That means that a typical SCTP implementation will transmit all the
fragments of a given datagram at least once before starting on the
fragments of any other datagram. In addition, a typical socket interface
to SCTP serializes the reception of datagrams as well. Once you have
started reading a datagram you cannot read anything else until that
datagram is finished.
This works really well if your datagrams are small, so that they consist of
a small number of fragments and are small enough to fit several in the
kernel level socket buffer. If either requirement is not met, SCTP will
serialize the datagram in much the same way as TCP.
As a consequence, an application layer multiplexing protocol like SPDY is a
practical necessity to gain the additional advantages of SCTP with a large
message oriented upper layer protocol like HTTP, the additional advantage
being non-serialization of small datagrams in the presence of packet loss.
SPDY and SCTP should be seen as complementary, rather than as independent
alternatives. That said the firewall / NAT problem with respect to SCTP is
serious enough that one should either use a variation of SCTP designed to
be layered over UDP, or something very similar, such that one effectively
has HTTP over SPDY over "SCTP" over UDP for optimal performance. HTTP over
SPDY over TCP is a major step in that direction, a solution *far* superior
to HTTP over SCTP or TCP alone.