WO2001076182A2 - Method and apparatus for determining latency between multiple servers and a client - Google Patents

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

Info

Publication number
WO2001076182A2
WO2001076182A2 PCT/US2001/010524 US0110524W WO0176182A2 WO 2001076182 A2 WO2001076182 A2 WO 2001076182A2 US 0110524 W US0110524 W US 0110524W WO 0176182 A2 WO0176182 A2 WO 0176182A2
Authority
WO
WIPO (PCT)
Prior art keywords
latency
client
management table
metric
rtt
Prior art date
Application number
PCT/US2001/010524
Other languages
French (fr)
Other versions
WO2001076182A3 (en
Inventor
Shankar Iyer
Sridhara Lanka
Original Assignee
Speedera Networks, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Speedera Networks, Inc. filed Critical Speedera Networks, Inc.
Priority to AU2001247925A priority Critical patent/AU2001247925A1/en
Publication of WO2001076182A2 publication Critical patent/WO2001076182A2/en
Publication of WO2001076182A3 publication Critical patent/WO2001076182A3/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/121—Shortest path evaluation by minimising delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/35—Network arrangements, protocols or services for addressing or naming 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping

Definitions

  • the invention relates to the routing of requests to a networked server in a computer environment. More particularly, the invention relates to determining a dynamic hop count between two nodes across a network in a computer environment.
  • the Internet is a confederation of loosely connected networks that connect computers all around the world.
  • Information is mirrored on multiple servers in order to improve performance, availability, and scalability.
  • clients requesting information need to be routed to the optimal server.
  • the traffic management industry routes traffic to the optimal server using different latency metrics including the Round Trip Time (RTT) and hop count.
  • RTT Round Trip Time
  • hop count The Round Trip Time measures the time it takes for a packet to travel between a server and a client or another server.
  • the dynamic hop count between a client and a server is typically derived from the Border Gateway Protocol (BGP).
  • BGP Border Gateway Protocol
  • BGP gives the hops between different Autonomous System Numbers (ASN).
  • ASN Autonomous System Numbers
  • the dynamic hop count can be used to differentiate latency metrics that might be close in terms of RTT.
  • the primary function of a BGP speaking system is to exchange network reachability information with other BGP systems.
  • the network reachability information includes information on the Autonomous Systems (AS) that the reachability information traverses.
  • AS Autonomous Systems
  • a BGP speaker advertises to its peers, i.e., other BGP speakers that it communicates with, in neighboring ASs only those routes that it uses.
  • the information is sufficient to construct a graph of AS connectivity from which routing loops may be pruned.
  • BGP hops The actual number of hops will typically be larger than that advertised by the BGP protocol since BGP only gives the hops between the ASNs.
  • IP hops Getting hop counts from the Internet Protocol (IP) is difficult because the Time To Live (TTL) field that is part of the IP header is not initialized to standard values by the various TCP/IP stack software running on various Operating Systems, e.g., Windows 98, Linux, NT, etc.
  • TTL Time To Live
  • the invention described in this patent provides a different and more precise method of determining the dynamic hop count. It would be advantageous to provide a method and apparatus for determining latency between multiple servers and a client that provides a more precise method of determining dynamic hop counts. It would further be advantageous to provide a method and apparatus for determining latency between multiple servers and a client that reduces the traffic required to measure the hops across the network.
  • the invention provides a method and apparatus for determining latency between multiple servers and a client.
  • the system provides a more precise method of determining dynamic hop counts and optimal content servers.
  • the invention reduces network traffic required for measuring the dynamic hop counts.
  • a preferred embodiment of the invention 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.
  • LDNS local domain names servers
  • the content server receives the request for latency metrics and looks up the latency metric for the client of the requesting LDNS.
  • 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.
  • the information in the Latency Management Table 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.
  • Fig. 1 is a block schematic diagram of a preferred embodiment of the invention measuring latency between servers and a client according to the invention
  • Fig. 2 is a block schematic diagram of an example of a preferred embodiment of the invention measuring dynamic hop counts from two POPs to a Border Gateway server according to the invention
  • Fig. 3 is a diagram of a Latency Management table according to the invention.
  • Fig. 4 is a block schematic diagram of an example of differing TTL values in IP packets according to the invention.
  • Fig. 5 is a block schematic diagram of the inverse relationship of dynamic hop counts in a preferred embodiment of the invention according to the invention.
  • Fig. 6 is a block schematic diagram of a task-level viewpoint of a preferred embodiment of the invention according to the invention.
  • the invention is embodied in a method and apparatus for determining latency between multiple servers and a client in a computer environment.
  • a system according to the invention provides a more precise method of determining dynamic hop counts and optimal content servers.
  • the invention provides a system that reduces network traffic required for measuring the dynamic hop counts.
  • the invention provides a new method to determine the dynamic hop count between two nodes (client and server). This new method provides a dynamic hop count that is more precise than the hop count obtained using the Border Gateway Protocol (BGP).
  • Border Gateway Protocol BGP
  • the latency probes in a Speedera Network are responsible for determining the latency between the Speedera servers and a client. This latency information is used by the Speedera Domain Name Server (SPDNS) to direct a client to the server that is "closest" to the client in latency.
  • SPDNS Speedera Domain Name Server
  • each Speedera Point of Presence (POP) 101 , 102 has a probe server 104, 106 and other infrastructure servers 103, 105.
  • the Client 109 receives a request, it tries to resolve the request from the Local Domain Name Server (LDNS) 108. If the LDNS 108 cannot resolve the request, it forwards the request to the Speedera Domain Name Server (SPDNS) 107.
  • the SPDNS 107 then routes the request to the optimal POP 101 , 102 by determining the server "closest" to the LDNS 108.
  • the Client 109 performs a name lookup for web content images.rich.com/images 110.
  • the local DNS (LDNS) client 108 forwards the request 111 to the SPDNS 107.
  • the SPDNS 107 requests latency information 1 12, 1 13 from the Speedera probes 104, 106 at locations that can serve images.rich.com (POP1 101 and POP2 102).
  • the latency probes 104, 106 initiate probes 1 17, 1 18 to the LDNS 108.
  • the latency probes 104, 106 return the latency metrics 1 15, 1 16 to the SPDNS 107.
  • the main components that are used by the invention to determine latency metrics are as follows:
  • ASN Autonomous System Number
  • BGP Border Gateway Protocol
  • BGP is a standard algorithm implemented in routers. It is a routing protocol that is used between large routers covering large administrative domains. All routes that are available within a network are exported to another network in an abbreviated form.
  • the network reachability information includes information on the Autonomous Systems (AS) that the reachability information traverses.
  • AS Autonomous Systems
  • a BGP speaker advertises to its peers, i.e., other BGP speakers that it communicates with, in neighboring ASs only those routes that it uses.
  • An AS is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASs.
  • the latency probe uses a UDP Reverse Name Lookup and Traceroute to determine RTT and dynamic hop count.
  • Reverse Name Lookup is a standard DNS query that specifies a client IP address and asks for the client name.
  • Traceroute is a specific format of a packet that is sent between routers to indicate if a packet has reached a destination.
  • POP1 201 and Pop2 202 must each find the distance from themselves to the ASN 203.
  • the latency for each path must also be found.
  • the distance and latency are calculated by using the hop count and latency time, respectively.
  • the invention aggregates the client 208 and the DNS 207 and assumes that they are co-located. Additionally, the latency and the hop counts are measured up to the Border Gateway (BG) 206. Once the autonomous system is entered, the hop counts are not as important.
  • the distance from the BG 206 to the client 208 is the same from either POP 201 , 202 at that point. Therefore, the relevant distance is to the BG 206. In other words, the distance T1 210 and T2 211 are most likely not equal, but the distance T3 212 is the same for both POPs 201 , 202.
  • the address of the client 208 is masked to the IP prefix of the ASN 203. For example, if the address of the client 208 is 4.10.20.30 then the address is masked to the ASN 203 which is 4.0.0.0.
  • the mask can vary depending on the granularity desired. For example, the first eight bits may be masked to the DNS, i.e., the address would then be masked to 4.10.20.00. This can be adjusted depending on the size of the network.
  • the data in the BGP table does not change over a period of time. Incremental updates are sent as the routing tables change. However, BGP does not require periodic refresh of the entire BGP routing table. Therefore, a BGP speaker must retain the current version of the entire BGP routing tables of all of its peers for the duration of the connection.
  • the invention performs its measurements a few times a day to achieve a good picture of the network status.
  • the invention reduces Internet traffic by aggregating at a higher level and therefore requires less probes.
  • a latency management table is used by the invention.
  • the table contains the following fields: IP address 301 ; BGP hop count 302; and Trace data 303.
  • IP address field 301 contains the IP addresses that the server is responsible for.
  • BGP hop counts 302 is taken from the BGP routing table for the particular IP address.
  • the Trace data field 303 contains the latency and hop count information obtained by the latency probes.
  • the BGP hop count 302 is used by the SPDNS when the first request from an LDNS comes in for a particular IP address. No previous connection has been established at this point. This is because the dynamic hop count to the BG takes some time to actually measure. Subsequent requests use the actual BG hop count measured by the system located in the Trace field 303. The latency measurement is also taken and the combination of the hop count and latency measurement in the Trace field 303 is used to determine which SPDNS is closest to the client.
  • the invention does not need to get absolute hop counts from the various probe servers to the LDNS. It is sufficient to determine the relative hop counts between the probe servers and the LDNS and use this information in arriving at relative latency metrics between the client and the probe servers. This information can then be used by the Speedera DNS to choose between the service points and locate a server that is closest to the client. With respect to Fig. 4, the invention is based on the very safe assumption that the target LDNS 402 will always send out packets with a fixed TTL independent of the SPDNS 401 that initiated a probe.
  • IP Internet Protocol
  • TTL Time To Live
  • the SPDNS 401 originates a packet with a TTL of 64 403.
  • the LDNS 402 always sends out packets with its own independent TTL value of 128 404. DNS's will send whatever TTL value that they prefer. The values may differ between each DNS, but each DNS is consistent in its TTL value.
  • the two probe servers (Probel 502 and Probe2 503) have initiated probes to the LDNS 501.
  • the LDNS 501 returns a response to each of the probe servers.
  • the LDNS 501 sets the TTL in the response IP packet to R 504, 505.
  • the TTL will be decremented by 1 each time the packet passes through a router (hop).
  • the packets go through H1 hops 506 between LDNS 501 and Probel 502 and H2 hops 507 between LDNS 501 and Probe2 503.
  • the TTL of the response packet that arrives at Probel 502 will be
  • the latency metric is a weighted combination of the RTT and the hop count.
  • the latency metric is used to determine the server that is the most efficient for accessing a client.
  • the invention precisely determines the hop count metric between client and server.
  • the dynamic hop count metric derived through the invention is more accurate than the hop count derived from BGP. As a result, requests will be routed more accurately to the optimal server resulting in improved performance.
  • the invention improves performance in multiple Internet infrastructure products including performance monitoring, WAN traffic management, and content distribution.
  • a task level viewpoint of the invention is shown.
  • Requests for content server addresses from LDNS's are received by the Receive IP Address Request module 605.
  • the Receive IP Address Request module 605 sends the content request to the Request Latency Metrics module 606.
  • POPs that can serve the content are retrieved from the Server Table 609 by the Request Latency Metrics module 606.
  • the Request Latency Metrics module 606 then sends latency metric requests to the POPs that can serve the content and notifies the Determine Optimal Server module 608 that latency metrics are expected.
  • Request for latency metrics activate the Send Latency Metric module 601 to lookup the latency metric for the requesting LDNS's client.
  • the Send Latency Probe module 603 sends latency probes to the IP addresses in the Latency Management Table 604. The IP addresses of clients are masked so the latency probes are sent to higher level servers as detailed above. Packets sent in response to the latency probes sent by the Send Latency Probe module 603 are received by the Receive Response Packet module 602. Hop count and latency data are stored into the Latency Management Table 604.
  • the Send Latency Metric module 601 uses the information in the Latency Management Table 604 to determine the latency metric from the resident POP to the requesting LDNS's client before sending the latency metric to the requesting server.
  • the Send Latency Metric module 601 uses the BGP hop count in the Latency Management Table 604 for its calculations upon the first request for an IP address.
  • the latency metric is calculated for subsequent requests of IP addresses by the Send Latency Metric module 601 using the hop count and RTT data obtained from the Receive Response Packet module 602. Latency metrics from POPs are received by the Receive Latency Metrics module 607.
  • the latency metrics are sent to the Determine Optimal Server module 608.
  • the Determine Optimal Server module 608 gathers the expected latency metrics and uses the inverse relationship of the hop counts in a weighted combination with the RTT to determine which latency metric indicates the optimal POP. The Determine Optimal Server module 608 then sends the address of the optimal POP to the requesting LDNS.

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 are 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.

Description

Method and Apparatus for Determining Latency Between Multiple Servers and a Client
CROSS-REFERENCES TO RELATED APPLICATIONS
The present application claims priority to U.S. Provisional Application No. 60/193,988 filed March 31 , 2000 (Attorney Docket No. 4878-US); and U.S. Patent Application No. 09/657,016 filed September 7, 2000(Attorney Docket No. UDN0003), commonly owned, and hereby incorporated by reference for all purposes.
BACKGROUND OF THE INVENTION
TECHNICAL FIELD
The invention relates to the routing of requests to a networked server in a computer environment. More particularly, the invention relates to determining a dynamic hop count between two nodes across a network in a computer environment.
DESCRIPTION OF THE PRIOR ART
The Internet is a confederation of loosely connected networks that connect computers all around the world. The proliferation of information and immense user population has made the management of information critical. Information is mirrored on multiple servers in order to improve performance, availability, and scalability. To facilitate the mirroring of information, clients requesting information need to be routed to the optimal server. The traffic management industry routes traffic to the optimal server using different latency metrics including the Round Trip Time (RTT) and hop count. The Round Trip Time measures the time it takes for a packet to travel between a server and a client or another server.
The dynamic hop count between a client and a server is typically derived from the Border Gateway Protocol (BGP). BGP is specified in RFC 1267 published in October 1991 and RFC 1654 published in July 1994. BGP gives the hops between different Autonomous System Numbers (ASN). The dynamic hop count can be used to differentiate latency metrics that might be close in terms of RTT.
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. The network reachability information includes information on the Autonomous Systems (AS) that the reachability information traverses. A BGP speaker advertises to its peers, i.e., other BGP speakers that it communicates with, in neighboring ASs only those routes that it uses. The information is sufficient to construct a graph of AS connectivity from which routing loops may be pruned.
Determining the dynamic hop count is currently problematic due to the following reasons:
1. BGP hops: The actual number of hops will typically be larger than that advertised by the BGP protocol since BGP only gives the hops between the ASNs.
2. IP hops: Getting hop counts from the Internet Protocol (IP) is difficult because the Time To Live (TTL) field that is part of the IP header is not initialized to standard values by the various TCP/IP stack software running on various Operating Systems, e.g., Windows 98, Linux, NT, etc.
The invention described in this patent provides a different and more precise method of determining the dynamic hop count. It would be advantageous to provide a method and apparatus for determining latency between multiple servers and a client that provides a more precise method of determining dynamic hop counts. It would further be advantageous to provide a method and apparatus for determining latency between multiple servers and a client that reduces the traffic required to measure the hops across the network.
SUMMARY OF THE INVENTION
The invention provides a method and apparatus for determining latency between multiple servers and a client. The system provides a more precise method of determining dynamic hop counts and optimal content servers. In addition, the invention reduces network traffic required for measuring the dynamic hop counts.
A preferred embodiment of the invention 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 client of the requesting LDNS. 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.
The information in the Latency Management Table 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.
Other aspects and advantages of the invention will become apparent from the following detailed description in combination with the accompanying drawings, illustrating, by way of example, the principles of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a block schematic diagram of a preferred embodiment of the invention measuring latency between servers and a client according to the invention;
Fig. 2 is a block schematic diagram of an example of a preferred embodiment of the invention measuring dynamic hop counts from two POPs to a Border Gateway server according to the invention;
Fig. 3 is a diagram of a Latency Management table according to the invention;
Fig. 4 is a block schematic diagram of an example of differing TTL values in IP packets according to the invention;
Fig. 5 is a block schematic diagram of the inverse relationship of dynamic hop counts in a preferred embodiment of the invention according to the invention; and
Fig. 6 is a block schematic diagram of a task-level viewpoint of a preferred embodiment of the invention according to the invention. DETAILED DESCRIPTION OF THE INVENTION
The invention is embodied in a method and apparatus for determining latency between multiple servers and a client in a computer environment. A system according to the invention provides a more precise method of determining dynamic hop counts and optimal content servers. In addition, the invention provides a system that reduces network traffic required for measuring the dynamic hop counts.
The invention provides a new method to determine the dynamic hop count between two nodes (client and server). This new method provides a dynamic hop count that is more precise than the hop count obtained using the Border Gateway Protocol (BGP).
The latency probes in a Speedera Network are responsible for determining the latency between the Speedera servers and a client. This latency information is used by the Speedera Domain Name Server (SPDNS) to direct a client to the server that is "closest" to the client in latency.
Referring to Fig. 1 , each Speedera Point of Presence (POP) 101 , 102 has a probe server 104, 106 and other infrastructure servers 103, 105. When the Client 109 receives a request, it tries to resolve the request from the Local Domain Name Server (LDNS) 108. If the LDNS 108 cannot resolve the request, it forwards the request to the Speedera Domain Name Server (SPDNS) 107. The SPDNS 107 then routes the request to the optimal POP 101 , 102 by determining the server "closest" to the LDNS 108.
In this example, the Client 109 performs a name lookup for web content images.rich.com/images 110. The local DNS (LDNS) client 108 forwards the request 111 to the SPDNS 107. The SPDNS 107 requests latency information 1 12, 1 13 from the Speedera probes 104, 106 at locations that can serve images.rich.com (POP1 101 and POP2 102). The latency probes 104, 106 initiate probes 1 17, 1 18 to the LDNS 108. The latency probes 104, 106 return the latency metrics 1 15, 1 16 to the SPDNS 107.
The main components that are used by the invention to determine latency metrics are as follows:
• RTT time from the latency probe to LDNS.
• ASN (Autonomous System Number) routing information derived from Border Gateway Protocol (BGP).
• Dynamic hop count from the latency probe to LDNS.
BGP is a standard algorithm implemented in routers. It is a routing protocol that is used between large routers covering large administrative domains. All routes that are available within a network are exported to another network in an abbreviated form. The network reachability information includes information on the Autonomous Systems (AS) that the reachability information traverses. A BGP speaker (router) advertises to its peers, i.e., other BGP speakers that it communicates with, in neighboring ASs only those routes that it uses. An AS is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASs.
The latency probe uses a UDP Reverse Name Lookup and Traceroute to determine RTT and dynamic hop count. Reverse Name Lookup is a standard DNS query that specifies a client IP address and asks for the client name. Traceroute is a specific format of a packet that is sent between routers to indicate if a packet has reached a destination.
Obtaining absolute hop counts is ideal, however, this is not a realistic goal in the real world. Quite often some of the local DNSs are unavailable because they are sitting behind a firewall or the DNS will drop the packet thinking that it is a denial of service attack. With these restrictions, it is not possible to reliably use an absolute hop count. Additionally, as described below, the IP packet information is not uniform throughout the network.
With respect to Fig. 2, most of the time the ASN 203 is easily reached. Even from various diverse points it is possible to converge onto the AS 203. However, it is the path required to reach the AS 203 from each server that is the important factor.
POP1 201 and Pop2 202 must each find the distance from themselves to the ASN 203. The latency for each path must also be found. The distance and latency are calculated by using the hop count and latency time, respectively.
Currently, it is only possible to measure hop count and latency time by sending a packet to the destination. However, as previously mentioned, most of the time the packet is sent back as not being able to reach the destination.
The invention aggregates the client 208 and the DNS 207 and assumes that they are co-located. Additionally, the latency and the hop counts are measured up to the Border Gateway (BG) 206. Once the autonomous system is entered, the hop counts are not as important. The distance from the BG 206 to the client 208 is the same from either POP 201 , 202 at that point. Therefore, the relevant distance is to the BG 206. In other words, the distance T1 210 and T2 211 are most likely not equal, but the distance T3 212 is the same for both POPs 201 , 202.
The address of the client 208 is masked to the IP prefix of the ASN 203. For example, if the address of the client 208 is 4.10.20.30 then the address is masked to the ASN 203 which is 4.0.0.0. The mask can vary depending on the granularity desired. For example, the first eight bits may be masked to the DNS, i.e., the address would then be masked to 4.10.20.00. This can be adjusted depending on the size of the network. The data in the BGP table does not change over a period of time. Incremental updates are sent as the routing tables change. However, BGP does not require periodic refresh of the entire BGP routing table. Therefore, a BGP speaker must retain the current version of the entire BGP routing tables of all of its peers for the duration of the connection.
The invention performs its measurements a few times a day to achieve a good picture of the network status. The invention reduces Internet traffic by aggregating at a higher level and therefore requires less probes.
Referring to Fig. 3, a latency management table is used by the invention. The table contains the following fields: IP address 301 ; BGP hop count 302; and Trace data 303. The IP address field 301 contains the IP addresses that the server is responsible for. BGP hop counts 302 is taken from the BGP routing table for the particular IP address. The Trace data field 303 contains the latency and hop count information obtained by the latency probes.
The BGP hop count 302 is used by the SPDNS when the first request from an LDNS comes in for a particular IP address. No previous connection has been established at this point. This is because the dynamic hop count to the BG takes some time to actually measure. Subsequent requests use the actual BG hop count measured by the system located in the Trace field 303. The latency measurement is also taken and the combination of the hop count and latency measurement in the Trace field 303 is used to determine which SPDNS is closest to the client.
The invention does not need to get absolute hop counts from the various probe servers to the LDNS. It is sufficient to determine the relative hop counts between the probe servers and the LDNS and use this information in arriving at relative latency metrics between the client and the probe servers. This information can then be used by the Speedera DNS to choose between the service points and locate a server that is closest to the client. With respect to Fig. 4, the invention is based on the very safe assumption that the target LDNS 402 will always send out packets with a fixed TTL independent of the SPDNS 401 that initiated a probe. Getting hop counts from the Internet Protocol (IP) is difficult because the Time To Live (TTL) field that is part of the IP header is not initialized to standard values by the various TCP/IP stack software running on various Operating Systems, e.g., Windows 98, Linux, NT, etc.
In this example, the SPDNS 401 originates a packet with a TTL of 64 403. The LDNS 402 always sends out packets with its own independent TTL value of 128 404. DNS's will send whatever TTL value that they prefer. The values may differ between each DNS, but each DNS is consistent in its TTL value.
Referring to Fig. 5, the two probe servers (Probel 502 and Probe2 503) have initiated probes to the LDNS 501. The LDNS 501 returns a response to each of the probe servers. Here, the LDNS 501 sets the TTL in the response IP packet to R 504, 505. The TTL will be decremented by 1 each time the packet passes through a router (hop). In this example, the packets go through H1 hops 506 between LDNS 501 and Probel 502 and H2 hops 507 between LDNS 501 and Probe2 503. The TTL of the response packet that arrives at Probel 502 will be
(R-H1) and which arrives at Probe2 503 will be (R-H2). The TTL of the response at Probel 502 and Probe2 503 will be in inverse relation to the number of hops
508, 509 (The fewer the number of hops, the higher the TTL). Thus, a relative hop count can be arrived at by subtracting the TTL in the response packet from a fixed value.
The latency metric is a weighted combination of the RTT and the hop count. The latency metric is used to determine the server that is the most efficient for accessing a client. The invention precisely determines the hop count metric between client and server.
The dynamic hop count metric derived through the invention is more accurate than the hop count derived from BGP. As a result, requests will be routed more accurately to the optimal server resulting in improved performance. The invention improves performance in multiple Internet infrastructure products including performance monitoring, WAN traffic management, and content distribution.
With respect to Fig. 6, a task level viewpoint of the invention is shown. Requests for content server addresses from LDNS's are received by the Receive IP Address Request module 605. The Receive IP Address Request module 605 sends the content request to the Request Latency Metrics module 606. POPs that can serve the content are retrieved from the Server Table 609 by the Request Latency Metrics module 606. The Request Latency Metrics module 606 then sends latency metric requests to the POPs that can serve the content and notifies the Determine Optimal Server module 608 that latency metrics are expected.
Request for latency metrics activate the Send Latency Metric module 601 to lookup the latency metric for the requesting LDNS's client. The Send Latency Probe module 603 sends latency probes to the IP addresses in the Latency Management Table 604. The IP addresses of clients are masked so the latency probes are sent to higher level servers as detailed above. Packets sent in response to the latency probes sent by the Send Latency Probe module 603 are received by the Receive Response Packet module 602. Hop count and latency data are stored into the Latency Management Table 604.
The Send Latency Metric module 601 uses the information in the Latency Management Table 604 to determine the latency metric from the resident POP to the requesting LDNS's client before sending the latency metric to the requesting server. The Send Latency Metric module 601 uses the BGP hop count in the Latency Management Table 604 for its calculations upon the first request for an IP address. The latency metric is calculated for subsequent requests of IP addresses by the Send Latency Metric module 601 using the hop count and RTT data obtained from the Receive Response Packet module 602. Latency metrics from POPs are received by the Receive Latency Metrics module 607. The latency metrics are sent to the Determine Optimal Server module 608. The Determine Optimal Server module 608 gathers the expected latency metrics and uses the inverse relationship of the hop counts in a weighted combination with the RTT to determine which latency metric indicates the optimal POP. The Determine Optimal Server module 608 then sends the address of the optimal POP to the requesting LDNS.
Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the invention should only be limited by the Claims included below.

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 latency metrics on a content server; wherein said latency metric request specifies a particular client; providing a latency management table; wherein said latency management table comprises a list of IP addresses along with corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop counts, and Round Trip Times (RTT); looking up the latency metric for said client in said latency management table; sending said latency metric to the requesting server; wherein the BGP hop count for said client in said latency management table is used for said latency metric upon the first request for said client; and wherein the dynamic hop count and RTT data for said client in said latency management table are used 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 , further comprising the steps of: receiving requests for a content server address from said client; sending a latency metric request to the appropriate content servers; receiving latency metric data from said content servers; determining the optimal content server for said client; and sending said optimal content server's address to said client.
5. The process of Claim 4, wherein said determining step gathers the expected latency metrics and uses the inverse relationship of the 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.
6. 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 latency metrics on a content server; wherein said latency metric request specifies a particular client; a latency management table; wherein said latency management table comprises a list of IP addresses along with corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop counts, and Round Trip Times (RTT); 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; wherein the BGP hop count for said client in said latency management table is used for said latency metric upon the first request for said client; and wherein the dynamic hop count and RTT data for said client in said latency management table are used for said latency metric for subsequent requests for said client.
7. The apparatus of Claim 6, 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.
8. The apparatus of Claim 7, 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.
9. The apparatus of Claim 7, further comprising: a module for receiving requests for a content server address from said client; a module for sending a latency metric request to the appropriate content servers; a module for receiving latency metric data from said content servers; a module for determining the optimal content server for said client; and a module for sending said optimal content server's address to said client.
10. The apparatus of Claim 9, wherein said determining module gathers the expected latency metrics and uses the inverse relationship of the 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.
11. 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 latency metrics on a content server; wherein said latency metric request specifies a particular client; providing a latency management table; wherein said latency management table comprises a list of IP addresses along with corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop counts, and Round Trip Times (RTT); looking up the latency metric for said client in said latency management table; sending said latency metric to the requesting server; wherein the BGP hop count for said client in said latency management table is used for said latency metric upon the first request for said client; and wherein the dynamic hop count and RTT data for said client in said latency management table are used for said latency metric for subsequent requests for said client.
12. The method of Claim 1 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.
13. The method of Claim 12, 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.
14. The method of Claim 11 , further comprising the steps of: receiving requests for a content server address from said client; sending a latency metric request to the appropriate content servers; receiving latency metric data from said content servers; determining the optimal content server for said client; and sending said optimal content server's address to said client.
15. The method of Claim 14, wherein said determining step gathers the expected latency metrics and uses the inverse relationship of the 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.
PCT/US2001/010524 2000-03-31 2001-03-30 Method and apparatus for determining latency between multiple servers and a client WO2001076182A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001247925A AU2001247925A1 (en) 2000-03-31 2001-03-30 Method and apparatus for determining latency between multiple servers and a client

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US19398800P 2000-03-31 2000-03-31
US60/193,988 2000-03-31
US09/657,016 2000-09-07
US09/657,016 US7058706B1 (en) 2000-03-31 2000-09-07 Method and apparatus for determining latency between multiple servers and a client

Publications (2)

Publication Number Publication Date
WO2001076182A2 true WO2001076182A2 (en) 2001-10-11
WO2001076182A3 WO2001076182A3 (en) 2003-11-06

Family

ID=26889582

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/010524 WO2001076182A2 (en) 2000-03-31 2001-03-30 Method and apparatus for determining latency between multiple servers and a client

Country Status (3)

Country Link
US (1) US7058706B1 (en)
AU (1) AU2001247925A1 (en)
WO (1) WO2001076182A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1324546A1 (en) * 2001-12-28 2003-07-02 Motorola, Inc. Dynamic content delivery method and network

Families Citing this family (215)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6275470B1 (en) 1999-06-18 2001-08-14 Digital Island, Inc. On-demand overlay routing for computer-based communication networks
US8543901B1 (en) 1999-11-01 2013-09-24 Level 3 Communications, Llc Verification of content stored in a network
US7523181B2 (en) * 1999-11-22 2009-04-21 Akamai Technologies, Inc. Method for determining metrics of a content delivery and global traffic management network
US7886023B1 (en) 2000-01-21 2011-02-08 Cisco Technology, Inc. Method and apparatus for a minimalist approach to implementing server selection
US7653706B2 (en) * 2000-07-19 2010-01-26 Akamai Technologies, Inc. Dynamic image delivery system
US7346676B1 (en) * 2000-07-19 2008-03-18 Akamai Technologies, Inc. Load balancing service
US8060581B2 (en) * 2000-07-19 2011-11-15 Akamai Technologies, Inc. Dynamic image delivery system
US7725602B2 (en) * 2000-07-19 2010-05-25 Akamai Technologies, Inc. Domain name resolution using a distributed DNS network
US8527639B1 (en) * 2000-08-18 2013-09-03 Cisco Technology, Inc. Content server selection for accessing content in a content distribution network
US7657629B1 (en) * 2000-09-26 2010-02-02 Foundry Networks, Inc. Global server load balancing
US7454500B1 (en) 2000-09-26 2008-11-18 Foundry Networks, Inc. Global server load balancing
US9130954B2 (en) 2000-09-26 2015-09-08 Brocade Communications Systems, Inc. Distributed health check for global server load balancing
EP1436736B1 (en) 2001-09-28 2017-06-28 Level 3 CDN International, Inc. Configurable adaptive global traffic control and management
US7860964B2 (en) 2001-09-28 2010-12-28 Level 3 Communications, Llc Policy-based content delivery network selection
US7373644B2 (en) 2001-10-02 2008-05-13 Level 3 Communications, Llc Automated server replication
US20030079027A1 (en) 2001-10-18 2003-04-24 Michael Slocombe Content request routing and load balancing for content distribution networks
US9167036B2 (en) 2002-02-14 2015-10-20 Level 3 Communications, Llc Managed object replication and delivery
KR20040094437A (en) * 2002-03-12 2004-11-09 코닌클리케 필립스 일렉트로닉스 엔.브이. Using timing signals to determine proximity between two nodes
JP3973986B2 (en) * 2002-07-12 2007-09-12 株式会社エヌ・ティ・ティ・ドコモ Node search method, node, communication system, and node search program
GB0217795D0 (en) * 2002-07-31 2002-09-11 Hewlett Packard Co Establishment of network connections
EP1387302A3 (en) * 2002-07-31 2006-05-24 Hewlett-Packard Development Company, L.P. Establishment of network connections
US7086061B1 (en) * 2002-08-01 2006-08-01 Foundry Networks, Inc. Statistical tracking of global server load balancing for selecting the best network address from ordered list of network addresses based on a set of performance metrics
US7574508B1 (en) 2002-08-07 2009-08-11 Foundry Networks, Inc. Canonical name (CNAME) handling for global server load balancing
US11368537B2 (en) * 2002-10-28 2022-06-21 Dynamic Mesh Networks, Inc. High performance wireless network
US9584360B2 (en) * 2003-09-29 2017-02-28 Foundry Networks, Llc Global server load balancing support for private VIP addresses
US20050097185A1 (en) * 2003-10-07 2005-05-05 Simon Gibson Localization link system
US7280486B2 (en) * 2004-01-07 2007-10-09 Cisco Technology, Inc. Detection of forwarding problems for external prefixes
US7496651B1 (en) 2004-05-06 2009-02-24 Foundry Networks, Inc. Configurable geographic prefixes for global server load balancing
US7584301B1 (en) 2004-05-06 2009-09-01 Foundry Networks, Inc. Host-level policies for global server load balancing
US7423977B1 (en) * 2004-08-23 2008-09-09 Foundry Networks Inc. Smoothing algorithm for round trip time (RTT) measurements
US8346956B2 (en) 2004-10-29 2013-01-01 Akamai Technologies, Inc. Dynamic image delivery system
US8145908B1 (en) 2004-10-29 2012-03-27 Akamai Technologies, Inc. Web content defacement protection system
US20070101019A1 (en) * 2005-11-03 2007-05-03 Cromer Daryl C Apparatus, system, and method for managing response latency
US7519734B1 (en) 2006-03-14 2009-04-14 Amazon Technologies, Inc. System and method for routing service requests
US8159961B1 (en) 2007-03-30 2012-04-17 Amazon Technologies, Inc. Load balancing utilizing adaptive thresholding
US7991910B2 (en) 2008-11-17 2011-08-02 Amazon Technologies, Inc. Updating routing information based on client location
US8028090B2 (en) 2008-11-17 2011-09-27 Amazon Technologies, Inc. Request routing utilizing client location information
US8615008B2 (en) 2007-07-11 2013-12-24 Foundry Networks Llc Duplicating network traffic through transparent VLAN flooding
KR101616063B1 (en) * 2007-08-08 2016-04-27 구글 인코포레이티드 Content server latency determination
US8949405B2 (en) * 2007-08-08 2015-02-03 Google Inc. Content server latency determination
US8429544B2 (en) * 2007-08-08 2013-04-23 Google Inc. Content server latency demonstration
US8082290B2 (en) * 2008-03-19 2011-12-20 Verizon Patent And Licensing Inc. Intelligent establishment of peer-to-peer communication
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US7962597B2 (en) 2008-03-31 2011-06-14 Amazon Technologies, Inc. Request routing based on class
US8321568B2 (en) 2008-03-31 2012-11-27 Amazon Technologies, Inc. Content management
US8447831B1 (en) 2008-03-31 2013-05-21 Amazon Technologies, Inc. Incentive driven content delivery
US8601090B1 (en) 2008-03-31 2013-12-03 Amazon Technologies, Inc. Network resource identification
US7970820B1 (en) 2008-03-31 2011-06-28 Amazon Technologies, Inc. Locality based content distribution
US8156243B2 (en) 2008-03-31 2012-04-10 Amazon Technologies, Inc. Request routing
US8533293B1 (en) 2008-03-31 2013-09-10 Amazon Technologies, Inc. Client side cache management
US10924573B2 (en) 2008-04-04 2021-02-16 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
WO2009123868A2 (en) 2008-04-04 2009-10-08 Level 3 Communications, Llc Handling long-tail content in a content delivery network (cdn)
US9762692B2 (en) 2008-04-04 2017-09-12 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US7925782B2 (en) 2008-06-30 2011-04-12 Amazon Technologies, Inc. Request routing using network computing components
US9912740B2 (en) 2008-06-30 2018-03-06 Amazon Technologies, Inc. Latency measurement in resource requests
US9407681B1 (en) * 2010-09-28 2016-08-02 Amazon Technologies, Inc. Latency measurement in resource requests
US20100088405A1 (en) * 2008-10-08 2010-04-08 Microsoft Corporation Determining Network Delay and CDN Deployment
US8521880B1 (en) 2008-11-17 2013-08-27 Amazon Technologies, Inc. Managing content delivery network service providers
US8060616B1 (en) 2008-11-17 2011-11-15 Amazon Technologies, Inc. Managing CDN registration by a storage provider
US8122098B1 (en) 2008-11-17 2012-02-21 Amazon Technologies, Inc. Managing content delivery network service providers by a content broker
US8073940B1 (en) 2008-11-17 2011-12-06 Amazon Technologies, Inc. Managing content delivery network service providers
US8732309B1 (en) 2008-11-17 2014-05-20 Amazon Technologies, Inc. Request routing utilizing cost information
US8065417B1 (en) 2008-11-17 2011-11-22 Amazon Technologies, Inc. Service provider registration by a content broker
US8462681B2 (en) * 2009-01-15 2013-06-11 The Trustees Of Stevens Institute Of Technology Method and apparatus for adaptive transmission of sensor data with latency controls
US8756341B1 (en) 2009-03-27 2014-06-17 Amazon Technologies, Inc. Request routing utilizing popularity information
US8412823B1 (en) 2009-03-27 2013-04-02 Amazon Technologies, Inc. Managing tracking information entries in resource cache components
US8688837B1 (en) 2009-03-27 2014-04-01 Amazon Technologies, Inc. Dynamically translating resource identifiers for request routing using popularity information
US8521851B1 (en) 2009-03-27 2013-08-27 Amazon Technologies, Inc. DNS query processing using resource identifiers specifying an application broker
US8782236B1 (en) 2009-06-16 2014-07-15 Amazon Technologies, Inc. Managing resources using resource expiration data
US20100333188A1 (en) * 2009-06-29 2010-12-30 Politowicz Timothy J Method for protecting networks against hostile attack
US8397073B1 (en) 2009-09-04 2013-03-12 Amazon Technologies, Inc. Managing secure content in a content delivery network
US8433771B1 (en) 2009-10-02 2013-04-30 Amazon Technologies, Inc. Distribution network with forward resource propagation
JP5428834B2 (en) * 2009-12-21 2014-02-26 富士通株式会社 Network group determination apparatus, network group determination method, and network group determination program
US9495338B1 (en) 2010-01-28 2016-11-15 Amazon Technologies, Inc. Content distribution network
US8756272B1 (en) 2010-08-26 2014-06-17 Amazon Technologies, Inc. Processing encoded content
US8489724B2 (en) 2010-09-14 2013-07-16 Cdnetworks Co., Ltd. CNAME-based round-trip time measurement in a content delivery network
US9003035B1 (en) 2010-09-28 2015-04-07 Amazon Technologies, Inc. Point of presence management in request routing
US9712484B1 (en) 2010-09-28 2017-07-18 Amazon Technologies, Inc. Managing request routing information utilizing client identifiers
US8468247B1 (en) 2010-09-28 2013-06-18 Amazon Technologies, Inc. Point of presence management in request routing
US8924528B1 (en) 2010-09-28 2014-12-30 Amazon Technologies, Inc. Latency measurement in resource requests
US8938526B1 (en) 2010-09-28 2015-01-20 Amazon Technologies, Inc. Request routing management based on network components
US10097398B1 (en) 2010-09-28 2018-10-09 Amazon Technologies, Inc. Point of presence management in request routing
US10958501B1 (en) 2010-09-28 2021-03-23 Amazon Technologies, Inc. Request routing information based on client IP groupings
US8577992B1 (en) 2010-09-28 2013-11-05 Amazon Technologies, Inc. Request routing management based on network components
US8819283B2 (en) 2010-09-28 2014-08-26 Amazon Technologies, Inc. Request routing in a networked environment
US8930513B1 (en) * 2010-09-28 2015-01-06 Amazon Technologies, Inc. Latency measurement in resource requests
US9536249B2 (en) * 2010-09-29 2017-01-03 Excalibur Ip, Llc Measuring inline ad performance for third-party ad serving
US8549148B2 (en) 2010-10-15 2013-10-01 Brocade Communications Systems, Inc. Domain name system security extensions (DNSSEC) for global server load balancing
US8452874B2 (en) 2010-11-22 2013-05-28 Amazon Technologies, Inc. Request routing processing
US9391949B1 (en) 2010-12-03 2016-07-12 Amazon Technologies, Inc. Request routing processing
US8626950B1 (en) 2010-12-03 2014-01-07 Amazon Technologies, Inc. Request routing processing
US8583824B2 (en) * 2010-12-16 2013-11-12 Microsoft Corporation Identifying an efficient destination server
US8867337B2 (en) 2011-04-26 2014-10-21 International Business Machines Corporation Structure-aware caching
US10467042B1 (en) 2011-04-27 2019-11-05 Amazon Technologies, Inc. Optimized deployment based upon customer locality
US9736065B2 (en) 2011-06-24 2017-08-15 Cisco Technology, Inc. Level of hierarchy in MST for traffic localization and load balancing
US9843601B2 (en) 2011-07-06 2017-12-12 Nominum, Inc. Analyzing DNS requests for anomaly detection
WO2013035310A1 (en) * 2011-09-06 2013-03-14 日本電気株式会社 Communication device, communication system, and communication method
US8908698B2 (en) 2012-01-13 2014-12-09 Cisco Technology, Inc. System and method for managing site-to-site VPNs of a cloud managed network
US8904009B1 (en) 2012-02-10 2014-12-02 Amazon Technologies, Inc. Dynamic content delivery
US10021179B1 (en) 2012-02-21 2018-07-10 Amazon Technologies, Inc. Local resource delivery network
US9172674B1 (en) 2012-03-21 2015-10-27 Amazon Technologies, Inc. Managing request routing information utilizing performance information
US10623408B1 (en) 2012-04-02 2020-04-14 Amazon Technologies, Inc. Context sensitive object management
US9154551B1 (en) 2012-06-11 2015-10-06 Amazon Technologies, Inc. Processing DNS queries to identify pre-processing information
US9350633B2 (en) * 2012-07-24 2016-05-24 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Dynamic optimization of command issuance in a computing cluster
US9525659B1 (en) 2012-09-04 2016-12-20 Amazon Technologies, Inc. Request routing utilizing point of presence load information
US9135048B2 (en) 2012-09-20 2015-09-15 Amazon Technologies, Inc. Automated profiling of resource usage
US9323577B2 (en) 2012-09-20 2016-04-26 Amazon Technologies, Inc. Automated profiling of resource usage
US10205698B1 (en) 2012-12-19 2019-02-12 Amazon Technologies, Inc. Source-dependent address resolution
US9043439B2 (en) 2013-03-14 2015-05-26 Cisco Technology, Inc. Method for streaming packet captures from network access devices to a cloud server over HTTP
US10164989B2 (en) 2013-03-15 2018-12-25 Nominum, Inc. Distinguishing human-driven DNS queries from machine-to-machine DNS queries
US9294391B1 (en) 2013-06-04 2016-03-22 Amazon Technologies, Inc. Managing network computing components utilizing request routing
US9565138B2 (en) 2013-12-20 2017-02-07 Brocade Communications Systems, Inc. Rule-based network traffic interception and distribution scheme
US9467461B2 (en) 2013-12-21 2016-10-11 Akamai Technologies Inc. Countering security threats with the domain name system
US9648542B2 (en) 2014-01-28 2017-05-09 Brocade Communications Systems, Inc. Session-based packet routing for facilitating analytics
US10122605B2 (en) 2014-07-09 2018-11-06 Cisco Technology, Inc Annotation of network activity through different phases of execution
US9825878B2 (en) 2014-09-26 2017-11-21 Cisco Technology, Inc. Distributed application framework for prioritizing network traffic using application priority awareness
US10097448B1 (en) 2014-12-18 2018-10-09 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10091096B1 (en) 2014-12-18 2018-10-02 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10033627B1 (en) 2014-12-18 2018-07-24 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10050862B2 (en) * 2015-02-09 2018-08-14 Cisco Technology, Inc. Distributed application framework that uses network and application awareness for placing data
US10708342B2 (en) 2015-02-27 2020-07-07 Cisco Technology, Inc. Dynamic troubleshooting workspaces for cloud and network management systems
US10771475B2 (en) 2015-03-23 2020-09-08 Extreme Networks, Inc. Techniques for exchanging control and configuration information in a network visibility system
US10129088B2 (en) 2015-06-17 2018-11-13 Extreme Networks, Inc. Configuration of rules in a network visibility system
US10911353B2 (en) 2015-06-17 2021-02-02 Extreme Networks, Inc. Architecture for a network visibility system
US9866478B2 (en) 2015-03-23 2018-01-09 Extreme Networks, Inc. Techniques for user-defined tagging of traffic in a network visibility system
US10225326B1 (en) 2015-03-23 2019-03-05 Amazon Technologies, Inc. Point of presence based data uploading
US9819567B1 (en) 2015-03-30 2017-11-14 Amazon Technologies, Inc. Traffic surge management for points of presence
US9887931B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9887932B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9832141B1 (en) 2015-05-13 2017-11-28 Amazon Technologies, Inc. Routing based request correlation
US10476982B2 (en) 2015-05-15 2019-11-12 Cisco Technology, Inc. Multi-datacenter message queue
US10530688B2 (en) 2015-06-17 2020-01-07 Extreme Networks, Inc. Configuration of load-sharing components of a network visibility router in a network visibility system
US10057126B2 (en) 2015-06-17 2018-08-21 Extreme Networks, Inc. Configuration of a network visibility system
US10616179B1 (en) 2015-06-25 2020-04-07 Amazon Technologies, Inc. Selective routing of domain name system (DNS) requests
US10034201B2 (en) 2015-07-09 2018-07-24 Cisco Technology, Inc. Stateless load-balancing across multiple tunnels
US10097566B1 (en) 2015-07-31 2018-10-09 Amazon Technologies, Inc. Identifying targets of network attacks
US9794281B1 (en) 2015-09-24 2017-10-17 Amazon Technologies, Inc. Identifying sources of network attacks
US9742795B1 (en) 2015-09-24 2017-08-22 Amazon Technologies, Inc. Mitigating network attacks
US9774619B1 (en) 2015-09-24 2017-09-26 Amazon Technologies, Inc. Mitigating network attacks
US11005682B2 (en) 2015-10-06 2021-05-11 Cisco Technology, Inc. Policy-driven switch overlay bypass in a hybrid cloud network environment
US10462136B2 (en) 2015-10-13 2019-10-29 Cisco Technology, Inc. Hybrid cloud security groups
US10270878B1 (en) 2015-11-10 2019-04-23 Amazon Technologies, Inc. Routing for origin-facing points of presence
US10523657B2 (en) 2015-11-16 2019-12-31 Cisco Technology, Inc. Endpoint privacy preservation with cloud conferencing
US10205677B2 (en) 2015-11-24 2019-02-12 Cisco Technology, Inc. Cloud resource placement optimization and migration execution in federated clouds
US10084703B2 (en) 2015-12-04 2018-09-25 Cisco Technology, Inc. Infrastructure-exclusive service forwarding
US10257307B1 (en) 2015-12-11 2019-04-09 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10049051B1 (en) 2015-12-11 2018-08-14 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10348639B2 (en) 2015-12-18 2019-07-09 Amazon Technologies, Inc. Use of virtual endpoints to improve data transmission rates
US10367914B2 (en) 2016-01-12 2019-07-30 Cisco Technology, Inc. Attaching service level agreements to application containers and enabling service assurance
US10243813B2 (en) 2016-02-12 2019-03-26 Extreme Networks, Inc. Software-based packet broker
US10999200B2 (en) 2016-03-24 2021-05-04 Extreme Networks, Inc. Offline, intelligent load balancing of SCTP traffic
US10129177B2 (en) 2016-05-23 2018-11-13 Cisco Technology, Inc. Inter-cloud broker for hybrid cloud networks
US10057153B1 (en) * 2016-06-02 2018-08-21 Cisco Technology, Inc. Detecting slow virtual devices
US10075551B1 (en) 2016-06-06 2018-09-11 Amazon Technologies, Inc. Request management for hierarchical cache
US10110694B1 (en) 2016-06-29 2018-10-23 Amazon Technologies, Inc. Adaptive transfer rate for retrieving content from a server
US10659283B2 (en) 2016-07-08 2020-05-19 Cisco Technology, Inc. Reducing ARP/ND flooding in cloud environment
US10432532B2 (en) 2016-07-12 2019-10-01 Cisco Technology, Inc. Dynamically pinning micro-service to uplink port
US10382597B2 (en) 2016-07-20 2019-08-13 Cisco Technology, Inc. System and method for transport-layer level identification and isolation of container traffic
US10263898B2 (en) 2016-07-20 2019-04-16 Cisco Technology, Inc. System and method for implementing universal cloud classification (UCC) as a service (UCCaaS)
US10567344B2 (en) 2016-08-23 2020-02-18 Cisco Technology, Inc. Automatic firewall configuration based on aggregated cloud managed information
US9992086B1 (en) 2016-08-23 2018-06-05 Amazon Technologies, Inc. External health checking of virtual private cloud network environments
US10033691B1 (en) 2016-08-24 2018-07-24 Amazon Technologies, Inc. Adaptive resolution of domain name requests in virtual private cloud network environments
US10616250B2 (en) 2016-10-05 2020-04-07 Amazon Technologies, Inc. Network addresses with encoded DNS-level information
US10523592B2 (en) 2016-10-10 2019-12-31 Cisco Technology, Inc. Orchestration system for migrating user data and services based on user information
US10567259B2 (en) 2016-10-19 2020-02-18 Extreme Networks, Inc. Smart filter generator
US11044162B2 (en) 2016-12-06 2021-06-22 Cisco Technology, Inc. Orchestration of cloud and fog interactions
US10326817B2 (en) 2016-12-20 2019-06-18 Cisco Technology, Inc. System and method for quality-aware recording in large scale collaborate clouds
US10831549B1 (en) 2016-12-27 2020-11-10 Amazon Technologies, Inc. Multi-region request-driven code execution system
US10372499B1 (en) 2016-12-27 2019-08-06 Amazon Technologies, Inc. Efficient region selection system for executing request-driven code
US10334029B2 (en) 2017-01-10 2019-06-25 Cisco Technology, Inc. Forming neighborhood groups from disperse cloud providers
US10552191B2 (en) 2017-01-26 2020-02-04 Cisco Technology, Inc. Distributed hybrid cloud orchestration model
US10320683B2 (en) 2017-01-30 2019-06-11 Cisco Technology, Inc. Reliable load-balancer using segment routing and real-time application monitoring
US10938884B1 (en) 2017-01-30 2021-03-02 Amazon Technologies, Inc. Origin server cloaking using virtual private cloud network environments
US10671571B2 (en) 2017-01-31 2020-06-02 Cisco Technology, Inc. Fast network performance in containerized environments for network function virtualization
US11005731B2 (en) 2017-04-05 2021-05-11 Cisco Technology, Inc. Estimating model parameters for automatic deployment of scalable micro services
US10503613B1 (en) 2017-04-21 2019-12-10 Amazon Technologies, Inc. Efficient serving of resources during server unavailability
US11075987B1 (en) 2017-06-12 2021-07-27 Amazon Technologies, Inc. Load estimating content delivery network
US10447648B2 (en) 2017-06-19 2019-10-15 Amazon Technologies, Inc. Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP
US10382274B2 (en) 2017-06-26 2019-08-13 Cisco Technology, Inc. System and method for wide area zero-configuration network auto configuration
US10439877B2 (en) 2017-06-26 2019-10-08 Cisco Technology, Inc. Systems and methods for enabling wide area multicast domain name system
US10425288B2 (en) 2017-07-21 2019-09-24 Cisco Technology, Inc. Container telemetry in data center environments with blade servers and switches
US10892940B2 (en) 2017-07-21 2021-01-12 Cisco Technology, Inc. Scalable statistics and analytics mechanisms in cloud networking
US10601693B2 (en) 2017-07-24 2020-03-24 Cisco Technology, Inc. System and method for providing scalable flow monitoring in a data center fabric
US10541866B2 (en) 2017-07-25 2020-01-21 Cisco Technology, Inc. Detecting and resolving multicast traffic performance issues
US10742593B1 (en) 2017-09-25 2020-08-11 Amazon Technologies, Inc. Hybrid content request routing system
US11481362B2 (en) 2017-11-13 2022-10-25 Cisco Technology, Inc. Using persistent memory to enable restartability of bulk load transactions in cloud databases
US10705882B2 (en) 2017-12-21 2020-07-07 Cisco Technology, Inc. System and method for resource placement across clouds for data intensive workloads
US11595474B2 (en) 2017-12-28 2023-02-28 Cisco Technology, Inc. Accelerating data replication using multicast and non-volatile memory enabled nodes
US10592578B1 (en) 2018-03-07 2020-03-17 Amazon Technologies, Inc. Predictive content push-enabled content delivery network
US10511534B2 (en) 2018-04-06 2019-12-17 Cisco Technology, Inc. Stateless distributed load-balancing
CN108600051B (en) * 2018-04-28 2020-02-18 网宿科技股份有限公司 BGP Anycast cluster service quality detection method and detection equipment
US10728361B2 (en) 2018-05-29 2020-07-28 Cisco Technology, Inc. System for association of customer information across subscribers
US10904322B2 (en) 2018-06-15 2021-01-26 Cisco Technology, Inc. Systems and methods for scaling down cloud-based servers handling secure connections
US10764266B2 (en) 2018-06-19 2020-09-01 Cisco Technology, Inc. Distributed authentication and authorization for rapid scaling of containerized services
US11019083B2 (en) 2018-06-20 2021-05-25 Cisco Technology, Inc. System for coordinating distributed website analysis
US10819571B2 (en) 2018-06-29 2020-10-27 Cisco Technology, Inc. Network traffic optimization using in-situ notification system
US10904342B2 (en) 2018-07-30 2021-01-26 Cisco Technology, Inc. Container networking using communication tunnels
US10862852B1 (en) 2018-11-16 2020-12-08 Amazon Technologies, Inc. Resolution of domain name requests in heterogeneous network environments
US11025747B1 (en) 2018-12-12 2021-06-01 Amazon Technologies, Inc. Content request pattern-based routing system
US11297040B2 (en) 2019-05-01 2022-04-05 Akamai Technologies, Inc. Intermediary handling of identity services to guard against client side attack vectors
US10834222B1 (en) 2019-05-09 2020-11-10 Akamai Technologies Inc. Server utilizing multiple object retrieval candidates
US11283757B2 (en) 2019-06-25 2022-03-22 Akamai Technologies, Inc. Mapping internet routing with anycast and utilizing such maps for deploying and operating anycast points of presence (PoPs)
US20210173888A1 (en) 2019-12-08 2021-06-10 Akamai Technologies Inc. Proxy server caching of database content
US11394801B2 (en) 2020-01-21 2022-07-19 Bank Of America Corporation Resiliency control engine for network service mesh systems
US11233768B1 (en) 2020-09-30 2022-01-25 Akamai Technologies, Inc. CDN configuration tuning based on domain scan analysis
US11445225B2 (en) 2020-10-27 2022-09-13 Akamai Technologies, Inc. Measuring and improving origin offload and resource utilization in caching systems
US11799948B2 (en) 2020-11-17 2023-10-24 Cisco Technology, Inc. Cloud service datacenter selection based on data sovereignty policies
US11379281B2 (en) 2020-11-18 2022-07-05 Akamai Technologies, Inc. Detection and optimization of content in the payloads of API messages
US11343348B1 (en) 2021-04-12 2022-05-24 Akamai Technologies, Inc. Real-time message delivery and update service in a proxy server network
US11343344B1 (en) 2021-04-23 2022-05-24 Akamai Technologies, Inc. Proxy server entity transfer modes
EP4327543A1 (en) 2021-04-23 2024-02-28 Akamai Technologies, Inc. Proxy server entity transfer modes
US20220377079A1 (en) 2021-05-18 2022-11-24 Akamai Technologies, Inc. Fast, secure, and scalable data store at the edge for connecting network enabled devices
WO2022272206A1 (en) * 2021-06-22 2022-12-29 Level 3 Communications, Llc Network optimization system using latency measurements
US11748263B2 (en) 2021-11-15 2023-09-05 Akamai Technologies, Inc. Internet caches with object hints
US11445045B1 (en) 2021-12-21 2022-09-13 Akamai Technologies, Inc. Systems and methods for preventing the caching of rarely requested objects

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5729689A (en) 1995-04-25 1998-03-17 Microsoft Corporation Network naming services proxy agent
US6360256B1 (en) 1996-07-01 2002-03-19 Sun Microsystems, Inc. Name service for a redundant array of internet servers
US5774660A (en) 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US6052718A (en) * 1997-01-07 2000-04-18 Sightpath, Inc Replica routing
US5918228A (en) 1997-01-28 1999-06-29 International Business Machines Corporation Method and apparatus for enabling a web server to impersonate a user of a distributed file system to obtain secure access to supported web documents
US6078943A (en) 1997-02-07 2000-06-20 International Business Machines Corporation Method and apparatus for dynamic interval-based load balancing
US6173311B1 (en) 1997-02-13 2001-01-09 Pointcast, Inc. Apparatus, method and article of manufacture for servicing client requests on a network
US6256675B1 (en) * 1997-05-06 2001-07-03 At&T Corp. System and method for allocating requests for objects and managing replicas of objects on a network
US6112239A (en) 1997-06-18 2000-08-29 Intervu, Inc System and method for server-side optimization of data delivery on a distributed computer network
US6029196A (en) 1997-06-18 2000-02-22 Netscape Communications Corporation Automatic client configuration system
US6006264A (en) * 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server
US6128279A (en) 1997-10-06 2000-10-03 Web Balance, Inc. System for balancing loads among network servers
US6070191A (en) 1997-10-17 2000-05-30 Lucent Technologies Inc. Data distribution techniques for load-balanced fault-tolerant web access
WO1999029083A1 (en) 1997-12-02 1999-06-10 Alcatel Usa Sourcing, L.P. Method and apparatus for dynamic domain names
US6118765A (en) * 1998-01-13 2000-09-12 Qualcomm Inc. System method and computer program product for eliminating unnecessary retransmissions
US6119171A (en) 1998-01-29 2000-09-12 Ip Dynamics, Inc. Domain name routing
US6735631B1 (en) * 1998-02-10 2004-05-11 Sprint Communications Company, L.P. Method and system for networking redirecting
US6665271B1 (en) * 1998-03-17 2003-12-16 Transnexus, Llc System for real-time prediction of quality for internet-based multimedia communications
US6115752A (en) 1998-05-21 2000-09-05 Sun Microsystems, Inc. System and method for server selection for mirrored sites
US6260070B1 (en) * 1998-06-30 2001-07-10 Dhaval N. Shah System and method for determining a preferred mirrored service in a network by evaluating a border gateway protocol
US6249801B1 (en) 1998-07-15 2001-06-19 Radware Ltd. Load balancing
US6092178A (en) 1998-09-03 2000-07-18 Sun Microsystems, Inc. System for responding to a resource request
US6381627B1 (en) 1998-09-21 2002-04-30 Microsoft Corporation Method and computer readable medium for discovering master DNS server computers for a given domain name in multiple master and multiple namespace configurations
US6438652B1 (en) 1998-10-09 2002-08-20 International Business Machines Corporation Load balancing cooperating cache servers by shifting forwarded request
US6298381B1 (en) * 1998-10-20 2001-10-02 Cisco Technology, Inc. System and method for information retrieval regarding services
US6182148B1 (en) 1999-03-18 2001-01-30 Walid, Inc. Method and system for internationalizing domain names
US6795860B1 (en) * 1999-04-05 2004-09-21 Cisco Technology, Inc. System and method for selecting a service with dynamically changing information
US6430619B1 (en) 1999-05-06 2002-08-06 Cisco Technology, Inc. Virtual private data network session count limitation
FI107421B (en) * 1999-06-28 2001-07-31 Stonesoft Oy Procedure for selecting connections
US6415323B1 (en) * 1999-09-03 2002-07-02 Fastforward Networks Proximity-based redirection system for robust and scalable service-node location in an internetwork
US6405252B1 (en) 1999-11-22 2002-06-11 Speedera Networks, Inc. Integrated point of presence server network
US6560717B1 (en) 1999-12-10 2003-05-06 Art Technology Group, Inc. Method and system for load balancing and management
US20020099816A1 (en) 2000-04-20 2002-07-25 Quarterman John S. Internet performance system
US7653706B2 (en) 2000-07-19 2010-01-26 Akamai Technologies, Inc. Dynamic image delivery system
US6546014B1 (en) * 2001-01-12 2003-04-08 Alloptic, Inc. Method and system for dynamic bandwidth allocation in an optical access network

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
BHATTACHARJEE S ET AL: "APPLICATION-LAYER ANYCASTING" PROCEEDINGS OF THE IEEE INFOCOM '97. THE CONFERENCE ON COMPUTER COMMUNICATIONS. 16TH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS SOCIETIES. DRIVING THE INFORMATION REVOLUTION. KOBE, APRIL 7 - 12, 1997, LOS ALAMITOS, CA: IEEE COMPU, vol. 3, 7 April 1997 (1997-04-07), pages 1388-1396, XP000851102 ISBN: 0-8186-7782-1 *
FEI Z ET AL: "NOVEL SERVER SELECTION TECHNIQUE FOR IMPROVING THE RESPONSE TIME OFA REPLICATED SERVICE" PROCEEDINGS OF THE IEEE INFOCOM '98. THE CONFERENCE ON COMPUTER COMMUNICATIONS. 17TH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS SOCIETY. GATEWAY TO THE 21ST CENTURY. SAN FRANCISCO, CA, MARCH 29 - APRIL 2, 1998, PROCEEDINGS IEEE I, vol. 2, 29 March 1998 (1998-03-29), pages 783-791, XP000852062 ISBN: 0-7803-4384-0 *
GUYTON J D ET AL: "LOCATING NEARBY COPIES OF REPLICATED INTERNET SERVERS" COMPUTER COMMUNICATIONS REVIEW, ASSOCIATION FOR COMPUTING MACHINERY. NEW YORK, US, vol. 25, no. 4, 1 October 1995 (1995-10-01), pages 288-298, XP000541664 ISSN: 0146-4833 *
MOORE K ET AL: "SONAR - a network proximity service" IETF INTERNET-DRAFT, 23 February 1996 (1996-02-23), XP002109464 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1324546A1 (en) * 2001-12-28 2003-07-02 Motorola, Inc. Dynamic content delivery method and network
WO2003065659A1 (en) * 2001-12-28 2003-08-07 Motorola Inc Dynamic content allocation/delivery mechanism

Also Published As

Publication number Publication date
US7058706B1 (en) 2006-06-06
AU2001247925A1 (en) 2001-10-15
WO2001076182A3 (en) 2003-11-06

Similar Documents

Publication Publication Date Title
US7058706B1 (en) Method and apparatus for determining latency between multiple servers and a client
US9692679B2 (en) Event triggered traceroute for optimized routing in a computer network
US7165116B2 (en) Method for network discovery using name servers
US8117296B2 (en) Domain name resolution using a distributed DNS network
EP2466810B1 (en) Method and router for a service dependent routing
TWI398149B (en) Method, apparatus, system, instructions and software for domain name resolution
Pan et al. An overview of DNS-based server selections in content distribution networks
Jakab et al. LISP-TREE: a DNS hierarchy to support the lisp mapping system
US7619982B2 (en) Active probe path management
US7675861B2 (en) Active probe target management
US7447798B2 (en) Methods and systems for providing dynamic domain name system for inbound route control
JP2001508258A (en) Replica routing
US20100110891A1 (en) Sharing performance measurements among address prefixes of a same domain in a computer network
Goel et al. Faster web through client-assisted CDN server selection
Agarwal et al. Content distribution architecture using network layer anycast
Cabellos et al. An Architectural Introduction to the Locator/ID Separation Protocol (LISP)
US8510419B2 (en) Identifying a subnet address range from DNS information
Colitti et al. Evaluating the effects of anycast on DNS root name servers
JP5283271B2 (en) Server selection method, selection system and program in network
Cisco Configuring CSS Network Protocols
Cisco AppleTalk Commands
Qian et al. Bringing local dns servers close to their clients
Tomic et al. Implementation and efficiency analysis of composite DNS-metric for dynamic server selection
US20230300060A1 (en) Optimizing network delivery of 5g edge application services
Grossglauser et al. Looking for science in the art of network measurement

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP