Method and apparatus for determining latency between multiple servers and a client

• US 7,058,706 B1
• Filed: 09/07/2000
• Issued: 06/06/2006
• Est. Priority Date: 03/31/2000
• Status: Expired due to Term

• Current Assignee: Akamai Technologies, Inc.
• Original Assignee: Akamai Technologies, Inc.
• Inventors: Iyer, Shankar, Lanka, Sridhara
• Primary Examiner(s): Vaughn, Jr., William C.
• Assistant Examiner(s): ENGLAND, DAVID E
• Application Number:
  US09/657,016
• Time in Patent Office: 2,098 Days
• Field of Search: 709220-232, 709238-244, 710/11
• US Class Current: 709/223
• CPC Class Codes: H04L 43/0852 Delays
• CPC Class Codes: H04L 45/12 Shortest path evaluation
• CPC Class Codes: H04L 45/121 by minimising delays
• CPC Class Codes: H04L 61/35 involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
• CPC Class Codes: H04L 61/45 Network directories; Name-to-address mapping
• CPC Class Codes: H04L 69/16 Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
• CPC Class Codes: H04L 69/161 Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields

Abstract

A method and apparatus for determining latency between multiple servers and a client receives requests for content server addresses from local domain names servers (LDNS). POPs that can serve the content are determined and sent latency metric requests. The content server receives the request for latency metrics and looks up the latency metric for the requesting client. Periodic latency probes are sent to the IP addresses in a Latency Management Table. The IP addresses of clients are masked so the latency probes are sent to higher level servers to reduce traffic across the network. The hop count and latency data in the packets sent in response to the latency probes are stored in the Latency Management Table and is used to determine the latency metric from the resident POP to the requesting client before sending the latency metric to the requesting server. The BGP hop count in the Latency Management Table is used for the latency metric upon the first request for an IP address. The latency metric is calculated for subsequent requests of IP addresses using the hop count and RTT data in the Latency Management Table. Latency metrics from POPs are collected and the inverse relationship of the hop counts in a weighted combination with the RTT are used to determine which latency metric indicates the optimal POP. The address of the optimal POP is then sent to the requesting LDNS.

Claims

1. A process for determining latency between multiple servers and a client across a network in a computer environment, comprising the steps of:

receiving a request for a content server address from said client;

sending a latency metric request from a server to an appropriate probe server;

receiving a request for latency metrics on a probe server;

wherein said latency metric request specifies a particular client;

wherein a latency management table initially comprises a list of IP addresses along with corresponding Border Gateway Protocol (BGP) hop counts;

looking up the latency metric for said client in said latency management table;

sending said latency metric to the requesting server;

receiving latency metric data from said probe server at the requesting server;

determining an optimal content server for said client using said latency metric data;

sending said optimal content server'"'"'s address to said client;

wherein only the BGP hop count for said client in said latency management table is used for said latency metric upon an initial request for said client; and

wherein the probe server determines a dynamic hop count and Round Trip Time (RTT) data for said client after the initial request enters the dynamic hop count and RTT information into said latency management table, and uses the dynamic hop count and RTT information for said latency metric for subsequent requests for said client.

2. The process of claim 1, further comprising the steps of:

sending periodic latency probes to the IP addresses in said latency management table;

receiving response packets for said latency probes; and

recording the dynamic hop count and latency (RTT) data in said latency management table.

3. The process of claim 2, wherein periodic latency probes are sent to a higher level server of a client by masking said client'"'"'s IP address in said latency management table.

4. The process of claim 1, wherein said determining step gathers the expected latency metrics and uses the inverse relationship of the dynamic hop counts in said latency metric data in a weighted combination with the RTT in said latency metric data to determine which latency metric data indicates the optimal content server.

5. An apparatus for determining latency between multiple servers and a client across a network in a computer environment, comprising:

a module for receiving a request for a content server address from said client;

a module for sending a latency metric request from a server to an appropriate probe server;

a module for receiving a request for latency metrics on a probe server;

wherein said latency metric request specifies a particular client;

a latency management table;

wherein said latency management table initially comprises a list of IP addresses along with corresponding Border Gateway Protocol (BGP) hop counts;

a module for looking up the latency metric for said client in said latency management table;

a module for sending said latency metric to the requesting server;

a module for receiving latency metric data from said probe server at the requesting server;

a module for determining an optimal content server for said client using said latency metric data;

a module for sending said optimal content server'"'"'s address to said client;

wherein only the BGP hop count for said client in said latency management table is used for said latency metric upon an initial request for said client; and

wherein the probe server determines a dynamic hop count and Round Trip Time (RTT) data for said client after the initial request, enters the dynamic hop count and RTT information into said latency management table, and uses the dynamic hop count and RTT information for said latency metric for subsequent requests for said client.

6. The apparatus of claim 5, further comprising:

a module for sending periodic latency probes to the IP addresses in said latency management table;

a module for receiving response packets for said latency probes; and

a module for recording the dynamic hop count and latency (RTT) data in said latency management table.

7. The apparatus of claim 6, wherein periodic latency probes are sent to a higher level server of a client by masking said client'"'"'s IP address in said latency management table.

8. The apparatus of claim 6, wherein said determining module gathers the expected latency metrics and uses the inverse relationship of the dynamic hop counts in said latency metric data in a weighted combination with the RTT in said latency metric data to determine which latency metric data indicates the optimal content server.

9. A program storage medium readable by a computer, tangibly embodying a program of instructions executable by the computer to perform method steps for determining latency between multiple servers and a client across a network in a computer environment, comprising the steps of:

receiving a request for a content server address from said client;

sending a latency metric request from a server to an appropriate probe server;

receiving a request for latency metrics on a probe server;

wherein said latency metric request specifies a particular client;

wherein a latency management table initially comprises a list of IP addresses along with corresponding Border Gateway Protocol (BGP) hop counts;

looking up the latency metric for said client in said latency management table;

sending said latency metric to the requesting server;

receiving latency metric data from said probe server at the requesting server;

determining an optimal content server for said client using said latency metric data;

sending said optimal content server'"'"'s address to said client;

wherein only the BGP hop count for said client in said latency management table is used for said latency metric upon an initial request for said client; and

wherein the probe server determines a dynamic hop count and Round Trip Time (RTT) data for said client after the initial request enters the dynamic hop count and RTT information into said latency management table, and uses the dynamic hop count and RTT information for said latency metric for subsequent requests for said client.

10. The method of claim 9, further comprising the steps of:

sending periodic latency probes to the IP addresses in said latency management table;

receiving response packets for said latency probes; and

recording the dynamic hop count and latency (RTT) data in said latency management table.

11. The method of claim 10, wherein periodic latency probes are sent to a higher level server of a client by masking said client'"'"'s IP address in said latency management table.

12. The method of claim 9, wherein said determining step gathers the expected latency metrics and uses the inverse relationship of the dynamic hop counts in said latency metric data in a weighted combination with the RTT in said latency metric data to determine which latency metric data indicates the optimal content server.