sctp_present

Document Sample
sctp_present Powered By Docstoc
					Performance of SCTP
   (Stream Control
Transmission Protocol)


 Student: Elvis Pfützenreuter
 Advisor: Prof. Luis Fernando Friedrich, Ph.D
     Why do we need another
     transport protocol?
●   TCP: reliable stream of bytes
●   UDP: unreliable datagrams
●   No reliable atomic message transmission
●   No variable degrees of reliability (only all or nothing)
●   Several channels or streams in one connection

                     TCP        UDP      ???

                            IP / IPv6

                           Link layer
SCTP history
●   SIGTRAN comittee wanted a transport protocol for
    SS7
●   MDTP (Multinetwork Datagram Transmission
    Protocol): did what SIGTRAN wanted, but it ran
    over UDP
●   MDTP evolved until becoming SCTP that is a
    transport protocol


     MDTP               SCTP

      UDP                UDP               SCTP

    IP / IPv6          IP / IPv6          IP / IPv6
   Associations and streams
   ●   SCTP association: analogous to TCP conn.
   ●   Streams: unidirectional channels for message
       transmission (up to 2^16 per direction)
   ●   Number of streams negotiated at connection
       initiation
                                          Streams




Terminal                                       Terminal
    Atomic messages
●   Sent and received atomically (always at once)
●   Can be bigger than a datagram (if implementation
    allows)
●   Application may ignore message boundaries
●   Delivery order is obeyed only within each stream
    (avoids HOL Blocking)


        Msg #4    Msg #3        Msg #2      Msg #1


                           Fluxos
        Msg #3         Msg #2              Msg #1
     Wait msg#1                          lost
     retransmission
Partial reliability
●    ―urgent‖ messages
●    Messages with time to live (deadline)
●    What about unreliable messages?
●     PR-SCTP (Partial Reliability SCTP) extension:
     redefines time to live
●    All types may go through the same stream


     Msg #3          Msg #2 urgent           Msg #1

     Waits #1       Delivered as         lost
    retransm.        soon as it
                      arrives
       More SCTP details
       ●    No half-open state, immune to blind spoof and
            SYN flood
       ●    Checksum is 32 bits (CRC32c)
       ●    Congestion control exactly like TCP
       ●    Architecture of TLV structures instead of bitmaps
       ●    API BSD Sockets: TCP and UDP style


             Type          Length                Value



Type (8b)   Flags (8b)   Length (16b)      Valule – 32-bit aligned
Work objectives
 Find oportunities ofusing SCTP in place
  of TCP or UDP in preexisting application
  protocols
 Performance tests: raw data and with
  application protocols (HTTP, SMB, RTP)
 Offer examples of SCTP API Sockets
  usage
 Feedback to LK-SCTP maintainers
SCTP use cases
•



●   In place of TCP
    ●   Atomic messages
    ●   Multiple connections belonging to a single
        transaction
    ●   Better security
    ●   Multipath
●   In place of UDP
    ●   SCTP has no broad/multicast!
    ●   Some real-time multimedia apps.
        •  Performance SCTP x TCP
       ●    Implementations: SCTP and TCP present in
            standard Linux 2.6.9
       ●    Test validity issues
       ●    Latency and throughput tests with reliable
            messages
       ●    TCPM and UNIXM: application protocols for simple
            message separation in TCP e UNIX

Tests applied in these points

             TCPM
                                        TCPM application proto
       TCP              SCTP
                                Byte 0xEE     Payload      byte 0xFF
            IP / IPv6
Loopback - throughput
•

●   Message size is varied
●   TCP: performance well over SCTP (9x to
    4x). Causes:
    ●   CRC-32c (is NOT the bottleneck)
    ●   Message separation
    ●   Memory-to-memory data copies
    ●   Context switches
    ●   Unfair comparison
    ●   TLV overhead
●   TCPM: throughput about the same as
    UNIXM and SCTP
Loopback – latency
•



●   Message size is varied
●   Latency SCTP 2x worse than TCPM
●   Serialization of all latencies
●   Library lksctp-tools deemed NOT guilty
●   SCTP extra latency is inside the kernel
•   100Mbps
●   Message size is varied
●   SCTP throughput below TCP and TCPM
    (even 10x less for 10-byte message)
     ●   Problems with SCTP Chunk bundling
●   Difference gets narrower as the message
    size increases (1000 bytes or more)
●   SCTP latency 25% bigger than TCPM
●   All next texts use 500-byte messages
•   100Mbps, loss 0% to 10%
●   SCTP throughput better than TCPM for
    network losses >1%
●   SACK of SCTP worked well, but...
●   SCTP latency was bad for losses >1%
    ●   Minimum and initial RTOs set default too
        high (1000ms) but can be tuned
    ●   TCP-inherited congestion control
    ●   Tuned RTOs deliver same performance as
        TCP
    ●   Still needs more tests
•10Mbps
latency from 5ms to 300ms
●   SCTP throughput 15% less than TCPM
●   Throughput of both protocols fall and
    difference narrows as network latency
    increases
    ●   Cause: untuned reception buffer
●   TCPM latency equals SCTP (both follow
    RTT = inherent net latenc)
•10Mbps
latency 5ms to 300ms
loss 1%
●   SCTP throughput 27% less
●   SCTP latency 2x more than TCP
●   Both differences to TCP narrow as the
    network latency increases
    ●   Reception buffer not tuned
●   Default minimum RTO too high
1Mbps net latency 50ms
•

●   Net latency 50ms +/- 25ms with 50%
    correlation
●   1% packet duplication
●   Variable losses because of shaping
    1Mbps
●   No constant losses
●   SCTP throughput 8% less
●   Latency SCTP 9% more
    ●   Default Minimum RTO too high
●   Constant loss of 0,1%: no change
11Mbps wireless ad-hoc
•



●   Path with 2 segments
    ●   802.11 e Ethernet
●   Total throughput: 3Mbps
    ●   Wifi signal quality was bad, on purpose
●   SCTP throughput 25% less
●   SCTP latency 22% more
Two clients 100Mbps
•



●   ―Strong‖ clients against ―weak‖ (slow)
    server
●   Throughput: SCTP shared it equally by
    all clients and directions
    ●   TCP had problems, summed throughput
        was smaller
●   Latency with 2 clients
    ●   Increased 30% with SCTP, from 1-client
        latency. Increased only 15% in TCPM
    ●   Cause: SCTP overhead in slow server
Multipath 10/11Mbps
•



●   Tests if it works, not the performance
●   Primary path enabled/blocked every 10
    seconds
●   SCTP needed some tuning to work
    properly
    ●   path_max_retrans lowered from 5 to 1
Conclusions at this point
•

●   SCTP performance ―worse‖ than TCP,
    TCP still has the best raw throughput
    ●   SCTP migration only if other good reasons
        can be found
●   CRC-32c influence in latency less than
    expected
●   Minimum and default RTOs of 1000ms
    (too high)
●   Congestion control not suitable for
    constant loss channels
HTTP tests
•

●   Softwares: thttpd and httperf
●   Adaptation of HTTP to SCTP, using a
    pair of streams per file
    ●   Inspired from SSL adaptation to SCTP
●   Using several SCTP streams incresases
    performance
    ●   Small open/close connection overhead
    ●   Less HOL blocking
SMB tests
•


●   Softwares: Samba and smbclient
●   Simple replacement of TCP by SCTP
●   Performance increase was expected
●   Reality check: SCTP performance was
    (not much) below TCP, much like the raw
    performance tests
●   More elaborated software adaptation
    would be necessary to explore SCTP to
    its full potential
•   RTP tests
●   Software: POC version 0.3.7
●   MP3 over UDP
●   RFC 2250, RFC 3119, FEC
●   Partial reliability SCTP
    ●   Unordered delivery, finite time to live
    ●   PR—SCTP
●   SCTP increased resistance against
    network problems
●   Partial reliability demand application
    changes for full potential
Other tests published
•

●   KANG & FIELDS (2003)
    ●   Usage of several streams to increase
        throughput, much like our HTTP test
●   RAJAMANI et al. (2002)
    ●   KAME/BSD implementation
    ●   HTTP
●   Overall results agree with ours
●   Out of order (―urgent‖) messages to increase
    throughput
●   KANG & FIELDS ideas can not be used for
    preexisting applicaiton protocols based on TCP
Conclusions
•


●   SCTP delivers its promises
●   Near production quality
●   No showstopper problem in LK-SCTP
●   Is not a silver bullet
●   All detected problems are solvable in
    single time
●   Consistent advantages of using SCTP as
    transport for (HTTP, RTP)
THE END
•

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:12/9/2011
language:
pages:33