Lecture 016 - CDN

Internet Content Delivery

How to map human-readable names (URLs) to server locations (IPs)? How to deliver content quickly & reliably?

DNS Architecture

DNS Tree

Routers don't route domain name, instead they route IP Address.

Challenges/Goals:

• Scalability

• Decentralized maintenance

• Robustness

• Global scope

DNS trades off consistency for all these goals

The DNS Hierarchy: a tree

• zones: subtree, managed by organization

• We will assume RRs store a (domain name, IP) tuples

• For leaf nodes: mapping is for a device (host, server, ..)

• For interior nodes: mapping is the name server of the domain

DNS Queries

The DNS protocol: RPC queries and responses

• Send by UDP (not TSL+TCP)

• UDP packets are not encrypted (optimized for response time), therefore a spy can know what a computer wants to talk to, which is bad.

• UDP is not reliable

• Now, some DNS server support TSL encryption

Client Side

• Resolver (kernel code) software on hosts

• Local DNS runtime server(s)

  • It answer DNS queries about the local zone
  • It does lookup of distant host names for local hosts from cache (for local machines)

• Caching: since website popularity follows long time distribution

  • Quick response for repeated translations
  • Reduces load on servers
  • Negative queries are also cached: since people's mistake is also long tail distribution
  • Cached DNS entries expired based on a Time-To-Live (TTL): caching time controlled by the domain name owner // QUESTION: malicious TTL?
    • Owner's responsibility: don't make frequent change if you set a large TTL (server may not be reachable)
    • Leaf's responsibility: actually follow what your parent node tells you to flush cache

Clients learn the local DNS server’s address via the host configuration protocol (DHCP)c

Recursive DNS Query: the DNS server always return a correct address, it does so by sending query from itself to other lower DNS servers.

Iterative DNS Query: the DNS server can response null answer, saying it does not know the answer, and let the client to query for lower level DNS.

In reality, there isn't a defined protocol. But generally, root servers uses iterative (lazy) strategy and leaf servers uses recursive (helpful) strategy.

Root Server: There are: $13$ root name servers (internally replicated and geographically replicated), currently {a-m}.root-servers.net. // QUESTION: what is the point of replicating root server? will ISP redirect your DNS request if it go down? we have to trust our ISP don't maliciously modify to bad DNS? Malicious DNS attack by faking package?

• you don't want to randonly ask people for name translation since people can be malicious

Content Distribution Network (CDNs)

Websites have typically small "object" (jpg, mp3, ...) per page, and file sizes are heavy-tailed.

Each object needs: - 3-way handshake TCP - TLS encryption - Solution: HTTP2 & HTTP3 allows query in parallel // QUESTION: what do they solve, how

Content Delivery Network (CDNs):

• The world’s largest distributed caching systems

• CDNs will carry 71% of Internet traffic in 2021, up from 52% in 2016.

Questions:

• Where and how to replicate content

• How to direct clients towards a specific CDN instance

• How to choose a CDN server within a CDN instance

• How to propagate updates (CDN cache consistency)

pull-based cache

1. check cache in local machine
2. if cache miss, pull from CDN
3. CDN check cache in local machine
4. if cache miss, pull from content provider

push-based cache: content provider can push to CDN

DNS-based Routing

• high-level name server: large TTL, return NS-record (a DNS record that contains the name of the authoritative name server within a domain or DNS zone)

• low-level name server: small TTL, choose specific caching server within its instance

Load-balancer:

• round robin load balancer:

  • idea: spread load evenly across server
  • problem: We don't know how much load a request/working will give to server. Some working set are small, some are big.

• static partition:

  • idea: partition load based on request URL (e.g. separate www.kokecacao.me with arknights.kokecacao.me)
  • problem: non-uniform request URL

• hash-based partition

  • idea: hash URL and then spread. If we have $4$ server, then we give request www.kokecacao.me to server id www.kokecacao.me $\mod 4$
  • problem: adding, removing server is hard, since all servers need to re-cache when adding a server

• consistent hashing

  • idea: special type of hashing that can resize table without shuffling all entries.

Consistent Hashing

• Idea:

  • Each server has a server name $S$, each request has a representation $R$
  • We design a hash function that hash things to a continuous space, say from $[0, 1)$
  • We hash server name $hash : S -> hash$, and hash representation $hash : R -> hash$.
  • The server with $hash(S)$ greater than $hash(R)$ should be responsible for the request $R$. (if no server is greater, we wrap around, forming a ring)

• Performance: on average only $\frac{1}{n}$ of entries will be moved when adding and removing node (where $n$ is total number of nodes)

• Problem

  • If two server hashed to a very close location, one server will handel no data
  • Even with server evenly spaced, removing a node will cause one node's load twice has high

• Solution: each server can have multiple "virtual node"

• Popularity: Amazon DynamoDB, Apache Cassadra, CDN

Typically, when we have multiple load-balancer, we need to hash all packet of one connection to the same server. So usually ip address and port number is used for hashing. This ensure packets of one connection always go to one server even with different Maglev balancer. Consistent hashing reduces the chance of a connection being sent to a different web server after a single server failure, relative to a naive hash-load balancer.

CDN Update Propagation:

• static web object: 1st generation CDN 1998

  • images, static website, css js
  • consistency via TTL set by content owner

• dynamic content: 2nd generation CDN 2010

  • dynamic web content at edge
  • most pages are dynamic

• edge application: today

  • application run on edge servers
  • paxos-based data replication

Akamai: Akamai is the leading content delivery network (CDN) services provider for media and software delivery, and cloud security solutions. evolved out of MIT research on consistent hashing. It serves 15-30% of all Internet traffic, with 170K servers worldwide.

Other solutions: CloudFront, CloudFlare, Fastly, ChinaNet, Edgecast, Limelight, Lvl3, GCD

Current developments: as of 2022

• Optimizing resource consumption

• Automation in performance tuning

• Large content providers deploy their own CDNs

• Many open problems (performance and security)

Takeaway: caching is the only way to improve latency