Split View: [컴퓨터 네트워크] 18. 멀티미디어 네트워킹과 스트리밍

Types of Multimedia Applications
===================================

1. Streaming Stored Media
   - Netflix, YouTube, Hulu
   - Pre-recorded content playback
   - Some delay acceptable (buffering)

2. Live Streaming
   - Twitch, live sports broadcasts
   - Real-time content with slight delay
   - Target: under 10 seconds delay

3. Interactive Real-Time
   - VoIP (Skype, Zoom, Discord)
   - Video conferencing, online gaming
   - Requires under 150ms delay (strict)

Video Compression Principles
==============================

Uncompressed Video:
  - Resolution: 1920 x 1080 (Full HD)
  - Color: 24 bits/pixel
  - Frame rate: 30fps
  - Bit rate: 1920 x 1080 x 24 x 30 = ~1.5 Gbps

After Compression:
  - H.264/AVC: 1~10 Mbps (Full HD)
  - H.265/HEVC: 0.5~5 Mbps (Full HD)

Compression Techniques:
  1. Spatial Redundancy
     - Exploits similarity of adjacent pixels within a frame
     - I-frame: Independently compressed

  2. Temporal Redundancy
     - Encodes only differences between consecutive frames
     - P-frame: Difference from previous frame
     - B-frame: Difference from adjacent frames

Bit Rate Modes
=================

CBR (Constant Bit Rate):
  Constant bit rate
  |_______________________________________
  |========================================
  |========================================
  +----------------------------------------> Time

VBR (Variable Bit Rate):
  Bit rate varies with scene complexity
  |         ___
  |   __   |   |  _    ___
  |__|  |__|   |_| |__|   |___
  +----------------------------------------> Time
    Static Dynamic Static Dynamic Static

VBR is typical: Better quality at the same average bit rate

HTTP Streaming Operation
==========================

Server                              Client
  |                                    |
  |<-- HTTP GET (video file request) --|
  |                                    |
  |--- HTTP Response (video data) ---->|
  |     Sequential delivery via TCP    |
  |                                    | [Receive Buffer]
  |                                    |     |
  |                                    | [Client Buffer]
  |                                    |     |
  |                                    | [Video Playback]

Client Buffer Behavior:
  - Playback starts when sufficient data accumulates
  - TCP adjusts send rate via congestion control
  - Rebuffering (playback pause) if buffer empties

DASH Operating Principle
==========================

Server-Side Preparation:
  Encode original video at multiple bit rates and split into chunks

  Bit rate 1 (240p):  [C1][C2][C3][C4][C5]...  0.5 Mbps
  Bit rate 2 (480p):  [C1][C2][C3][C4][C5]...  1.5 Mbps
  Bit rate 3 (720p):  [C1][C2][C3][C4][C5]...  3.0 Mbps
  Bit rate 4 (1080p): [C1][C2][C3][C4][C5]...  6.0 Mbps
  Bit rate 5 (4K):    [C1][C2][C3][C4][C5]...  15.0 Mbps

  Manifest file (MPD): URL and bit rate info for each chunk

Client Operation:
  1. Download manifest file
  2. Measure current available bandwidth
  3. Request next chunk at bit rate matching bandwidth
  4. Dynamically adjust bit rate as bandwidth changes

Bit rate changes over time:
  [720p][720p][1080p][1080p][480p][480p][720p][1080p]
                      ^BW increase  ^BW decrease  ^Recovery

Without CDN vs With CDN
=========================

Without CDN:
  US Server <=============> Korean user (200ms+ latency)
  US Server <=============> Brazilian user (300ms+ latency)
  US Server <=============> Australian user (250ms+ latency)
  --> Load concentrated on one server, high latency

With CDN:
  [Origin Server]
       |
  [CDN Server: Seoul] <--> Korean user (10ms latency)
  [CDN Server: Sao Paulo] <--> Brazilian user (15ms latency)
  [CDN Server: Sydney] <--> Australian user (12ms latency)
  --> Content delivered from near the user

CDN Deployment Strategies
===========================

1. Enter Deep
   - Place servers inside ISP access networks
   - Very close to users
   - Difficult to manage (very many servers)
   - Akamai approach: 240,000+ servers worldwide

2. Bring Home
   - Place large server clusters near IXPs (Internet Exchange Points)
   - Easier to manage
   - Slightly more distant from users
   - Limelight, Google CDN approach

CDN Content Delivery Process
===============================

User requests video.example.com/movie.mp4:

1. User browser performs DNS lookup: video.example.com
2. Origin DNS redirects to CDN DNS via CNAME
3. CDN DNS returns IP of CDN server closest to user
4. User sends HTTP request directly to CDN server
5. CDN server delivers content (immediately on cache hit, fetches from origin on miss)

DNS-based CDN Server Selection:
  User location --> Local DNS IP --> CDN DNS
  CDN DNS returns IP of geographically closest server

Netflix Streaming Architecture
=================================

[Netflix Client App]
        |
        | 1. Login, search, recommendations
        v
[AWS Cloud] (Netflix Backend)
  - User authentication
  - Content recommendations
  - DRM licensing
  - Manifest file generation
        |
        | 2. Streaming URL (CDN server address)
        v
[Netflix Client App]
        |
        | 3. DASH-based video streaming
        v
[Netflix Open Connect CDN]
  - Proprietary CDN infrastructure
  - OCA (Open Connect Appliance) installed inside ISPs
  - Popular content pre-distributed (during off-peak hours)

VoIP Requirements
===================

- Acceptable delay: Under 150ms (good), under 400ms (tolerable)
- Packet loss: 1~5% loss recoverable with FEC
- Jitter: Variation in packet arrival intervals --> compensated with playout delay

Voice Encoding:
  PCM: 8000 samples/sec x 8 bits = 64 Kbps
  Packetization: 160 bytes every 20ms + header = ~200 byte packets

Jitter Problem
================

Sender: Sends packets at regular intervals (20ms)
  |P1|  |P2|  |P3|  |P4|  |P5|  (20ms intervals)

After traversing network, arrival intervals become irregular:
  |P1|    |P2||P3|      |P4|  |P5|  (variable intervals)

Solution: Playout Buffer
  - Store received packets in buffer
  - Play back from buffer at regular intervals after fixed delay

Playout Delay Setting:
  Fixed playout delay:
    Same delay applied to all packets
    Large delay: fewer packet losses but increased conversation delay
    Small delay: natural conversation but late packets discarded

  Adaptive playout delay:
    Adjust delay between talkspurts
    Dynamically adjust based on estimated mean and variance of network delay

VoIP Loss Recovery Techniques
================================

1. FEC (Forward Error Correction)
   Method A: Redundant packet transmission
     Original:  [P1][P2][P3][P4]
     XOR:       [P1^P2][P2^P3][P3^P4]
     If P2 lost: P1^P2 XOR P1 = P2 recovered

   Method B: Insert low-quality copy
     [P1 high quality][P1 low copy | P2 high quality][P2 low copy | P3]
     If P2 lost, substitute with P2 low-quality copy

2. Interleaving
   Original:     [1,5,9,13] [2,6,10,14] [3,7,11,15] [4,8,12,16]
   Interleaved:  [1,2,3,4] [5,6,7,8] [9,10,11,12] [13,14,15,16]

   Single packet loss results in distributed rather than consecutive loss
   --> Recoverable via interpolation

QoS Requirements by Traffic Type
===================================

Traffic Type    | Bandwidth | Delay    | Jitter  | Loss
----------------+-----------+----------+---------+--------
Email           | Low       | N/A      | N/A     | 0% needed
Web Browsing    | Medium    | Low      | N/A     | 0% needed
File Transfer   | High      | N/A      | N/A     | 0% needed
VoIP            | Low       | Very Low | Low     | Some OK
Video Streaming | High      | Low      | Low     | Some OK
Online Gaming   | Low       | Very Low | Very Low| Some OK

QoS Mechanisms
================

1. Marking
   - Mark priority on packets
   - Use ToS/DSCP field in IP header
   - High priority: VoIP, video conferencing
   - Low priority: File downloads, email

2. Policing
   - Limit traffic to not exceed agreed rate
   - Token Bucket: Tokens generated at constant rate, consumed when sending packets

3. Scheduling
   - Priority queuing, WFQ, etc.
   - Process higher priority traffic first

4. Admission Control
   - Determine if network can accommodate new flow
   - Reject if not possible

Token Bucket Algorithm
========================

Parameters:
  r = token generation rate (tokens/sec)
  b = bucket size (maximum tokens)

Operation:
  - Tokens accumulate in bucket at rate r
  - Tokens consumed when sending packets
  - If no tokens, packets wait or are discarded
  - New tokens discarded if bucket is full

Effect:
  - Average send rate: limited to r
  - Instantaneous burst: up to b allowed

  Token count
  b |____
    |    \___
    |        \___
    |    Burst    \___Average r
    +-------------------> Time

Diffserv Architecture
========================

Scalable framework for providing QoS on the Internet

Operation:
  1. Edge routers: Classify and mark packets (set DSCP)
  2. Core routers: Differentiated treatment based on DSCP value

DSCP (Differentiated Services Code Point):
  Uses 6 bits of the ToS field in IP header

PHB (Per-Hop Behavior):
  - EF (Expedited Forwarding): Highest priority (VoIP, etc.)
  - AF (Assured Forwarding): Guaranteed delivery (4 classes)
  - BE (Best Effort): Default treatment (general traffic)

Advantages: Scalable, no per-flow state needed
Disadvantages: Strict QoS guarantees are difficult