video streaming with the stream control transmission
play

Video Streaming with the Stream Control Transmission Protocol (SCTP) - PowerPoint PPT Presentation

Chair for Network Architectures and Services Department of Informatics Technische Universitt Mnchen Video Streaming with the Stream Control Transmission Protocol (SCTP) Lothar Braun, Andreas Mller Internet Protocol Stack The Internet


  1. Chair for Network Architectures and Services Department of Informatics Technische Universität München Video Streaming with the Stream Control Transmission Protocol (SCTP) Lothar Braun, Andreas Müller

  2. Internet Protocol Stack  The Internet Protocol Stack Session, Presentation, Application Application Layer UDP UDP TCP TCP SCTP Transport Layer IP Network Layer Network Interface Physical + Data Link Layer (Ethernet, PPP, …)  Why another transport layer protocol? 2

  3. Contents  Recap: UDP and TCP  Problems with UDP/TCP  Stream Control Transmission Protocol (SCTP)  Association setup / stream setup  Message types  Partial Reliability  Multi-Homing support  Congestion control  The Lab 3

  4. Contents Recap: UDP and TCP 4

  5. User Datagram Protocol (1)  Message oriented  Sending application writes a N byte message  Receiving application reads a N byte message  Unreliable  Lost packets will not be retransmitted  Unordered delivery  Packets may be re-ordered in the network Hello World World Hello Hello World Application Application UDP UDP IP IP Network Interface Network Interface 5

  6. User Datagram Protocol (2) Application address on a host 0 16 31 Source Port Destination Port Packet Length Checksum header Data ... Message Length: Message Header and Data  Barely more features than IP 6

  7. Transmission Control Protocol (1)  Connection/Stream oriented. Not message oriented World Hello World Hello Message boundaries are not preserved  Reliable transmission  Lost packets are retransmitted  Retransmission will be repeated until acknowledgment is received  In-order delivery  Segments n + 1, n + 2, n + 3, will be delivered after segment n  Congestion control  TCP tries to share bandwidth equally between all end-points 7

  8. Transmission Control Protocol (2)  Much information encoded into a single header  Ports  Application addressing  Sequence Numbers  Used to identify/acknowledge segments  Flags/Window  Signaling 31 0 16 Source Port Destination Port Sequence Number Acknowledgement Packet U A P R S F 4 bit TCP 6 bit header Window R C S S Y I header unused G K H T N N length Checksum Urgent Pointer Options Daten ... 8

  9. Problems  Certain applications observe problems due to UDP and TCP properties  TCP: Head-of-line blocking with video streaming  Frames 2,3,4 arrived but cannot be shown because frame 1 is missing  Video will stop until frame 1 is delivered  UDP:  Unordered delivery: Second image is delivered after first image  Packet loss: Certain frames get lost  low video/audio quality  No congestion control  Example: Internet-Telephony  Two types of traffic: • Signalling traffic: should be delivered reliable and in-order (TCP) • Voice traffic: should not suffer from head-of-line blocking (UDP)  Need to manage two sockets  SCTP can deal with these problems 9

  10. Contents SCTP Features 10

  11. SCTP Features at a glance  Connection and message oriented  SCTP builds an “association” between two peers  TCP connections  Association can contain multiple “streams”  Messages are sent over one of the streams  Partial reliability  “Lifetime” defined for each message • Retransmission of a message is performed during its lifetime  Messages can be delivered unreliable, full reliable or partial reliable  Multi-Homing  SCTP can use multiple IP addresses 11

  12. Contents SCTP Message Format 12

  13. SCTP Message Format  Common header format  12 byte header  In front of every SCTP message Ports address the application 0 16 31 Source Port Destination Port Packet Verification tag header Checksum Data („Chunks“) ... Checksum on the complete Random number which SCTP message: Common Identifies a given association: header and “chunks” Used to distinguish new from old connections 13

  14. SCTP Chunk Format  Data and signaling information is transported in chunks  One or more chunks in a SCTP message  Each chunk type has a special meaning: • INIT, INIT-ACK, COOKIE, COOKIE-ACK  Connection setup • DATA  Transports user data • SACK  Acknowledge Data  You will learn more about the different chunk types in the pre lab  Common chunk format 0 16 31 Chunk header Chunk Type Chunk Flags Chunk Length Chunk Data ...  Additional formats are defined for the different chunk types 14

  15. Contents SCTP Associations and Data Transmission 15

  16. Connection Setup  TCP connection setup Client Server SYN Create State for TCP connection: Store SYN/ client information ACK ACK Known Problem: TCP SYN-Flooding  16

  17. SYN Flodding SYN Client 1 SYN/ACK State: SYN Client 1 Client 2 SYN/ACK Client 2 Client 3 SYN Client 3 SYN/ACK  Clients send SYN-Packets but do not respond to SYN-ACK  Usually done by a single client that performs IP address spoofing  Works because only a single forged packet is necessary  Server has to store state until a TCP timeout occurs  Leads to resource exhaustion  Server cannot accept any more connections 17

  18. SCTP Association Setup  Solution to SYN-Flood problem: Cookies Client Server INIT Generate client specific cookie INIT-ACK Send Cookie  Forget client Cookie-Echo Check if cookie is valid  Create state only on valid Cookie-ACK cookie Association is established - You will learn more about this No SYN-floods with spoofed in the Pre-Lab addresses possible 18

  19. Data Transmission  Application data is transmitted in Data Chunks  A data chunk is associated to a stream (Stream Identifier S)  TSN (Transport Sequence Number)  Global Sequence Number  Similar to Sequence number in TCP  Necessary for retransmissions  Stream sequence number  Necessary for per-stream transmission reliability 19

  20. Transmission reliability (1)  TCP  Packets are transmitted fully reliable  retransmitted until received  Packets are delivered in-order to the application  Slow start and congestion avoidance for congestion control  UDP  Packets are transmitted fully unreliable  never retransmitted  No re-ordering  packet order may be changed at the receiver  No congestion control  SCTP can do both and more because of its streams 20

  21. Transmission reliability (2)  Why multiple streams?  Solves head of line blocking  No firewall issues (only one port for several streams)  Partial Reliability Extension (PR-SCTP) for different reliability levels  PR-SCTP  Allows to set a lifetime parameter for each message  Lifetime specifies how long the sender should try to retransmit a packet  Allows to create reliable and unreliable streams within an association Fully reliable streams (TCP like) Partial reliable stream unreliable stream (UDP like) 21

  22. Contents Multihoming 22

  23. Multi-Homing: Association setup  SCTP chooses one IP address at association setup  IP can be specified by user UMTS-IP Server IP SCTP Association DSL-IP DSL IP is used to setup the connection UMTS-IP is announced as backup IP at association setup 23

  24. Multi-Homing  Heartbeat messages are periodically sent to check link availability UMTS-IP Heartbeat Server IP Heartbeat SCTP Association DSL-IP 24

  25. Multi-Homing  Changes only occur when the default link is found to be broken  Is identified because of packet loss (data or heartbeat)  Consequence: SCTP will resume on the backup link No new association setup necessary UMTS-IP Server IP SCTP Association DSL-IP 25

  26. Real World Deployment  SCTP is cool -> but why don‘t we use it?  Why do we use HTTP over TCP for Video Streaming?  Why don‘t we use Multicast?  …  Because it just works „good enough“  Firewall and NAT issues  Most home routers simply can‘t translate SCTP  Implementations  No native Windows support (only userspace lib)  BUT: mandatory for some newly developed protocols such as IPFIX 26

  27. Contents The Lab 27

  28. The Lab  Pre-Lab  Get to known SCTP in detail  Learn how things work • How to setup SCTP connections • How streams are used • What kind of SCTP chunks you have and what their purpose is  Lab – Part 1  Observe SCTP traffic on the wire  Use “Wireshark” to observe the traffic from an unknown SCTP application  Lab – Part 2  Build a SCTP video streaming application • Program an controller that allows to start, stop, pause, forward, rewind videos • Stream videos over a lossy network link – “See” and “hear” the quality differences when streaming over SCTP compared to streaming over UDP and TCP 28

  29. Contributions to the lab  The SCTP Lab was set up in summer term 2010 (SS 2010).  Students  Carl Denis  Alexandra Simon  Supervisors  Lothar Braun  Andreas Müller  You are invited to contribute as well by giving us comments and suggestions for improvement! 29

  30. Questions? 30

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend