1 / 171

Tutorial SCTP – Stream Control Transmission Protocol

Prof. Paul Amer Prof. Phillip Conrad CIS Department. Protocol · Engineering · Laboratory. Tutorial SCTP – Stream Control Transmission Protocol. Randall Stewart. Who are We?. “An Extension to TCP: Partial Order Service,” RFC1693, Nov 94 “Transport Layer Protocols: Survey and Tutorial,”

zion
Download Presentation

Tutorial SCTP – Stream Control Transmission Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Prof. Paul AmerProf. Phillip Conrad CIS Department Protocol · Engineering · Laboratory TutorialSCTP – Stream Control Transmission Protocol Randall Stewart

  2. Who are We? “An Extension to TCP: Partial Order Service,” RFC1693, Nov 94 “Transport Layer Protocols: Survey and Tutorial,” ACM Computing Surveys, 31(4), Dec 99 “SCTP”

  3. Outline • The transport layer • Limitations of TCP and UDP for new applications • Innovative transport services • SCTP – Stream Control Transmission Protocol (RFC2960)

  4. Acronyms • PMTU – Path Maximum Transfer Unit • SSN – Stream Sequence Number • SID – Stream indentifier • MDTP – Multiple-network Datagram Transmission Protocol • AAA – Authentication, Authorization, and Accounting • TSN - Transmission Sequence Number • TCB – Transmission Control Block

  5. Where does SCTP fit? (From Stewart/Xie)

  6. A Brief History

  7. Transport UDP TCP SCTP DCCP UDP lite UDP TCP SCTP DCCP UDP lite IP IP IP IP IP IP IP CHAOS ! Innovative Transport Protocols application application

  8. UDP Application • Reliable • No loss • No duplicates • No corrupted data • Order preserved • Flow control • Congestion control • Connection-oriented TCP “transport” services needed to enhance UDP UDP - Unreliable, no flow or congestion control, connectionless 25 years of experience! How to design a new application ? Current environment: On top of TCP Application

  9. Designing a new application Research: On top of “ideal” transport protocol Application menu of transport protocols/services TCP Transport Layer SCTP UDP

  10. Innovative Transport Services

  11. Services/Features SCTP TCP UDP Connection-oriented yes yes no Full duplex yes yes yes Reliable data transfer yes yes no Partial-reliable data transfer proposed no no Flow control yes yes no TCP-friendly congestion control yes yes no ECN capable yes yes no Ordered data delivery yes yes no Unordered data delivery yes no yes Uses selective ACKs yes optional no Path MTU discovery yes yes no Application PDU fragmentation yes yes no Application PDU bundling yes yes no Preserves application PDU boundaries yes no yes Multistreaming yes no no Multihoming yes no no Protection against SYN flooding attack yes no n/a Allows half-closed connections no yes n/a Reachability check yes yes no Pseudo-header for checksum no (uses vtags) yes yes Time wait state for vtags for 4-tuple n/a

  12. TCP SCTP A1 B1 ISP ISP Internet A2 B2 ISP ISP SCTP Multihoming Key Research Problems: • fault tolerance • load sharing (concurrent transfer) Why important? - multihoming is just now happening on wide scale

  13. Multi-Homing port Application 132 (IANA) SCTP IP addresses ... IP Link ... ... Physical ... failover for “persistent on-the-move” sessions changeover for load balancing

  14. IP B2 IP B1 IP A1 IP B3 IP A2 IP network SCTP Multi-Homing • Multiple src/dest ip addresses • Path concept • Use of different physical paths not guaranteed • Peer reachability and path status are monitored (heartbeat) • One selectable default path • Parameters per path (cwnd, RTT, RTO, PRL) Can multihoming provide resistance to traffic analysis?

  15. Multi-homing with mobility TCP: connection defined bysocket pair; if IP addresseschange, must re-establishconnection SCTP: multi-homing supportedcan maintain “persistent on-the-move session”

  16. Application Striping vs CMT Bulk transfer striping application (manages n associations) Bulk transfer application (1 CMT-enabled association) application layer … SCTP-CMT SCTP1 SCTP2 SCTPn … (distributes data) transport layer … new data sent to dest1 new data sent to dest2 new data sent to destn … new data sent to dest1 new data sent to dest2 new data sent to destn …

  17. Multi-streaming voice video tactical info (e.g., gps, supply levels) images (e.g., maps, radar) Issues: synchronization, congestion control, flow control

  18. Multistreaming sender app receiver app s2 s1 s4 s3 s3 s4 s1 s2 multistreaming transport IP DLL PHY

  19. Multi-streaming with priorities • Reconnaissance Mapping • image – low priority stream • region of interest – high priority stream

  20. Head-of-the-line Blocking • TCP provides a single data stream • When a segment is lost, subsequent segments must wait to be processed. • Problem for some applications (telephony) • SCTP provides multiple independent streams per association.

  21. Head-of-Line Blocking in TCP S R’s App R 1 2 ACK 2 3 1 4 ACK 3 2 5 6 ACK 3 ACK 3 PDU 3 is blocking the head of the line.

  22. Head-of-Line Blocking in SCTP (all ordered streams) S R App Layer Transport Layer App Layer TSNs SID :SSN SID :SSN 1:1 3:1 ACK 2 1:1, 3:1 1,2 1:1, 3:1 1:2 1:2 3 undelivered 3:2 1:3 2:1 3:2, 1:3, 2:1 ACK 2 3:2,2:1 4,5,6 1:4 2:2 1:4, 2:2, 3:3 3:3 ACK 2 2:2, 3:3 7,8,9 NOTE: An SCTP ACK a cum ack based onTSN.

  23. On Streams • Streams by definition are ordered • Unordered data may be sent in a stream (U bit = 1) • Sequence number is ignored for U = 1 • Unordered messages should be processed first • Unordered messages may be used for “out-of-band” signaling, as in telnet.

  24. Head-of-Line Blocking in SCTP S R (stream 1 unordered) App Layer Transport Layer App Layer TSNs SID :SSN SID :SSN 1:a 3:1 ACK 2 3:1,1:a 1,2 3:1,1:a 1:b 1:b 3 Only blocked message 1:c 3:2 2:1 3:2, 2:1,1:c ACK 2 4,5,6 3:2,2:1,1:c 1:d 2:2 2:2, 3:4,1:d 3:3 ACK 2 2:2, 3:3,1:d 7,8,9 Letters show unordered chunks w/in a stream. U bit is set & SSN is ignored.

  25. 1. create A 3. create B … 4. create C 2. modify A 4. create C 3. create B 3. create B 1. create A 2. modify A 4. create C 2. modify A 1. create A transport transport Unordered / Partial Order “A create event on object A must be communicated before a modify event on A. However, the order to process create events on objects B and C is unimportant. If the create event on A is not delivered, we must suspend processing the modify on A. However, we are completely free to process the create event on B & C” “ Designing Communications Software For Tactical Wireless Networks,” by Thomas McVittie

  26. 50 10 9 8 7 6 5 4 3 2 1 … 10 9 8 50 5 3 1 acceptable  3 frames/sec … 9 7 1 50 10 5 3 … unacceptable < 3 frames/sec retransmissions Controlled / partial reliability 10 second video 5 frames/sec

  27. Higher security • avoid denial-of-service attacks, mid-stream attacks V: Verification tag I: Initiate tag closed A B t=0 INIT (V=0) (I=TagA) cookie wait INIT–ACK (V=TagA) (I=TagB) (StateCookie) closed 1RTT COOKIE–ECHO (V=TagB) (StateCookie) cookie echoed COOKIE–ACK (V=TagA) 2RTT estab’d data (V=TagB) established

  28. … left 30º 20mph stop Reliable & time critical • Commands to robot • must be reliable AND delivered within a bounded delay • Mechanisms • Send multiple copies (ie “retransmit before loss” to increase probability of receipt) • Send multiple copies out different interfaces (assuming multihoming) • Use FEC unmanned vehicle

  29. “Undo” or “Expire” Application GPS transport transport

  30. SCTP – History • Sponsored by IETF Transport Working Group (TSVWG) as a general purpose transport protocol alternative to TCP and UDP • Proposed Standard - RFC2960 • Supported by industry (bakeoffs) • Munich (June 2000) – 12 companies • Research Triangle Park (October 2000) – 22 companies • Sophia Antipolis (April 2001) – 19 companies ADAX - Cisco - Compaq - Data Connection - DataKinetics - Ericsson -Hewlett Packard - Hughes Software - IBM - Motorola - Nokia - Open SS7 - Performance Technologies - RadiSys - Siemens - Sun Microsystems - Telesoft Technologies - Toshiba - Ulticom • San Jose (February 2002) – “Connectathon 2002” • Implementations: AIX, FreeBSD, Linux, QNX, Solaris, True64, Windows, Sony PlayStation II, …

  31. Interoperability Workshops Bakeoffs Date Attend Origins: Public Telephone Network SignalingSS7 over IP (IETF Sigtran working group) Current home: IETF TSVWG(Transport Services Working Group) • IETF recognizes broader scope • Proposed Standard - RFC2960 Supported by industry: • Participation in Bakeoffs: ADAX - Cisco – HP/Compaq - Data Connection - DataKinetics - Ericsson - Hughes Software - IBM - Motorola – Netbricks - Nokia - Open SS7 - Performance Technologies - RadiSys - Siemens – Spider - Sun Microsystems - Telesoft Technologies - Toshiba - Ulticom -Wipro • Implementations: AIX, FreeBSD, Linux, QNX, Solaris, True64, IOS (Cisco Routers), Sony PlayStation II, Mac OS, Windows, more… U of Delaware 6/03 11

  32. Summary of SCTP Features • Multi-homing • failover for persistent connections • changeover for load balancing • Multi-streaming • Partial order, and unordered delivery • Better security • Controlled reliability (extension) • Compatible with new Explicit Congestion Notification (ECN)

  33. Research Project I:Improving FTP Using SCTP Multistreaming

  34. FTP server File Transfer Protocol control connection FTP client data connection n+1 TCP connections

  35. FTP over TCP Client Server PORT 200 NLST SYN SYN-ACK ACK 150 DATA FIN 226 FIN-ACK PORT ACK 200 SIZE 213 RETR SYN SYN-ACK ACK 150 DATA FIN 226

  36. FTP Variants: Timing Diagrams Client Server PORT 200 NLST SYN Redundant round trips SYN-ACK ACK 150 NAME LIST FIN FIN-ACK 226 ACK PORT 200 SIZE 213 RETR SYN SYN-ACK ACK Classic FTP over TCP 150 DATA FIN FIN-ACK 226 ACK

  37. Using multistreaming in FTP FTP server FTP client control stream data stream 1 SCTP association

  38. FTP over multistreamed SCTP with command pipelining FTP over multistreamed SCTP Client Server Client Server NLST NLST 150 150 DATA DATA 226 226 SIZE SIZE SIZE 213 213 RETR RETR 213 150 RETR 150 DATA DATA 226 226 FTP over TCP Client Server PORT 200 NLST SYN SYN-ACK ACK 150 DATA FIN 226 FIN-ACK PORT ACK 200 SIZE 213 RETR SYN SYN-ACK ACK 150 DATA FIN 226

  39. FTP Variants: Timing Diagrams Client Server Client Server stream 0 stream 0 NLST NLST stream 0 stream 0 150 150 stream 1 stream 1 Name List Name List stream 0 stream 0 226 226 stream 0 stream 0 SIZE SIZE stream 0 stream 0 stream 0 SIZE 213 stream 0 213 stream 0 stream 0 RETR 213 RETR stream 0 stream 0 stream 0 RETR 150 150 stream 1 stream 1 DATA DATA stream 0 stream 0 226 226 FTP over multistreamed SCTP FTP over multistreamed SCTP with command pipelining

  40. bandwidth = BW delay = D FTP client Traffic shaper FTP server bandwidth = BW delay = D Experimental Setup Bandwidth-Delay Configurations: • 1Mbps-35ms : US end-to-end coast • 256Kbps-125ms : Satellite communication • 3Mbps-1ms : UAV communication • Loss probability: {0, .01, .03, .06, .10} • Loss probability distribution: Uniform • File sizes: {10K, 50K, 200K, 500K, 1M} • Number of files transferred: {10, 100}

  41. configuration: 1Mbps - 35ms

  42. bandwidth = BW delay = D FTP client Traffic shaper FTP server bandwidth = BW delay = D Experimental Setup Bandwidth-Delay Configurations: • 1Mbps-35ms : US end-to-end coast • 256Kbps-125ms : Satellite communication • 3Mbps-1ms : UAV communication • Loss probability: {0, .01, .03, .06, .10} • Loss probability distribution: Uniform • File sizes: {10K, 50K, 200K, 500K, 1M} • Number of files transferred: {10, 100}

  43. configuration: 256Kbps - 125ms

  44. configuration: 256Kbps - 125ms

  45. bandwidth = BW delay = D FTP client Traffic shaper FTP server bandwidth = BW delay = D Experimental Setup Bandwidth-Delay Configurations: • 1Mbps-35ms : US end-to-end coast • 256Kbps-125ms : Satellite communication • 3Mbps-1ms : UAV communication • Loss probability: {0, .01, .03, .06, .10} • Loss probability distribution: Uniform • File sizes: {10K, 50K, 200K, 500K, 1M} • Number of files transferred: {10, 100}

  46. End-to-End configuration: BW = 1Mbps, RTT = 70ms

  47. Results FTP over SCTP with multistreaming/pipelining • dramatically reduces end-to-end latency in multiple file transfers, and in a TCP-friendly manner • reduces the server load (by decreasing the number of connections) • reduces the network load • maintains simplicity at the application

  48. Comments ? Thank you

  49. Extra slides

  50. Path1 A1 B1 Host A Host B Network A2 B2 Path2 Example Architecture

More Related