[Ch2 & Ch3] CDN, UDP & TCP, Mux & Demux

CDN

DASH

Streaming stored video

• playing while downloading
• challenge: scale, heterogeneity of clients 👉 solution: distributed, smart client
  • progressive: 점진적(Progressive)으로 내 컴퓨터에 다운로드하여 플레이 되는 방식
  • adaptive: 비디오를 chunk로 나누어 전송

DASH (Dynamic, Adaptive Streaming over HTTP)

• server
  • divides video file into multiple chunks -> each chunk stored, encoded at different rates
  • manifest file: provides URLs for different chunks
• client (smart client)
  • periodically e2e delay 측정
  • request one chunk at a time: choses maximum coding rate and diffrent coding rates at different points in time (depending on available BW at time)
  • client determines when to request chunk, what encoding rate to request, where to requeest chunk

 

CDN

CDN (Content Distribution Network)

• store/serve multiple copies of content at multiple geographically distributed sites (CDN nodes)
• subscriber requests content from CDN

enter deep

• push CDN servers deep into many access networks
• close to users -> better e2e delay performance than bring home

bring home

• smaller number of larger clusters in IXPs or POPs near (but not within) access networks
• better (easier) management & maintenance than enter deep

OTT (Over the top)

• challenges: coping with a congested Internet

---

UDP & TCP

Socket Programming

Socket

• door btw applications process and end-end-transport protocol (L5 - L4)
• Two socket types for two transport services:
  • UCP: unreliable datagram
  • TCP: reliable, byte stream-oriented

 

UDP

UDP

• UDP provides unreliable transfer (only error checking) of groups of bytes (datagrams) btw client and server
• no "connection" btw client & server: no handshaking before sending data
  • no delay for call set-up before data delivery
• transmitted data may be lost or received out-of-order
• sender explicitly attaches IP destination & port # to each pkt -> receiver extracts sender IP address and port # from received pkt

 

TCP

TCP

• reliable, no-loss, in-order, byte stream-oriented
• server must first be running
• client contact server by creating TCP socket -> connection to server TCP -> server TCP creates new socket dedicated to particular client -> source port # used to distinguish client

---

Transport Layer Service

Transport Layer

Transport Layer (L4): process to process comunication

• logical communication btw app processes running on different hots
• Transport protocol run in end systems (hosts) only
  • sender side: breaks app msg into segments -> passes to network layer
  • receiver side: reassembles segments into msg -> passes to app layer

Transport Layer 기본 기능

• L4의 상위 계층인 L5에서 구동하고 있는 process들 간의 msg 교환을 지원
• sending host의 transport 계층에서는 sending / receiving process의 port #를 L4의 PDU의 header에 넣어 전송 👉 MUX
• receiving host의 transport 계층에서는 sending host가 알려준 정보를 이용하여 receiving process (socket)을 찾아 데이터 전달 👉 DEMUX

Transport Layer의 기본 기능은 destination host의 특정 NIC 카드로 도착한 msg들을 기다리는 수신 process를 찾는 것. 이때, NIC 카드에 설정된 L3 IP address와 L4에서 사용하는 port # 를 각 L3, L4 header의 destination 필드 값과 같은지 비교하여 결정한다.

 

TCP Segmentation at L4

• MSS (Maximum Segment Size) which is set during TPC connection set-up 으로 메시지를 쪼갬
• MSS <= MTU (Maximum Transmission Unit == Link transmission rate R) in association with a NIC (Network Interface Card)

UDP

• IP Fragmentation at L3

Application 계층에서 생성된 msg 크기가 전송된 링크의 transmission rate R보다 큰 경우 msg는 더 작은 크기로 쪼개져서 전송된다.
  - Transport Layer에서 수행 -> TCP Segmentation
  - Network Layer에서 수행 -> IP Fragmentation

L4에서 TCP를 사용하는 경우 이미 MTU보다 같거나 작게 쪼개서 L3에 전달되므로 IP가 break down 하지 않아도 됨
  - IP의 의무는 링크를 통과할 수 있도록 링크가 허용하는 MTU 이하로 패킷 크기를 만드는 것

 

 

Transport Layer vs Network Layer

• Network Layer: logical communication btw hosts

 

Transport Layer Protocols

TCP

• reliable, in-order delivery
• congestion control, flow control, connection setup & disconnection
• mux / demux : finding an appropriate process(socket)

UDP

• unreliable, unordered delivery
• mux / demux

Services not avaliable in both TCP and UDP:

• delay guarantees
• bandwidth guarantees

UDP 혹은 TCP가 Demux 할 때, port # + IP address 사용 -> socket을 생성할 때 identification을 위해 자신의 port # 이외에 IP address까지 사용하는 이유?

👉 호스트가 둘 이상의 IP 주소를 가지고 있는 경우, 다른 IP 주소를 destination IP address로 하여 도착한 pkt은 destination port #가 동일하더라도 다른 소켓으로 전달될 수 있기 때문에
👉 포트 번호는 IP 주소 당 관리된다.

---

Mux & Demux

Multiplexing / Demultiplexing

Multiplexing at sender (server)

• handle data from multiple sockets, add transport header (later used for demultiplexing)

Demultiplexing at receiver

• use header info to deliver received segments to correct socket

 

Demultiplexing

How Demux Works

• host receives IP datagrams
  • each datagram has src & dst IP address
  • each datagram carries one transport-layer segment
  • each segment has src and dst port numbers
• host uses IP address & port nubmers to direct segment to appropriate sockets

UDP: Connectionless demux

• sender (mux)
  • created socket has host-local port number
  • when creating IP datagram to send into UDP socket, must specify destination IP address & port #
• receiver (demux)
  • when host receives UDP datagram, checks destination port # in UDP header
  • directs UDP datagram to socket with that port #
  • IP datagrams with same destination port #, but different source IP address and/or source port numbers will be directed to same socket at destination host

TCP: Connection-oriented demux

• each TCP socket identified by
  • source IP address / port # & destination IP address / port #
• demux
  • receiver uses all four values to direct segent to appropriate socket
• server host may support many simultaneous TCP sockets
• web servers have different sockets for each connection client -> threaded
  • non-persistent HTTP will have different socket for each request
  • destination IP address, port #가 같은 경우 UDP는 같은 socket으로 보내지만, TCP는 다른 socket으로 mapping될 수 있음

TCP 서버는 UDP와 달리 자신과 통신하는 각 클라이언트들과 연결된 socket에 해당 client host의 IP 주소와 port number를 추가로 기록한다.