지난 시간 배운 내용

DNS는 각 ip address와 host address를 매핑 시켜 놓은 데이터베이스, 그 엔트리가 DNS 서버.

각 엔트리의 타입에 따라 name-value의 해석이 달라짐

• Type A: IPv4 addr - host name

  Type AAAA: IPv6 addr - host name

• Type CNAME: Canonical host name - alias host name

• Type MX: alias host name - mail server's host name (수신자 메일 서버)

• Type NS: alias host name - authoritative DNS server host name

---

Inserting records into DNS

"Network Utopia"라는 회사를 세워 도메인을 등록한다면

.com TLD server 에 두 가지 RR을 등록해야함

• (nu.com, dns1.nu.com, NS)

nu.com이라는 도메인의 모든 웹 서버, 메일 서버와 매핑 관계를 갖고 있는 PC(authoratitve dns server)의 host name → 그 host name의 ip도 필요

• (dns1.nu.com, 212.212.212.1, A)

그 host name의 ipv4. (ipv6도 있다면 AAAA로 한 줄 더 넣을 수 있음)

⇒ nu.com의 IP주소를 물으면 .com TLD에 와서 authorative dns server로 찾아갈 수 있음

Accessing Web Page of Network Utopia

Alice가 "www.networkutopia.com"에 접속하는 과정 시나리오

(1) Alice의 호스트가 www.networkutoia.com의 IPv4 주소를 묻는 DNS query를 Alice가 속한 ISP의 LDNS에게 보낸다.

→ Alice가 속한 ISP의 LDNS가 모든 질의를 한 후 cache를 보유

(2) Alice의 LDNS는 DNS query를 (이전에 이미 알고있었던 .com TLD DNS 서버의 IP 주소를 이용해서) .com TLD DNS 서버에게 보낸다.

DNS client와 Local name server(LDNS)는 같은 ISP에 존재하며, LDNS가 root DNS 서버에 먼저 묻지않고도 바로 .com TLD DNS 서버에게 DNS query를 보낼 수 있는 이유는 이전에 이미 root DNS 서버에게 query를 보내서 .com TLD DNS 서버의 hostname과 IP주소 매핑을 얻었고 아직 cache에 저장하고 있었기 때문이라고 가정

→ 처음엔 root DNS 서버에게 .com TLD 서버의 ip주소를 질의 해야 함. 이미 질의한 적이 있어 .com TLD 서버의 IP 주소를 보유하고 있는 것

.com TLD 서버의 IP 주소를 보유하고 있다는 것은 NS와 A타입의 RR을 보유, 즉 .com TLD 서버의 hostname과 IP주소를 보유하고 있다는 것

(3) (Bob이 .com TLD DNS 서버에 등록해 놓은 NS와 A 타입의 RR을 이용해서) .com TLD 서버는 Network Utopia 회사의 authoritative DNS 서버의 hostname과 IP주소(이 슬라이드에서는 212.212.212.1이라고 가정함)를 포함한 DNS reply 메시지를 Alice의 LDNS에게 보내 응답한다.

→ .com TLD 서버는 host aliace name과 authoritative dns server의 host name, 그리고 그 host name과 IP주소를 매핑하고 있음

(4) Alice의 LDNS는 DNS reply 메시지에서 얻은 Network Utopia 회사의 authoritative DNS 서버의 IP주소를 이용해서 다시 (iterative 방식으로) Network Utopia 회사의 authoritative DNS 서버에게 DNS query를 보내 www.networkutoia.com의 IP주소를 묻는다.

(5) Network Utopia 회사의 authoritative DNS 서버(gateway)가 www.networkutoia.com의 IP주소를 저장한 DNS reply 메시지를 Alice의 LDNS에게 보낸다.

(6) Alice의 LDNS는 www.networkutoia.com의 IP주소(이 슬라이드에서는 212.212.212.4라고 가정함)가 담긴 DNS reply 메시지를 Alice 호스트에게 전달한다.

(7) Alice의 browser가 212.212.212.4로 TCP 연결을 맺고 HTTP request 메시지를 전송한다.

→ client에서 TCP Sync. 메시지를 (DNS reply에서 얻은 web서버의 IP주소를 IP 패킷해더의 destination IP주소 필드에 넣어서) 보내는 것을 의미

⇒ Network Utopia 회사의 authoritative DNS 서버(gateway) dns.nu.com에 있는  entry는 아래 두 개. (IP주소는 임의)

• type A RR for web server & CNAME RR for web server

(www.nu.com, webserver1.nu.com, CNAME) : 웹서버의 진짜 hostname

(webserver1.nu.com, 212.212.212.4, A) : hostname과 매핑된 IP address

(www.nu.com, webserver2.nu.com, CNAME)

(webserver2.nu.com, 212.212.212.5, A)

• type MX RR for mail server

(nu.com, mail1.nu.com, MX) : 메일 서버의 hostname

• type A RR for mail server

(mail1.nu.com, 212.212.212.6, A) : hostname과 매핑된 IP address

DNS protocol, messages

Application layer(L5)에서 붙는 메시지

---

P2P applications

Pure P2P architecture

• no always-on server

dedicated된 특정의 서버가 X. 각 클라이언트는 서버가 될 수 있다.

• arbitrary end systems directly communicate

클라이언트끼리 직접 connection을 맺고 통신하는 구조

• peers are intermittently connected and change IP addresses

File distribution: client-server vs P2P

P2P의 가장 큰 장점: self-scalability

한 영화 파일이 한 PC에 모두 저장되어 있지 않고 청크(chunk)로 쪼개져 있음

클라이언트-서버 구조에선 클라이언트가 많을 시 서버의 속도가 감소

• 서버로의 connection이 많아서 busy
• 클라이언트가 속한 ISP도 busy해짐 → Web cache 사용

각기 다른 n개의 ISP와 연결된 n개의 peer(P2P에서의 client, 서버가 될 수도 있기에 peer라고 함), 사이즈가 f인 하나의 파일을 모두 다운 받으려고 할 때, 각 peer들이 다운로드 하는데 걸리는 시간?

P2P와 client-server를 정확히 비교하려면 core network에서의 delay를 무시

Access link의 up/down link are devoted to the file distribution

File distribution time: client-server

Parameters

• ui, di: up/down link bandwidth (속도 단위: bps = 초당 비트 수)

• us: server의 up link bandwidth = R bps

• server transmission: must sequentially send (upload) N copies

  • time to send one copy: F/us = Dtrans = L/R

    → time to send N copies: NF/us

• client: each client must download file copy

  각 클라이언트의 access link band width는 다를 수 있음

  • dmin = min client download rate = min(di) ⇒ bottleneck

    → min client download time: F/dmin

⇒ time to distribute F to N clients using client-server approach

Dc-s > max{NF/us,F/dmin}

(N이 증가한다면 N에 의해 linear하게 증가하므로 서버의 업로드 속도에 의해 영향을 받음)

File distribution time: P2P

Parameters

• ui, di: up/down link bandwidth (속도 단위: bps = 초당 비트 수)

• us: server의 up link bandwidth = R bps

• server transmission: must upload at least one copy

  • time to send one copy: F/us = Dtrans = L/R

• client: each client must download file copy

  각 클라이언트의 access link band width는 다를 수 있음

  • dmin = min client download rate = min(di) ⇒ bottleneck

    → min client download time: F/dmin

• clients: as aggregate must apload NF bits

  → max upload rate (limiting max download rate) is us + S(ui)

⇒ time to distribute F to N clients using client-server approach

DP2P > max{F/us,F/dmin,NF/(us + S(ui))}

N이 증가 하여도 NF(us + S(ui))는 상수

F/u = 1 hour = L/R, us = 10u → F/us (한 copy 올리는데 걸리는 시간) = 6min

client 중 가장 느린 download 속도가 서버의 upload 속도보다 빠름

= downlink는 bottleneck이 아님 ⇒ uplink 속도가 영향을 미친다.

여기서 dcs = NF/us = NF/10u = N/10*1hour

따라서, client가 많을 때는 P2P를 이용하는 것이 self scalibilty가 좋다.

---

video streaming and content distribution networks (CDNs)

Video Streaming and CDNs: context

해결해야 하는 가장 중요한 두 가지

(1) server infra(storage, network bandwidth)

⇒ Content Distribution Network로 해결! (network를 직접 만들자!)

(2) heterogeneity(각기 다른 client의 downlink bandwidth, video quality)

⇒ Dash

Multimedia: video

한 장 = frame → 초당 몇 개의 frame이 전송되냐가 video를 구성

• video: sequence of images displayed at constant rate
• digital image: array of pixels
• pixels: each pixel represented by bits
• coding: 압축.

Streaming stored video:

streaming: downloading & processing at the same time

progressive download (old HTTP)

• old Youtube

client가 streaming 도중 화질을 전환하면 server에서 다시 download

(이미 다운 받은 만큼에 대한 bandwidth 낭비)

Adaptive streaming (DASH)

• Youtube, Netflix, Hulu

한 파일을 여러 개의 chunk로 나눠 각각의 chunk를 다른 rate으로 인코딩

each chunk is encoded at diff. bit rate & stored at diff. URLs

Streaming multimedia: DASH

DASH: Dynamic, Adaptive, Streaming over Http

stored 된 영상들을 대상으로한 streaming

http protocol위에 DASH layer

• server

  divides video file into multiple chunks

  each chunk stored, encoded at different rates

  manifest file: provides URLs for different chunks

• client

  periodically measures server-to-client bandwidth

  consulting manifest, requests one chunk at a time

  chooses maximum coding rate sustainable given
  current bandwidth

  can choose different coding rates at different points
  in time (depending on available bandwidth at time)

---

Quiz

(57) 만일 내가 cook.edu이라는 회사를 만들었고, DNS 서버를 구축하였는데 그 서버의 hostname이 dns.cook.edu이고 IPv4 주소가 134.198.24.34이라고 가정할 경우, 어떤 DNS 서버에 어떤 RR을 저장해야 외부에서 고객들이 dns.cook.edu 라는 DNS 서버에 접근할수 있게되는가?

⇒ .edu TLD 서버에 (dns.cook.edu, 134.198.24.34)를 매핑하는 type A RR,

(cook.edu, dns.cook.edu)를 매핑하는 type NS RR

(58) 75번 슬라이드 OTT 사업자가 해결 해야하는 challenge 두 가지를 설명하시오.

⇒ 1. storage, network bandwidth를 해결한 server infra 구축 2. 클라이언트마다의 link capacity와 video 재생 quality가 다른 점

(1) 서버의 storage와 서버가 연결된 NW의 용량(BW)를 고려한 server infra 구축이 필요.

(2) 서비스를 사용하는 클라이언트들이 연결된 네트워크의 down link capacity (transmission rate)와 사용하는 디바이스의 품질이 각기 다른(heterogeneous)것을 고려해 서비스를 제공해야함.

(59) 위 (58)에서 각 문제를 해결할 방법으로 등장한 기술의 예를 드시오.

⇒ 1. Content Distribution Network를 따로 구축한다. 2. DASH:파일을 chunk 단위로 나누어 각각을 다르게 인코딩하며 다른 서버에 저장한다.

OTT 사업자의 가입자 수 및 분포 등의 통계를 고려하여 서버 인프라를 지원하기 위한 네트워크(라우터와 링크)를 함께 구축하는 CDN(Content distribution/delivery network)이 등장하였으며, 각 클라이언트들의 장비품질, access network의 download link 속도의 이질성, 시간대별 망 상황의 변이 등을 고려하여 컨텐츠를 제공/접근하는 스마트 application layer 프로토콜(DASH)이 등장하였음.

(60) Video-on-demand (VoD) 스트리밍 서비스를 제공하기 위한 DASH 프로토콜의 서버 동작을 4단계로 나눠서 설명하시오

⇒

(1) 각 비디오를 일정 크기의 "chunk"로 나누고,

(2) 여러 가지 bitrate로 (혹은 다양한 품질별로) encoding하여

(3) 각 다른 URL에 (분산하여) 저장한 후,

(4) 그 내용을 manifest 파일에 저장하여 client에게 알려준다.

(61) 위한 DASH 프로토콜의 서버가 video의 각 chunk들을 다양한 bit rate로 인코딩하는 이유 2개를 적으시오. 즉, 클라이언트의 어떤 2가지 측면을 고려한 것인가?

⇒ 1. 클라이언트 마다 요구하는 화질이 다른 점, 2. network link capacity가 다른 점

(1) 클라이언트들의 playing device 품질이 다름(어떤 클라이언트는 고품질 IPTV에서 시청하고, 어떤 클라이언트는 저품질 PC에서 시청할 수 있기때문에)을 고려.

(2) 각 클라이언트들의 access network의 downlink 속도가 다르며, 혹은 클라이언트가 어떤 시간에 playing하느냐에 따라 core network의 지연도 달라질 수 있다는 것을 고려.