Reference:

• Computer Networks, Fifth Edition by by Andrew S et al.

• The Australian National University CECS

  Real-time?

• 한 패킷 손실을 어느정도 감당할 수 있는가

• 한 지연된 패킷을 어느정도 감당할 수 있는가

• 한 지연을 얼마나 알아차릴 수 있는가

  • 비디오컨퍼런스와 스트리밍, 비디오와 오디오의 싱크

• TCP를 Contend Delivery Network (CDN)을 이용하여 스트리밍

  • 이로 인해 지연의 심각성을 낮추고, 신뢰성을 얻을 수 있다. (빠르게, 그리고 확실하게 스트리밍)
  • CDN은 ISP와 User 사이에 있으며, ISP에 서비스 비용을 지불하고, 유저로 부터 비용을 받는다. CDN은 유저의 트래픽을 받아서 저장하고, 시청자에게 같은 데이터를 보냄으로써, 유저의 부담을 덜하며, 다수의 유저에게 같은 데이터를 보내준다.
  • 즉 트위치, 아프리카등의 플랫폼은 CDN을 이용한다고 봐야한다.

• UDP for two way (interactive), real-time

  • UDP의 특성상 낮은 지연과 낮은 오버헤드를 가지고 있음.

Why is it hard?

인터넷은 best-effort (서킷을 가지고 있지 않는한) 의 형식을 띄고 있어서 패킷 손실, 지연 등을 100% 보장할 수 없다. 다양한 종류의 원인으로 인한 손실도 존재한다.

Network Delays

• 송신자는 지속적인 흐름의 오디오/비디오 샘플들을 보낸다 (대역폭은 코덱에 따라 다르다)
  • 물론 수신자는 지속적인 스트림을 받기를 기대한다 (끊김없이)
• 이를 위해 라우터의 경로, 대역폭, 용량 (capacity) 등을 모두 필요로 한다. 물론 종단까지의 모든 라우터와 경로가 송신자것이 아니니 불가능하다.
• 이상적으로 레이턴시 이후에 100%의 패킷을 받는게 좋지만 (constant delay and everything at once) 현실은 다양하게 변화한다.

Jitter: 처리 시간 및 결과물의 도달 시간의 변동폭 등 (패킷 지연 변동폭)

즉 위의 패킷 전달 마찰은 밑의 그림과 같은 상황을 야기한다.

각 패킷에 대한 지터가 다르기때문에 보낸 순서와 상관없이 도착하는 패킷 순서및 타이밍이 다른것.

버퍼링 (TCP - lite)

송신자는 당연히 지속적인 오디오/비디오 샘플 (패킷)을 보낸다. 당연하게도 수신자는 끊김없는 스트리밍을 받기를 원한다.

이와 같은 효과를 내기 위하여 수신자는 playout buffer을 만들어 지연등을 부드럽게 만든다 (보통 바이트 단위로 만들지만, 효과적이기 위해서는 시간 단위로 만들어야 한다)

• 지연 시간 (playout)을 일정 단위를 추가해서, 그 시간/단위 기간동안 패킷들을 더 기다린후, 유저에게 보여주는 형식이다.
• 내가 아는 하두리? 버퍼링은 바이트 단위의 버퍼링이다 (시간 관계없이 영상 바이트들을 어느정도 받고 나서야 시작이 됬으니까).
• 밑의 그림처럼, 어느 선까지 받고서 그 이후의 패킷들은 버린다. (물론 예상컨데 버퍼링 implementation 마다 다를것이다.)

물론 위와 같은 버퍼링은 trade-off가 존재한다.

1. 큰 버퍼:
   1. 지연으로 인한 패킷 손실이 줄어든다. 이는 곧 지터/PDV (Packet Delay Variation) 에 대한 tolerant가 늘어난다.
   2. 다만 transmission 과 playout 간의 지연이 늘어난다. 즉 영상을 시작하면 부드럽게 진행되지만, 처음 시작하기까지 오래걸림.
2. 작은 버퍼:
   1. transmission and playout 의 delay가 적다
   2. 여유 기간이 짧은 만큼 (큰 버퍼에 비해) 더 많은 패킷들이 지연으로 인해 손실된다. 지터/PDV에 대한 tolerant가 더 적음.

바라는 지연이 짧을수록 손실을 방지하기가 더 어려워진다 - 이로 인해 glitch 가 생성되는데. 흔한 예로는 비디오와 오디오 싱크가 안 맞는등..

Fixes?

• 재전송:

  • 패킷 손실을 알아차리면, ARQ (TCP-like) 를 이용해서 재전송을 요청한다.

  • 이로 인해 round-trip-time + latency + Queue 딜레이 만큼 더 걸린다

    • 이는 곧 큰 수신 버퍼와 지연을 의미하며, 송신자 또한 버퍼 도구가 필요하다 (아마 원하는 패킷을 저장해두고 다시 보낼수 있어야 하니까).

  • 멀티캐스트 (UDP) 방식에서는 반드시 송신자가 다시 보내는것은 아니다

    • 아래와 같이 주위의 다른 수신자가 있으면 걔가 보내줌

    

• 탄력적 버퍼 (Elastic):

  • 상황에 맞게 버퍼의 크기를 조정함
  • 이를 위해 playout을 느리게 함
  • 상황이 나아지면 버퍼의 크기를 다시 줄여서 (지연/손실이 줄어드니) 빠르게 진행한다 (실시간일 수록 좋으니까 상황이 괜찮으면).

• Error Correction:

  • 패킷간의 보간법을 위한 미디어 인코드 - 보간법을 이용해 뭐를 놓쳤는지 알 수 있음
    • Forward Error Correction - 고장난게 있으면 직접 고칠수 있음. 신뢰성이 필요한곳이나 재전송이 비싼 경우에 사용되곤 한다.

• 병렬 전송

  • 다양한 카피들을 같은 시간에 보내는것 - 동영상 화질에 종류가 있는것들. 즉 1080으로 보다가 멈추는것보단 360으로라도 끊김없이 보는게 나으니까. 즉 결국 내용을 볼 수 있다는것 자체로 신뢰성이 필요한곳에 사용될 수 있다.

Realtime Transport Protocol (RTP)

UDP, TCP냐에 따라 연결성이 달라짐. 다양한 미디어 인코딩을 지원하며, 다양한 자원들이 병합, 동기화, 선택 될 수 있다. (비디오 따로 오디오 따로 보내서 두게를 합치거나, 언어와 자막을 선택하는등의)

• 송신자는 여러가지들을 고려하여 RTP를 어떻게 보낼것인지 조정할 수 있다. 현재 스트리밍이 어떻게 되고 있는지 (비율, 인코딩, 에러 수정, 재전송 등등), 혹은 얼마나 많은 그리고 어느 종단들이 받고, 보내고 있는지 (멀티캐스트).
• RTP Control Proctocol (RTCP)
  • 양방향, Out-of-Band 시그널링 (독립된 채널을 통해 시그널링 하는것) (RTP는 짝수 포트, RTCP는 홀수 포트) - 대역폭을 제한해야한다.
  • 송수신자 모두 보고를 한다. (통계: 패킷의 수신/손실, 지연, 지연 변동폭등)
  • 자원 설명, 송수신 시작/완료 (Hello Goodbye)
  • 존재 알리기 (heartbeat pulse), 거리 (홉), 재전송 요청 채널 등등 다양하게 지원함

ALL together

여러 사이트에 여러 미디어 스트림을 보내기.

다음과 같은것들을 필요로 한다.

1. Establish a call: Session Initiation Protocol (SIP) - 세션 시작
2. Negotiate the details: Session Description Protocol (SDP) - 세션 정보 협상 (뭐로 할건지)
3. Deliver the media: RTP and RTCP - 협의 바탕으로 결정한 프로토콜로 정보 교환
4. Playout as reliable and quickly as you can: (buffer) - 알아서

Session Initiation Protocol (SIP)

• Open with IETF protocol to establish and close the call with RFC.
  • 어느 방식으로 전달 하던 상관없음.
  • 이 세션 프로토콜은 스카이프, 메센저, 줌등에 사용되지 않음
  • 라이벌로는 ITU H.323 이 존재함
• Voice over IP (VOIP)에 주로 쓰임
• 프록시,registrars, redirectors, border controller, gateway 등등을 포함하하며 PSTN 연결이나, NATs등에 유용하다.

Non-realtime realtime?

• 단 방향 미디어 전송: 스트리밍
  • less interactive, 지연에 덜 민감하며 (almost live), 대역폭이나 지터에 문제를 아직 가지고 있음.
• Sliding windows을 통한 playout buffer 관리 (나중에 다시 한번 읽을것)
  • 수신자는 컨텐츠를 빼내고, 버퍼를 played out 된것처럼 채운다

Real Time streaming Protocol (RTSP)

• 스트리밍 세션을 만들고 미디어 전송을 협의한다 (프로토콜등)
• HTTP 와 SIP와 비슷하다
  • 옵션 (무엇을 할 수 있는지) 설명 (무엇을 줄 수 있는지)
  • 셋업 (스트림(들)을 프로토콜을 통해 수신할 준비
  • 플레이 (play from time 1 to 2)
• RTP/RTCP 등을 통해 대역폭, 인코딩을 적용함

최후의 수단: HTTP 이용

• 방화벽을 통과 할 수 있으니까
• 다양한 extensions을 지원하니까 (어플리케이션, 전송 프로토콜등)
• Head Request를 통한 미디어와 옵션들 요구
• Get with Range Get을 통한 요구
  • playout 버퍼를 위한 조각들을 다운, 서버에게 인코딩 부탁하기
• HTML 5 has bulit in vidoe player. (to kill flash)
• 이득: 서버 state 필요없음, HTTP 프록시, 캐쉬, CDNs 등을 물려 받음

정리

• 완벽하고, 적은 지연, 실시간등은 best effort 네트워크에서 하기 정말 힘들다
  • Very application specific - 유통성이 없음
• 특별한 서킷을 이용해서 경로를 만드는게 아닌이상, 힘듬
• 오디오 비디오는 괜찮음 (기술의 발달로 화질이 올라감) - 괜찮음의 정의가 시대상을 따라감
• 기기 조종을 위한 실시간 트래픽이 늘어나는 추세임
  • 인터넷이 최선의 선택은 아니더라도, 유일한 선택일지도 모름