Anycast by DNS over pure IPv6 network

Anycast by DNS over pure IPv6 network Minghua Chen & Wei Mao EECS, UC, Berkeley {minghua, maowei}@eecs

Outline • Introduction • Anycast • Anycast by modifying DNS service over pure IPv6 Network • WTRT server selection Model • Conclusions • Acknowledgement

Introduction • Internet grows dramatically • Exponential growth • In 1999, every 10 seconds, a new pc connects to Internet • Distributed information services face a number of problems of scale • excessive server load • wasted bandwidth • excessive latency

The growth of Internet 460 Million users Source: Cerf, based on www.nw.com, Jan 2000

Server replication & caching • Relatively straightforward method to potentially improve client performance and reduce network load • A key issue in realizing such techniques is how to find the best provider of that service • What is difference between the performance of the best case and the worst case scenario?

Performance variance

What is the relation to our topic? • We believe that anycast service is the right way to do “best” server selection. • Combining anycast service and server replication, the scale problems of distributed information services can be resolved

Concept Of Anycast • Original definition:a stateless best effort delivery of an anycast datagram to at least one host, and preferably only one host, which serves the anycast address. • Here, anycast is a communication paradigm service, which connect the client to the “nearest” node in a set of nodes that have some same properties

Anycast Illustration Typically, client chooses a nearby server.

Anycast realization • Network-layer anycast • Routing to the nearest server using routing distance metric • Comments • Straightforward idea, hard to implement • Need to modified router • Lack of flexibility in selection criteria

Anycast realization (cont.) • Application layer anycast • Query with a name and a client address. Returns the unicast address of the “best” server • Comments • Does not involve modifying router • Flexible selection criteria • Need periodically collect information

Why we choose application layer implementation? • Implementation Simplicity • Flexible selection criteria • e.g. Server load • More appropriate selection criteria • Network layer: Hop count only is not a good metric for node selection • Application layer: can use other significant information than hop count as metric

Hop count is a poor predictor of performance Hop counts RTT

Problem translation • In application-layer anycast • providing anycast service  selecting the “best” server given necessary information • These information may include • Server load • Latency • Available bandwidth • Client preference

Current server selection schemes • Assign server to a client using round-robin method • Balancing server load • NSCA WWW servers use it • Geographically server assignment • Predicted transfer time (PTT) model or similar model

These schemes are not good enough • Server load • Server load has impact on response latency • Retransmission cost • e.g. Congestion • Traffic segregation according to network topology • Keep traffic “local”– principle of scaling

Why by modifying DNS • One concern of application-layer anycasting • Require bootstrap mechanism • DNS query is almost an essential step to access Internet services • By quiz • By experience • Is one time query enough for an Internet connection?

The probability of the server’s rank change > 4 is 0.15 Optimal selection changes fairly slowly

Why over pure IPv6 network • We believe that IPv6 will be an important competitor of the next generation IP protocol • IPv6 adopts anycast • IPv6 provides strictly aggregated address space • What will happen in this case?

Our work: Propose the server selection criteria • Goal is to select the “nearest” server. • Possible distance measures: • lantency, server load, available bandwidth, etc. • propose Weighted Total Response Time (WTRT) • TRT is measured from the time the IP request is sent to the time the whole document is received • The less WTRT, the better • Why? Keen to user’s perspective of QoS

Formulation of WTRT • Express WTRT as the following: • Key elements: • w: segregation weight • Latency: time elapsed from request to start of receiving document • E[packets]: expected total number of packets considering loss and retransmission • P_size: average size of TCP packet • BW: available bandwidth of the link path • K1 and k2: constant coefficients to be determined

Segregation Weight (SW) ?

SW (cont.) • Weight the server within the same subnet less in order to avoid traffic through backbone • Key issue: how to know c/s are in the same subnet???

SW (cont.) • In IPv6 addresses are strictly aggregated  • Do longest prefix matching using c/s IP addresses, similar to the algorithm used in CIDR routing • the longer matched prefix, the more “local” the server is to the client

W4 W1<W2<W3<W4 Details of SW W1 W2 W3

Details of SW (cont.) • Value of SW should be the same for the same level of aggregation • Who determine the SW? • SW could be determined at the authorized DNS server for a particular domain name • SW could be applied by local DNS server on the query results, in order to realize policy flow balance control • Encourage/discourage outgoing flow

Latency • How it affect the TRT • Small latency lead to fast response from server. • When document size is small, this dominates the document retrieve time • What determine latency • Current server load • Current link load and link characteristics

How to estimate latency? • Fei et al proposed a hybrid server push/probe scheme to estimate the latency from a client to a server • Their simulation results show that the scheme works fairly well

Available Bandwidth • How it affect the TRT: • Higher bandwidth leads to faster document transfer • What determines the available bandwidth: • The capacity of the c/s path • Present traffic on the path

Available Bandwidth (cont.) • How to estimate it: • R. L Carter proposed bandwidth probing (BPROBE) algorithm to estimate the total capacity • Also proposed CPROBE algorithm to estimate the current traffic • Their results provide a reasonable ground for other existing researches

Packet Loss & Retransmission • Assume: • K original packets need to be transmitted • p is the steady-state packet loss rate. • Packets lost are retransmitted only once. • Binomial model of the # of retrans. Packets leads to E[packets]=K(1+p). • The total size of the document transmitted becomes E[packets]*P_size. • Average size of TCP packet is 403 bytes.

K1 And K2 • Why K1 and K2? • Linear model • How to determine K1 and K2 • By client preference • small document size  larger ratio of K1 / K2 • large document size  smaller ratio of K1 / K2 • By regression method

Comparison to PTT model • WTRT is derived from PTT but more extensive • WTRT • PTT

PTT WTRT An example Heavy server load

Modified DNS query procedure

Modified DNS query procedure (cont.) • Client IP address and preference are sent between DNS servers • DNS server may return several IP addresses to client for further selection • SW can be determined at authorized DNS server or local DNS server • Periodically, the authorized DNS server gather information from server and probes to update its database

Conclusions • Server selection + anycast service = solution to the problems of scaling of distributed information services • Application layer anycasting has more advantage over network layer anycasting • In application layer anycasting • providing anycast service  selecting the “best” server given server and link characteristics

Conclusions (cont.) • Anycast by modifying DNS service provide an easy bootstrap mechanism • In IPv6, strictly aggregated address space can facilitate segregating traffic according to network topology • WTRT model is more reasonable and extensive than PTT model

Acknowledgement • Jim Guyton @ Apple Co. for some discussion on traffic segregation • F. Yu and L. Yin for the development of the initial idea Thank you very much for your attention !

Anycast by DNS over pure IPv6 network