Quartz 4

Real Time Traffic on the Internet

1 min read

What is Real-time Traffic? Defining characteristic: deadlines

  • The system fails if data is not delivered by a certain time
  • Railway signalling must deliver data to change a signal before train arrives – Hard Deadline
  • Streaming video should deliver a new frame every 60th of a second, else the movie playback stutters – Soft Deadline
  • What is the probability a deadline is missed? What are the consequences? Engineer accordingly – no system is 100% reliable

Deadlines can be absolute or relative

  • Data must be delivered before a certain time – absolute deadline
  • Data must be delivered periodically, within some time after the previous – relative deadline Real-time is not necessarily high performance
  • It requires predictable timing, not necessarily high Bandwidth or low Latency

Streaming Applications

Video on demand has no absolute deadline, but needs regular data to prevent stalls once started Acceptable if a takes a few seconds to start the video Playback should be smooth once it starts

Live video may have absolute deadlines e.g., live sports playout

Bit rate depends on desired quality Higher quality is better, up to limits of display Predictable, but lower, quality often preferred to more variable, but on average higher, quality

For a given bit rate, trade-off between frame rate and frame quality Smoother motion or higher resolution?

Why do we use HTTPS for streaming over RTP or WebRTC ?

We use an adapted HTTP (MPEG DASH - HTTP Adaptive Streaming)

We do this because of Content Distribution Networks (CDN)

Link to original

Interactive Applications

Interactive Applications

Interactive applications have been around for a long time, and come in many forms:

  • Telephony
  • Voice-over-IP (VoIP)
  • Video Conferencing

Many types:

Requirements

Requirements for interactive applications determined by task and human perception:

  • Phone call or video conference One-way mouth-to-ear delay ~150ms maximum for telephony Video conferences want to lip-sync audio and video Audio should be no more than 15ms ahead, or 45ms behind, video

  • Lecture style Mostly unidirectional with occasional questions → can tolerate much higher latency

  • Distributed music performance One-way latency ≪50ms desirable Speed of sound: ~15ms to go from one side of a large orchestra to the other

Media Encoding

Speech Encoding

Typically operates on 20ms packets

  • Data rate tens of kilobits
  • Background noise packets are much lower encoding quality Highly loss tolerant, can conceal around 10-20% random packet loss without noticing Burst losses are less well concealed

Video Encoding

Video frame rate/resolution is highly variable:

  • High def H.264 is around 2-4Mbps
  • Frame rates from 25-60fps common
  • I-frame ⇒ tens of packets; P-frames ⇒ single/few packets Not very loss tolerant
  • No scene changes to reset decoder state to known good value
  • Retransmissions possible in some cases; forward error correction more typical

General Transmission Path

  1. Frames of media data are captured periodically
  2. Codec compresses media frames
  3. Compressed frames fragmented into packets
    1. Transmitted using RTP inside UDP packets
    2. RTP protocol adds timing and sequencing, source identification, payload identification
  4. Transmitted over the network

General Reception Path

  1. UDP packets containing RTP protocol data arrive
    1. Separated according to sender
  2. Channel coder repairs loss using forward error correction
    1. Additional packets sent along with the media, to allow some repair without needed retransmission
  3. Playout buffer used to reconstruct order, smooth timing
  4. Media is decompressed, packet loss concealed, and clock skew corrected
  5. Recovered media is rendered to user

Forward Error Correction (FEC)

Retransmission possible, but often takes too long – Packet should have been played out before retransmission arrives Forward error correction (FEC) often used instead Additional FEC packets are sent along with the original data Contain error correcting codes e.g., the Exclusive-OR (XOR) of the original packets – many different FEC schemes If some original packets are lost but the FEC packets arrive, original data can be reconstructed

Link to original

QoE

Quality Of Experience (QoE)

What ultimately matters is subjective quality of experience

  • Does the application meet user needs?
  • Does the application allow users to communicate effectively?
  • Does the application provide compelling entertainment?

QoE is not a one-dimensional metric

  • What aspect of user experience are you evaluating?
    • e.g., “Does it sound good” is not the same as “Can you understand it?”
  • How does your metric relate to the task being performed?
  • Some aspects of user experience can be estimated from technical metrics
    • e.g., the ITU-T E-model for speech quality evaluation based on latency and packet loss
  • Some aspects are subjective and task dependent – need user trials
Link to original

QoS

Quality Of Service (QoS)

Quality of Service reserves network capacity for Real Time Traffic on the Internet, but it adds a lot of complexity.

You must check the reservations are allowed and paid for, and overall this only helps if there isn’t enough capacity on the network.

Crucially unfair for the network

Link to original

History

Telephony and voice-over-IP (VoIP), Internet radio, video conferencing, streaming video and TV, gaming, sensors, industrial control

Initial packet voice experiments → 1970s Network Voice Protocol Core standards defined → mid-1990s SIP, SDP, RTP, RTSP, H.323 HTTP adaptive streaming → mid-2010s MPEG DASH

Graph View

Backlinks