1 / 34

NIS 290 – Chapter 2

NIS 290 – Chapter 2. RTP. Introduction Overview of RTP RTP Packets RTCP (RTP Control Protocol) RTP Payload Format (RTP Packetization). Introduction – OSI Model and protocol environment. Layer 1&2 – not important Layer 3 – Internet Protocol IP Layer 4 – UDP or TCP

tara-pickett
Télécharger la présentation

NIS 290 – Chapter 2

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. NIS 290 – Chapter 2

  2. RTP • Introduction • Overview of RTP • RTP Packets • RTCP (RTP Control Protocol) • RTP Payload Format (RTP Packetization)

  3. Introduction – OSI Model andprotocol environment • Layer 1&2 – not important • Layer 3 – Internet Protocol IP • Layer 4 – UDP or TCP • Application Layer Transport - RTP • provides transparent transfer of data between end users

  4. TCP vs. UDP • TCP features: • applications on networked hosts create a connection one to another • guarantees reliable and in-order delivery of sender to receiver data • sequence numbers for ordering received TCP segments and detecting duplicate data • checksums for segment error detection acknowledgements and timers for detecting and adjusting to loss or delay • retransmission and timeout mechanisms for error control • unpredictable delay characteristics • Hence: not suitable for real-time communication

  5. TCP vs. UDP – Cont. • UDP features: • simple, unreliable datagram transport service • does not provide reliability and ordering guarantees • datagrams may arrive out of order or go missing without notice • checksum for detecting packages containing bit errors • faster and more efficient for many lightweight or time-sensitive purposes • obvious choice for real-time video transmission

  6. RTP Overview • RTP is the Internet-standard protocol for the transport of real-time data, including audio and video. It can be used for media-ondemand as well as interactive services such as Internet telephony. RTP consists of a data and a control part. The latter is called RTCP (RTP Control Protocol). • Reference: RFC 3550, July 2003http://www.ietf.org/rfc/rfc3550.txt

  7. RTP Overview – Cont. • The data part of RTP is a thin protocol providing support for applications with real-time properties such as continuous media (e.g., audio and video), including timing reconstruction, loss detection, security and content identification. • RTCP provides support for real-time conferencing of groups of any size within an internet. It offers quality-of-service feedback from receivers to the multicast group as well as support for the synchronization of different media streams.

  8. General Scenario • One-to-one • One-to-many • Many-to-many • Local transmission (access within one machine) • RTP packets • RTCP (Sender and Receiver Reports)

  9. RTP Packet • Consist of and RTP header, optional payload headers and the payload itself • RTP overhead = 12 bytes • IP+UDP+RTP overhead = 20+8+12 = 40 bytes • It is advisable to keep coded slice sizes as close to, but never bigger than, the MTU size (largest size of a packet that can be transmitted without being split/recombined on the transport and network layer), because: • 1. It optimizes the payload/header overhead relationship • 2. Minimizes the loss probability of a (fragmented) coded slice due to the loss of a single fragment on the network/transport layer and the resulting discarding of all other fragments belonging to the coded slice • MTU sizes: ~1500 bytes for wireline IP links (max. size of an Ethernet packet), ~100 bytes in wireless environments

  10. RTP Packets Example • DVD quality video transmission: 30 frames/s, 720x480 resolution, 3 bytes per pixel • 31,104,000 bytes/s raw rate • 311,040 bytes/s compressed data rate (100x compression) • MTU = 1500 bytes: 311,040/1460 = 213 packets/s -> 319,500 bytes/s (required throughput including overhead) • MTU = 100 bytes: 311,040/60 = 5184 packets/s -> 518,400 bytes/s (required throughput)

  11. RTP Packets – Cont. • RTP header contains the following: sequence number (used for packet-loss detection), timestamp (timing information, synchronization of media streams), payload type (identifies the media codec of the payload), marker bit (detecting the end of a group of related packets), source identifiers (contributing and synchronizing)

  12. RTP Packet Header

  13. Real-Time Control Protocol • The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP. It is recommended that the fraction of the session bandwidth allocated to the RTCP is 5%. The primary function of this protocol is to provide feedback on the quality of the Data distribution.

  14. RTCP Packets • SR – sender report, for transmission and reception statistics from participants that are active senders • RR - Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources • SDES - Source description items, including CNAME (Canonical Name – RTP source identifier) • BYE - Indicates end of participation • APP - Application specific functions

  15. Feedback in RTCP Sender and Receiver Reports (SR & RR) • Timestamps allowing to calculate the Round-Trip Time RTT = T4-T3+T2-T1 • Packet counts • Inter-arrival jitter (variation in delay) • Fraction of packets lost, cumulative number of packet lost • Number of packets expected to have been received • Available bandwidth estimation (back-toback packet sending)

  16. Feedback in RTCP Using the SR and RR information we can obtain the following measurements: • Packet loss rate over the interval between two reception reports. It is the difference in the cumulative number of packets lost (calculated over a given interval) • Number of packets expected during the interval – it is the difference in the extended last sequence numbers received • Packet loss fraction over the interval - the ratio of the two above. This ratio should equal the fraction lost field if the two reports are consecutive, but otherwise it may not. • Loss rate per second - can be obtained by dividing the loss fraction by the difference in NTP timestamps, expressed in seconds.

  17. Feedback RTCP – Cont. • Number of packets received is the number of packets expected minus the number lost. • Statistical validity of any loss estimates – can be judged using the number of packets expected. For example, 1 out of 5 packets lost has a lower significance than 200 out of 1000. • Apparent throughput available to one receiver – it is the number of packets received by a particular receiver times the average payload size (or the corresponding packet size), assuming that packet loss is independent of packet size • interarrival jitter - provides a short-term measure of network congestion, it tracks transient congestion. The jitter measure may indicate congestion before it leads to packet loss.

  18. RTCP – Compound Packet • All RTCP packets must be sent in a compound packet of at least two individual packets (each periodically transmitted compound RTCP packet must include a report packet as well as the SDES CNAME)

  19. Why IPv6? • Huge Address Space • Address Renumbering/Hierarchy/Mobility • Multicast/Anycast • Security (IPsec, Source Route) • Flow Labels • High Performance Design • Jumbograms (packets > 64 KB) http://www.go6.net

  20. A whole lot of addresses • IPv4 supports 4.2 billion adresses, which is inadequate for giving even ONE address to every living person. • IPv6 will provide 340 unidecillion addresses. That’s 340 with 36 zeros or 3.4 X 10^38. This will give each person on the planet 5 sextillion addresses. This will provide a virtually inexhaustible supply of IP addresses for the future. (assuming 6.5 billion people today).

  21. Why not IPv6? • Network Address Translation (NAT) • Application Level Gateways (ALG) • Classless InterDomain Routing (CIDR) • DHCP for IPv4 • IPsec for IPv4 • Mobility for IPv4 • Multiprotocol Label Switching (MPLS) • Jumbograms? (Try > 1500 Bytes!)

  22. Why not IPv6? http://2002:09fe:fdfc:2a41: fe2108c9e133fe01/index.html

  23. What’s So Bad About NAT? • Loss of Transparency • No Inbound Services • Some Apps Won’t Work (e.g. IPsec, WINS) • Nat Breaks the end-to end model Address Rewriting Local Intranet 10.xx, 192.168.xx Globally Routed Internet NAT • Performance Limitations • Redundancy is Hard • Nesting is Hard • Merger is Hard

  24. Flow Label Hdr Len Identification Flg Fragment Offset Header Checksum Options... shaded fields have no equivalent in the other version IPv6 header is twice as long (40 bytes) as IPv4 header without options (20 bytes) IPv6 Header compared to IPv4 Header Ver. Traffic Class Flow Label Ver. Hdr Len Type of Service Total Length Payload Length Next Header Hop Limit Identification Flg Fragment Offset Source Address Time to Live Protocol Header Checksum Source Address Destination Address Options... Destination Address

  25. Chain of Pointers Formed by the Next Header Field

  26. Type of IPv6 Addresses unicast: for one-to-one communication multicast: for one-to-many communication anycast: for one-to-nearest communication U M M M A A A

  27. Types of IPv6 Addresses • Like IPv4… • Unicast • An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. • Multicast • An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. • Anycast: • An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance). Specified in the the v6 address architecture RFC.

  28. Addressing formats • •16-bit hexadecimal numbers • Numbers are separated by (:) • Hex numbers are not case sensitive • Abbreviations are possible Leading zeros in contiguous block could be represented by (::) Example: 2001:0db8:0000:130F:0000:0000:087C:140B 2001:0db8:0:130F::87C:140B Double colon only appears once in the address Representation

  29. Addressing formats • “preferred” form: 1080:0:FF:0:8:800:200C:417A • compressed form: FF01:0:0:0:0:0:0:43 becomes FF01::43 • IPv4-embedded: 0:0:0:0:0:FFFF:13.1.68.3 or ::FFFF:13.1.68.3

  30. Addressing formats • address prefix: 2002:43c:476b::/48 (note: no masks in IPv6!) • zone qualifiers: FE80::800:200C:417A%3 • in URLs: http://[3FFE::1:800:200C:417A]:8000 • (square-bracket convention also used anywhere else there’s a conflict with address syntax)

  31. Hierarchical Addressing and Aggregation

  32. Hierarchical Addressing and Aggregation

More Related