Subject: [Tsvwg] sctp performance

From: Salvatore Loreto <[email-masked]>
Date: Thu, 7 Oct 2004 11:50:25 +0200 (CEST)

Hi all,
 
reading the experiments on SCTP performance 
 
LKSCTP 
http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm

OPENSS7
http://www.openss7.org/sctp_perf.html
 
If we ignore the gap underline between TCP and SCTP in LKSCTP, becose due to implementation problem ( and I think now the situation is better, isn't it? does someone have up to date results about?)
and use just the result underline on OPENSSS7
 
I've some questions/doubts and I'd like know you opinion about:
 
1) the test SCTP with 1 interface shows a substanzial equivalent to TCP.
Is it possible SCTP with 1 interface is TCP, or if you want if there is   not HoL block there are not difference between two protocols due to the same congestion algorithm.
 
2) SCTP with 2 interface has a better performance just for message size greater than 64-byte.
But SCTP was born for Signaling transport, and signaling messages are yes lager than 64-bye but not very large.
 
when in the experiment is used SOCK_SEQPACKET
3) the real start up with 1 or 2 interfaces are both worse than the Theoretical one. The strange is the reale one with 2 interfaces is worse than the reale one with just one interface.
4) similar considerations ( done above ) could be done also for the other phases . So SOCK_SEQPACKET seems not so good.

regards
sal

---------------------------------
Yahoo! Mail ti protegge gratis dalla posta indesiderata e dai virus!

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Oct 2004 06:11:29 -0600

Salvatore,

Performance tests on a clean network do not exercise SCTP's strong
points.  SCTP was not really intended to outperform TCP on a clean
network with a single interface: it was intended to outperform TCP on a
real network with noise, failures and reconfiguration.  If you look at
even single stream tests under noise SCTP rapidly outperforms TCP in
dirty networks.

The SOCK_SEQPACKET test deviation from theoretical is probably more of a
software glitch in bundling, Nagle'ing and Minshall'ing in the OpenSS7
stack more than a problem with the protocol (that was noted in the
results).

The SOCK_STREAM tests on a single interface did outperform TCP, however,
note that the tests saturated the network and both are running very
close to theoretical maximums.

The interesting thing about the OpenSS7 tests were the multiple
interface tests on SOCK_STREAM, that showed that max throughput was a
multiple of the number of available interfaces.  Once TCP saturates
a single interface it has nowhere else to go.  SCTP can load multiple
interfaces to saturation.

These were throughput tests.  Latency tests show SCTP has comparable
results to TCP (with slight improvements) on clean networks, and
SCTP exhibits significant reduced latencies to TCP under even as little
as 5% noise.  On distrupted networks (50% interface failure on a 1 or
2 second duty cycle) TCP stops and SCTP continues.

There are a lot of good papers out there testing more real environments
as well as NS-2 simulations that demonstrate the benefits of SCTP over
TCP for its original intended application, telephony signalling.  Search
on "SCTP Performance" and you can read for the better part of a day.

--brian

On Thu, 07 Oct 2004, Salvatore Loreto wrote:

>    [1]http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm
> 
>    OPENSS7
>    [2]http://www.openss7.org/sctp_perf.html
> 
> 
> 
>    If  we  ignore  the  gap  underline between  TCP  and  SCTP in LKSCTP,
>    becose due   to   implementation   problem   ( and  I  think  now  the
>    situation is  better,  isn't  it? does someone have up to date results
>    about?)
> 
>    Is  it  possible SCTP with 1 interface is TCP, or if you want if there
>    is    not HoL block there are not difference between two protocols due
>    to the same congestion algorithm.
> 
> 
> 
>    But  SCTP was born for Signaling transport, and signaling messages are
>    yes lager than 64-bye but not very large.
> 
> 
> 
>    3)  the  real  start up with 1 or 2 interfaces are both worse than the
>    Theoretical  one.  The  strange  is the reale one with 2 interfaces is
>    worse than the reale one with just one interface.
> 
>    4)  similar  considerations  ( done above ) could be done also for the
>    other phases . So SOCK_SEQPACKET seems not so good.
> 
> 
> 
> 
> 
>    regards
> 
>    sal
> 
> 
> 
> 
>      _________________________________________________________________
> 
>    [3]Yahoo!  Mail  ti  protegge  gratis  dalla  posta indesiderata e dai
>    virus!
> 
> References
> 
>    1. http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm
>    2. http://www.openss7.org/sctp_perf.html
>    3. http://it.rd.yahoo.com/mail/taglines/*http://it.mail.yahoo.com

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Pawel Hadam <[email-masked]>
Date: Thu, 07 Oct 2004 18:49:35 +0200

Hi

> http://www.openss7.org/sctp_perf.html

I am interested in a case with 2 interfaces.
How did they do the load-balancing between 2 interfaces?
It was on SCTP or application (iperf ???) level ???

Does anybody know?

Pawel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Oct 2004 20:06:09 -0600

Pawel,

The load balancing is performed in the SCTP implementation.  It's the same
algorithm that allowed us to acheive 20ms nominal fail-over times between
interfaces in lmco's testing.

--brian