計算機網路_CH7

26 April 2020

計算機網路 Chapter 9-1

Video、Audio特性

video

  1. high bit rate : 傳輸需要很大的頻寬
  2. compression : video是image的集合，因此可以做compression減少需要的頻寬
    • spatial redundancy : 很多空白，可以用少數值代表多個pixel
    • temporal redundancy : video圖片間可能有很多相似，可以兩張圖片共用很多pixel值

Audio

  1. 相較vedio需要較少bit rate
  2. 類比訊號(analog sampling)到數位訊號，取道的類比訊號round到附近整數(quantized)
  3. 錄音時將類比訊號轉成數位訊號(例如有256個值，那一個frame就用1 byte儲存)，播放時再將數位訊號轉回類比訊號(失真)，frame越小失真狀況越少

CBR(constant bit rate): video encoding每個frame需要固定的bit來存 VBR(variable bit rate): video encoding隨frame不同而需要的bit數量不同

Multimedia network application

streaming stored audio, vedio

就是預先錄好存起來的影片、音樂，存在server上，user request時回傳給user，user接收respons

  • user邊接收傳來的資料邊播放影片，這樣就可以邊接收邊播放，不用全部下載在播放
  • user也可以選擇在播放過程中暫停影片、音檔
  • 那就是要保證穩定的接收檔案，不然播完後還沒接收到新的frame就產生lag

client buffering

目的是preload資料，並buffer住

  1. 減少network delay造成lag的問題
  2. 減少bandwidth突然驟降來不及load frame的問題

問題：

  1. video packet loss, retransmit造成delay
  2. client interactive, 包括client快轉造成buffer瞬間減少或pause造成buffer overflow

Prefetching

client試圖download影片速度比播的速度快，這樣才能buffer，如果塞滿client buffer，然後TCP socket buffer也滿，那就會停止傳輸，等到client繼續消frame buffer有空間才會繼續傳

可分成以下三類，主要都是利用client side buffering

UDP streaming

  1. 傳輸速度固定，send rate = encoding rate = constant(穩定傳輸固定量，依據client播放影片消耗frame的速度) -> 如果有network delay會造成lag，畢竟是等速傳輸，沒有congestion conrtol，但沒辦法handle network jitter
  2. small buffer
  3. 用RTP(real time transport protocol)傳送資訊給client
  4. control connection, client送目前的state給server(告訴server目前影片在play, pause….)
  5. 可能會被firewall擋下

HTTP streaming

影片存在HTTP server的file裡，可用url存取

  1. client要求影片時，發起GET request之類的TCP request
  2. server瘋狂送資料，不要congestion control就好
  3. client的buffer有一個最低位，buffer量超過最低位就開始播
  4. 因為TCP有congestion control跟resend的機制，所以buffer很重要，不然依定lag，傳送過程像鋸齒狀
  5. youtube,Netflix用這個
  6. 能過防火牆
  7. larger playout delay
  8. 有HTTP byte-range header決定client目前想播哪個片段的影片，對reposition HTTP streaming很好用。透過header能決定server要傳哪個片段的影片。但跳轉的話buffer住的frame就會在沒被看的情況下被清掉，造成waste，因此設定client buffer size很重要。

VoIP

Internet telephony, real-time conversational voice 網路是best-effort讓資料從sender送到receiver，但中途沒有保證多久會收到和data loss rate為多少，所以對一個real-time service沒辦法保證多久會收到資料是一個很大的問題，以TCP而言有congestion control或者封包會掉，那這都沒辦法確定封包多久後會收到 VoIP提出下列兩個問題解法

  1. 何時playback frame
  2. 如何處理沒收到的frame(packet loss)
  3. loss tolerance，VoIP本身能接受小程度的packet loss

他提供三個機制

  1. Fixed playout delay

End-to-end delay

因為router queuing、processing導致delay 如果end-to-end delay沒太嚴重(150ms以內)，不會影響user 但delay太長會有問題，所以VoIP會把超過400ms的packet就不理他了

jitter

因為router queuing delay的關系，有的packet delay小有的大，這種不規則的packet到達時間 例如queue住的資料中間夾了很多其他的packet，那delay就長 減少jitter

  1. 每個packet加入timestamp
  2. 用上述buffer方法確保一直都有東西buffer

Fixed playout delay

  1. sender將每個資料timestamp t
  2. client端設定每筆封包在產生後q秒內要播，所以封包從產生後t+q秒後要播
  3. 假設收到時超過t+q秒，就discard
  4. q的選法
    • 如果network jitter很大，那q要設大一點
    • 如果network jitter還好而且封包到的時間標準差少，q可以設小一點，q設太小會容易discard packet

如圖packet產生後固定時間就是播放的底線，沒收到就blue了

Adaptive playout delay

前面的做法都是要buffer到一定量才開始播放，這會導致一開始很大的initial delay。因此改成adaptive方式來算delay來決定threshold設多少 基本上就是算出delay的平均＋標準差為threshold 令

  • $t_i$ : 第i個packet被generate的timestamp(第i個packet上的timestamp)
  • $r_i$ : client收到第i個packet時間
  • $p_i$ : 第i個packet被播放的時間
  • $d_i$ : average network delay，跟之前的network delay和最新的packet的內差，u為隨意constant
  • $v_i$ : 封包delay的標準差

    $d_i = (1-u)d_i+u(r_i-t_i)$ $v_i = (1-u)v_{i-1}+u|r_i-t_i-d_i|$

first packet playout time = $t_i+d_i+uv_i$ u是constant

透過sequence number、timestamp來判斷談話內容有沒有小段的silence

  1. 沒packet loss : 兩個packet timestamp相差20ms以上代表有小段silence
  2. 有packet loss : 同上外sequence number要連續，則代表有小段silencecket的timestamp不會超過某個值 如果有packet loss要注意sequence number

Loss recovery scheme

retransmission在real time service沒有意義，所以不要retransmission，但要設法能recover

Forward error Correction(FEC)

  1. 傳一些能幫助recovery的redundant資料
每傳n筆資料再傳一比redundant資料(為那n比資料的xor)，
這方法能忍受一筆的data loss，當n不要取太大時，這方法有效
  1. 傳原本audio外再傳low-resolution的audio - piggyback
如果某個frame loss可以用low-resolution那個代替
可以忍受多筆的data loss
缺點是相對上面那個耗頻寬

Interleaving

傳送data時不是照順序一一傳送，而是跳著傳，因此一個packet段弄丟，並不是弄丟一段連續的frame，而是數個有距離的frame，因此不會出現一段是空白的frame

  • 優點：減少packet loss造成的損害
  • 缺點:playout delay高，不適用於VoIP

Error concealment

自己復原loss packet 影片、音檔的變化是有連續的，因此可以interpolate或者複製前一個frame來求得loss frame low computational cost

VoIP case study - Skype

  1. 用UDP傳資料，但如果有防火牆會改用TCP，control packet用TCP
  2. 使用FEC來做資料recover
  3. node分成一般peer跟super peer，一個super peer負責多個peer，登入的user都會assign到一個super peer
  4. supernode(super peer)彼此會和其他super node相連，並且像name server，存其他user的IP location
  5. client和super peer產生連結，super peer幫忙forward訊息

沒NAT

透過Super node(super peer)找到對方的IP，直接交流傳訊息(不用透過Super node來傳)

NAT的問題(兩方都NAT)

在NAT下，兩個client如果只知道IP並沒有辦法互相溝通，沒辦法建立連線，根本不知道對方是在哪個port 如果只有一方有NAT，只有NAT那方能夠建立connection，不然要用super node peer A要和peer B溝通

  • 透過peer A的super peer和peer B的super peer溝通
  • 建立連結後另外選一個非NAT的super peer(relay peer)來當作溝通橋樑，原本的super peer告知user連到relay peer並用它來溝通

會議模式

  1. 如果人藏在NAT裡，那還是要用relay node
  2. 利用server來distribute，因為upload速度比download慢很多，所以統一傳到一個server distribute減少upload的量 多人視訊、音檔 音檔： n個user傳音檔到server(conference initiator)，他在把所有人傳來的何在ㄧ起傳給n-1 user 影片：
  3. 每個user傳影片到server cluster，server cluster把他distribute給其他n-1個user