Patent Publication Number: US-11381493-B2

Title: Determining a transit appliance for data traffic to a software service

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of and claims the priority benefit of U.S. patent application Ser. No. 17/073,064 filed on Oct. 16, 2020, which is a continuation of and claims the priority benefit of U.S. patent application Ser. No. 15/857,560 filed Dec. 28, 2017, U.S. Pat. No. 10,812,361 granted on Oct. 20, 2020, which is a continuation of and claims the priority benefit of U.S. patent application Ser. No. 14/447,505 filed on Jul. 30, 2014, U.S. Pat. No. 9,948,496 granted on Apr. 17, 2018. The disclosure of the above-referenced applications are incorporated herein in their entirety for all purposes. 
    
    
     TECHNICAL FIELD 
     This disclosure relates generally to optimization of data transfer to a software service via a transit appliance. 
     BACKGROUND 
     The approaches described in this section could be pursued, but are not necessarily approaches that have previously been conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. 
     Data centers may be used to provide computing infrastructure by employing a number of computing resources and associated components, such as telecommunication equipment, networking equipment, storage systems, backup power supplies, environmental controls, and so forth. A data center may provide a variety of services (e.g., web applications, email services, and search engine services) for a number of customers simultaneously. To provide these services, the computing infrastructure of the data center may run various software applications and store business and operational data. The computing resources distributed throughout the data center may be physical machines and/or virtual machines running on a physical host. 
     Computing resources of a data center may transmit and receive data packets via one or more interconnected networks, such as a Wide Area Network (WAN). Physical switches and routers can be distributed throughout the WAN and configured to connect various network segments and route the data packets within the network environment. It may be desirable to optimize or otherwise transform the data packets transmitted and received via the WAN. Routing of the data packets for optimization may be performed by configuring physical switches, routers, and/or other network appliances, to reroute the data packets to a data optimization virtual machine. However, involving reconfiguration of physical network components in data optimization may be costly and require complex coordination of various organizations and departments. 
     Additionally, an increasing number of computing resources and services are being hosted in the cloud. Infrastructure as a Service (IaaS) allows an organization to outsource the equipment used to support operations. As such, a request for a service may be first routed to a server associated with the service, with the server being housed in an IaaS center. 
     Software as a Service (SaaS) is also increasingly prevalent as it allows a user to access software services from any computing terminal. Access times for a user to access the SaaS may vary depending on the location from which a user is trying to access the software service. As the access time increases, the user may perceive performance and usability problems with the service. Furthermore, the software service hosted as SaaS may have its necessary computing equipment located in one or more physical locations, including IaaS locations. As such, a user request for a software service may first travel through one or more interconnected networks to one or more IaaS centers and then to the SaaS, which can be located anywhere in the world. Because the data may have to travel substantial geographic distances from each intermediate point, this increases the response time to the end user as well as the opportunities for packet loss. 
     While there are many optimization techniques that can be accomplished in a WAN, many of these optimization techniques for data transfer across a network require symmetric network components. For example, if data packets are encoded on the transmitting end before transmission through the network, they must be decoded on the receiving end. To optimize data transfer to a particular software service, it is desirable to decode the data as close to the requested software service as possible. 
     Therefore, a mechanism is needed to find an optimal transit appliance for a requested software service based on network performance characteristics, so that a user can access a software service with the most efficiency. 
     SUMMARY 
     This summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
     In exemplary embodiments, a computer-implemented method for selecting a transit appliance for data traffic to a software service through a network comprising a plurality of network appliances, comprises: measuring one or more performance metrics of data traffic from at least one of the plurality of network appliances to an IP address associated with a software service, the IP address for the software service having been retrieved from a service directory; determining a derived performance metric to be advertised to the plurality of network appliances, the derived performance metric based at least in part on the one or more measured performance metrics; advertising the derived performance metric among one or more of the plurality of network appliances; updating an advertised metric table at one or more of the plurality of network appliances with the derived performance metric received from at least one of the plurality of network appliances; and selecting a transit appliance for data traffic to the IP address associated with the software service, the selection based at least in part on the advertised performance metrics. The performance metric may be based on at least one of network latency, data loss, and round trip time. The software service to be accessed may be hosted in a cloud-based environment. One or more of the plurality of network appliances may also be hosted in a cloud-based environment. 
     In further exemplary embodiments, the above method steps may be stored on a machine-readable medium comprising instructions, which when implemented by one or more processors perform the steps of the method. In yet further examples, subsystems or devices can be adapted to perform the recited steps. Other features, examples, and embodiments are described below. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments are illustrated by way of example, and not by limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
         FIG. 1A  depicts an exemplary system environment for determining a transit appliance for transfer of data traffic to and from a software service. 
         FIG. 1B  depicts an exemplary system environment for determining a transit appliance for transfer of data traffic to and from a software service. 
         FIG. 2  illustrates an exemplary service directory from the portal. 
         FIG. 3  illustrates an exemplary measured metric table at an appliance. 
         FIG. 4  illustrates an exemplary advertised metric table at an appliance. 
         FIG. 5  is a process flow diagram illustrating an exemplary method for the determination of a transit appliance to a software service. 
         FIG. 6  shows an exemplary system environment suitable for implementing methods for optimization of data across one or more interconnected networks. 
         FIG. 7A  is a process flow diagram illustrating an exemplary method for the transmission of data packets for a software service via a first appliance. 
         FIG. 7B  is a process flow diagram illustrating an exemplary method for the transmission of data packets for a software service via a transit appliance. 
         FIG. 8  is a screenshot of an exemplary GUI for a user to select optimization of data traffic to and from particular software services. 
         FIG. 9  shows an exemplary global network of appliances in an overlay network. 
     
    
    
     DETAILED DESCRIPTION 
     The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations, in accordance with exemplary embodiments. These exemplary embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the present subject matter. The embodiments can be combined, other embodiments can be utilized, or structural, logical, and electrical changes can be made without departing from the scope of what is claimed. The following detailed description is therefore not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents. In this document, the terms “a” and “an” are used, as is common in patent documents, to include one or more than one. In this document, the term “or” is used to refer to a nonexclusive “or,” such that“A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. 
     The embodiments disclosed herein may be implemented using a variety of technologies. For example, the methods described herein may be implemented in software executing on a computer system or in hardware utilizing either a combination of microprocessors or other specially designed application-specific integrated circuits (ASICs), programmable logic devices, or various combinations thereof. In particular, the methods described herein may be implemented by a series of computer-executable instructions residing on a storage medium, such as a disk drive, or computer-readable medium. 
     The embodiments described herein relate to computer-implemented methods for optimization of data transfer to a software service via a transit appliance. 
       FIG. 1A  depicts an exemplary system environment for determining a transit appliance for transfer of data traffic to and from a software service across one or more interconnected networks  120 , such as the Internet, or any other wide area network. In the exemplary embodiment, a user at computer  102   a  may access a software service, such as software service  110 A, software service  1106 , or software service  110 N. While three software services are depicted here, there can be any number of software services. Data packets from the user at computer  102   a  may be transmitted via appliance  104   a , which may also be referred to herein as the first appliance or ingress appliance for the request. Data packets from the user at computer  102   b  may be transmitted via appliance  104   b , which is the first appliance or ingress appliance for that request. 
     The data packets from the user are then transmitted across the one or more interconnected networks  120 , where there may be one or more peer appliances at different locations. In various embodiments as discussed herein, each of these peer appliances are in communication with each other, and form an overlay network that optimizes communication between the appliances. For example, the appliances may transfer data packets within the overlay network using one or more data transfer optimization techniques, such as compression/decompression, deduplication, TCP acceleration, performance enhancing proxy, packet reconstruction, error correction, or any other technique for optimizing data transfer between network appliances or devices. 
     Embodiments of the present disclosure provide for the selection of a transit appliance (also referred to herein as a second appliance or egress appliance), for each software service. The selected transit appliance (also referred to herein as the optimal transit appliance) may be the appliance which has the best network performance metrics for providing access to the requested software service, or component of the requested software service. In the exemplary embodiment depicted in  FIG. 1A , the optimal transit appliance for software service  110 A is appliance  106   a , the optimal transit appliance for software service  110 B is appliance  106   b , and the optimal transit appliance for software service  110 N is appliance  106   n . As discussed further herein, appliances  106   a ,  106   b , and  106   n  can be geographically located anywhere in the world. 
       FIG. 1B  depicts an exemplary system environment for determining a transit appliance for transfer of data to and from a software service across the one or more interconnected networks. In the exemplary embodiment, an end user accesses a software service, such as software service  110 A, through computer  102 . Computer  102  may be a desktop computer, laptop computer, handheld computing device, server, or any other type of computing device. While a single computer is depicted here, computer  102  may also be a cluster of computing devices. 
     The request for software service  110 A from computer  102  is transmitted via appliance  104 , which is in communication with computer  102  through a network  108 . The network  108  may include one or more of the following: WAN, the Internet, Metropolitan Area Network (MAN), Backbone network, Storage Area Network (SAN), Advanced Intelligent Network (AIN), Local Area Network (LAN), Personal Area Network (PAN), and so forth. 
     Appliance  104  can be any type of hardware device, or software operational on a computing device. Appliance  104  may be located at the same geographical location as computer  102 , or may be located in a remote location. Appliance  104  may be in communication with other appliances across the network, such as appliances  106 ,  116 , and  112 , regardless of geographical location of the appliances. While appliance  104  is in communication with three other appliances in the exemplary embodiment depicted in the figure, there may be any number of appliances in the system. The appliances together may form an overlay network over the one or more interconnected networks between computer  102  and software service  110 A. 
     Each of the appliances in the system may further be in communication with a portal  114 . Portal  114  comprises a database with a service directory for the various software services, the IP addresses/subnets associated with each software service, and one or more test methods for determining network performance characteristics for each appliance in relation to the IP addresses/subnets associated with each software service. Portal  114  is also discussed in further detail below with respect to later figures. Each appliance in the overlay network is in communication with the portal  114  and retrieves a copy of the service directory. In various embodiments, the service directory is stored locally at each appliance, and the local copy at each appliance is updated on a fixed periodic schedule, upon a change in the service directory, upon the direction of a network administrator, or other triggering event. Exemplary changes in the service directory include the addition of a new software service, deletion of a software service, a change in an associated IP address/subnet, or a change in a test method. 
     Software service  110 A may have an exemplary IP subnet of a.b.c.d/24. An appliance may query an IP address from the IP subnet using the information from the portal service directory to determine network performance characteristic(s) for the transmission of data between that appliance and software service  110 A. The performance metric comprises information such as latency, round trip time, data loss, or any other network performance characteristic. The appliance then stores the measured performance metric(s) for the IP address or subnet in a local network performance characteristics table or database, referred to herein as a measured metric table. The measured metric table is discussed in further detail below in connection with  FIG. 3 . 
       FIG. 2  shows an exemplary service directory  200  from the portal  114 . In various embodiments, the service directory  200  provides a listing of the various software services that are available for optimized access through the overlay network of appliances. There can be any number of software services in the service directory, such as software service  110 A,  1106 , and  110 N. Each software service can have one or more IP addresses or IP subnet associated with it. The IP addresses may be in IPv4, IPv6, or other network addressing systems. While the term “IP address” has been used throughout this disclosure, a person of ordinary skill in the art would understand that any other network addressing system besides IP is also within the scope of this disclosure. 
     The service directory  200  can provide a listing of each IP address or subnets associated with the software service, one or more test IP addresses, and one or more test methods for the IP addresses. In various embodiments, additional data associated with each software service is also stored in the service directory  200 , as understood by a person of ordinary skill in the art. The service directory  200  can be updated on a fixed periodic schedule, upon certain trigger events, or as directed by a network administrator. 
     In the exemplary service directory  200  of  FIG. 2 , software service  110 A has two exemplary IP subnets, 152.3.4.0/24 and 97.5.6.0/24. The subnets may be in different geographical locations. Each IP subnet has one or more test methods associated with it. The test method can be ping IP, http-ping IP, tcp-ping IP, or any other test method as understood by a person of ordinary skill in the art. Each test method denotes the mechanism whereby the appliance queries an IP address associated with the software service to determine network performance characteristic(s) for the transmission of data from that appliance to the software service. As understood by a person of ordinary skill in the art, the subnet may contain many IP addresses. The test method may sample one or more of the included IP addresses, as testing every IP address in the subnet may introduce more traffic and overhead for very little additional information. Also, one service may have different optimal transit nodes for different parts of the service. 
       FIG. 3  shows an exemplary measured metric table  300  stored at each appliance for collecting measured metrics from that appliance to each software service. For each software service, the IP address or subnet associated with that software service is noted, along with the test method(s) used. The listing of software services, IP address/subnet, and test method(s) may be retrieved by each appliance from the service directory  200  in portal  114 . In various embodiments, the measured metric table  300  is updated on a periodic fixed schedule, upon direction by a network administrator, or upon another triggering event, such as a change or addition of a subnet. Upon receipt of new information or a new service directory  200  from the portal  114 , the information may be merged into the measured metric table  300  such that previous information from the measured metric table is maintained, if still applicable. Additionally, while the measured metric table and all other tables are described herein as “tables”, the data can also be represented using other data structures, as understood by a person of ordinary skill in the art. 
     In exemplary embodiments, an appliance queries one or more IP addresses associated with each software service in the table using the one or more test methods and measures one or more network performance characteristics. These characteristics may be stored in the measured metric table  300  as the measured metric(s). A derived metric related to the measured metric(s) is also stored in the measured metric table  300 . The derived metric is a calculated or selected metric value that may be advertised, along with the corresponding tested IP address or subnet, with other peer appliances in the overlay network. 
     In the exemplary embodiment of  FIG. 3 , software service  110 A has two associated IP subnets. For the IP subnet 152.3.4.0/24, the appliance queries the IP address 152.3.4.5 using a ping test method and measures a network performance metric of 70 milliseconds. For the IP subnet 97.5.6.0/24, the appliance queries the IP address 97.5.6.50 using an http-ping test method and measures a metric of 80 milliseconds, and also queries the IP address 97.5.6.51 using a tcp-ping test method and measures a metric of 70 milliseconds. In various embodiments, each measured metric may be stored in the measured metric table  300  fora fixed period of time, upon expiry of which it may need to be measured again. Additionally, the measured metric table  300  may keep a rolling average or other statistical aggregation for each measured metric instead of only the latest measured value(s). The statistical aggregation may be reflected in the measured metric(s), derived metric, or an additional field in the measured metric table  300 . 
     From the various measured metrics, a derived metric may be calculated or selected for each tested IP address or subnet. The derived metric may be an average, mean, median, or any other statistical or calculated value from the one or more measured metrics. In the exemplary embodiment of  FIG. 3 , the derived metric for the IP subnet 97.5.6.0/24 is based on a scaled average of the two measured metrics from the http-ping and tcp-ping test methods. The derived metric may be updated on a periodic fixed schedule, as directed by a network administrator, or upon a triggering event, such as a change in a measured metric value. 
     In exemplary embodiments, the derived metric is then advertised by an appliance with the other appliances in the overlay network. For example, in the exemplary system environment of  FIG. 1B , appliance  104  advertises one or more of its derived metric(s) for the IP address/subnet associated with software service  110 A, with the peer appliances  106 ,  116 , and  112 . Similarly, one or more of the other appliances  106 ,  116 , and  112  may also advertise one or more of their derived metric(s) for the IP address/subnet associated with software service  110 A with all other peer appliances in the network. In various embodiments, an appliance may advertise all of the derived metrics for a particular software service, or only advertise a derived metric that is closest to a specified value, or a derived metric representative of the most ideal network characteristics, such as the lowest value or highest value. The derived metrics may be advertised to the other peer appliances on a periodic schedule, as directed by a network administrator, or upon a triggering event, such as a change in a derived metric value. Furthermore, if the derived metric is below or above a certain threshold, it may not be advertised with the other peer appliances. 
       FIG. 4  shows an exemplary advertised metric table  400  for collecting advertised metrics from the appliances in the overlay network. While  FIGS. 2-4  have been described herein as a “table,” the data can be represented by other data structures as well, as understood by a person of ordinary skill in the art. 
     The advertised metric table  400  shows that for exemplary subnet a.b.c.d/24, peer appliance  104  has advertised a performance metric of 5, peer appliance  106  has an advertised performance metric of 20, peer appliance  116  has an advertised performance metric of 10, and peer appliance  112  has an advertised performance metric of 7.5. In various embodiments, a transit appliance for each IP subnet is selected based on the peer appliance with the lowest value advertised metric, the highest value advertised metric, or the advertised metric that is closest to a specified value. The specified value can be any value determined by a network administrator. In the exemplary embodiment of  FIG. 4 , the selected performance metric for subnet a.b.c.d/24 is the lowest value of 5, which corresponds to appliance  104 . As such, appliance  104  is the optimal transit appliance to route data traffic through for the subnet a.b.c.d/24. In the exemplary embodiment of  FIG. 4 , the selected metric is noted by a box around the number. In other embodiments, the selected metric can be noted by any other means. Additionally, the advertised metric table  400  may optionally comprise one or more additional columns to note the peer appliance with the selected metric for the IP subnet as the optimal transit appliance, or to store any other information. 
     For exemplary subnet e.f.g.h/20, peer appliance  104  has an advertised metric of 15, peer appliance  106  has an advertised metric of 20, peer appliance  116  has an advertised metric of 10, and peer appliance  112  has an advertised metric of 8. If the selected performance metric is taken as represented by the lowest value, then peer appliance  112  is the selected transit appliance for the subnet e.f.g.h/20. 
     Advertised metric table  400  may be stored locally at each appliance, or stored in another central location that is accessible by all of the peer appliances, or stored and shared between appliances in other ways. In various embodiments, the table is updated on a periodic schedule, upon direction by a network administrator, or upon another triggering event, such as a change or addition of a subnet, peer appliance, or updated advertised metric. In various embodiments, each peer appliance&#39;s advertised metric may be stored in the advertised metric table  400  for a fixed period of time, upon expiry of which it may need to be updated. Additionally, the advertised metric table  400  may keep a rolling average or other statistical aggregation for each advertised metric instead of only the latest advertised values. 
     Now referring to  FIG. 5 , a flowchart  500  showing an exemplary method for the determination of a transit appliance to a software service is presented. The method may be performed by one or more peer appliances in the network. Additionally, steps of the method may be performed in varying orders or concurrently. Furthermore, various steps may be added, removed, or combined in the method and still fall within the scope of the present invention. 
     In step  510 , an appliance retrieves information from the service directory  200 . In step  520 , the appliance measures performance metric(s) to one or more specified software services using the information from the service directory, such as the IP address or subnet for each software service and test method(s). From the measured metric(s), derived metric(s) are determined for each tested IP address, and the information is stored in the measured metric table  300  at the appliance in step  530 . The appliance advertises a selected derived performance metric to the other peer appliances in step  540 . As previously disclosed, the appliance may not advertise a derived performance metric if the derived performance metric is outside of a specified threshold. In step  550 , the advertised metric table  400  at each peer appliance in the network is updated with the advertised performance metric if an updated advertised performance metric value was advertised. The optimal transit appliance for each software service is determined from the advertised metric table, as discussed above. The advertised metric may also have a time period for which it is valid, upon expiry of which it is calculated, selected, or advertised again. 
     Each step of the method may be performed at different times (asynchronously), even though it is depicted as a sequence in  FIG. 5 . For example, if the measured metric doesn&#39;t change for a particular appliance, then it may not be advertised in step  540 . Additionally, each appliance in the network can perform each step of this method at varying times. Steps of the method may be performed on a periodic fixed schedule, at the direction of a network administration, or upon any other triggering event. 
       FIG. 6  shows an exemplary system environment suitable for implementing methods for optimization of data across one or more interconnected networks. Three software services are depicted in the exemplary embodiment of  FIG. 6 , software service  110 A,  110 B, and  110 N. However, there can be any number of software services in communication with the various appliances of the overlay network. While two appliances are depicted in the exemplary system of  FIG. 6 , there can be any number of appliances in communication over one or more interconnected networks. 
     In the exemplary system of  FIG. 6 , an end user accesses a software service, such as software service  110 N, through computer  102  by sending data packets to software service  110 N via appliance  104  through network  606 . As discussed above with respect to  FIGS. 1A and 1B , computer  102  may be a desktop computer, laptop computer, handheld computing device, server, or any other type of computing device. While a single computer is depicted here, computer  102  may also be a cluster of computing devices. Also, network  606  may be any type of network, as discussed above with respect to network  108  of  FIG. 1B . 
     Appliance  104  may extract the IP address for software service  110 N from the destination IP address in the data packets it receives from the computer  102 . Appliance  104  may then query its advertised metric table  400  for the peer appliance in the overlay network via which to direct the request for the software service based on the extracted IP address. The selected peer appliance may constitute the optimal transit appliance for the extracted IP address. If the advertised metric table  400  contains a transit appliance for the extracted IP address of the software service, appliance  104  directs the request via the transit appliance noted for the IP address. A row of the advertised metric table  400  is said to contain an IP address, if that IP address belongs inside the subnet that the row corresponds to. Furthermore, a user request for a software service may be directed through any number of network appliances, routers, switches, or other network devices before the request is routed to the software service, depending on the network path. 
     In the exemplary embodiment depicted in  FIG. 6 , appliance  104  determines that the optimal transit appliance for the extracted IP address associated with desired software service  110 N is through appliance  106  located at service  118 A. Service  118 A may contain computing devices that enable software service  110 N, or may be unrelated to software service  110 N. By placing appliance  106  at IaaS service  118 A, appliance  106  may be located close to software service  110 N. As such, appliance  106  may have good network performance characteristics for data transfer to and from software service  110 N and is likely to be a good transit appliance for software service  110 N. 
     While services  118 A,  118 B, and  118 N are depicted in  FIG. 6  as exemplary cloud services within an IaaS location, they may be located outside of the cloud. Furthermore, appliance  106  may be located anywhere in the world, and may not necessarily be in an IaaS center.  FIG. 6  depicts an exemplary embodiment where appliance  106  is the selected transit appliance for software service  110 N and is located at an IaaS service. 
     In various embodiments, appliance  106  also performs network address translation (NAT) on the data before forwarding the software service request to software service  110 N, such that the request for software service  110 N appears to originate from appliance  106 . This way, the reply from software service  110 N is also routed back through the transit appliance  106 . 
     In some cases, appliance  104  may determine that there is no optimal transit appliance for software service  110 N, or the transit appliance is appliance  104 . If there is no optimal transit appliance for software service  110 N, the user request for software service  110 N may be directed from appliance  104  to software service  110 N over the network  620 , without using the overlay of optimizing peer appliances. Network  620  can be any type of network, including a Wide Area Network (WAN), the Internet, and so forth. In various embodiments, default routing behavior is also stored in one or more routing tables. The routing tables can be stored in each appliance of the network, and/or in a central location accessible to all appliances. 
     Software service  110 N may process the data packets received from appliance  106  and direct the reply to the appliance from which the request was forwarded, in this case appliance  106  located in Service  118 A. Appliance  106  then performs network address translation on the data, to direct it to the appliance originating the request, appliance  104 . From appliance  104  the reply is sent back to computer  102 . In various embodiments, there may be any number of intermediate appliances between appliance  104  and software service  110 N. Each intermediate appliance may perform network address translation to ensure that the reply is routed back through the network via the same path. 
       FIG. 7A  is an exemplary flow diagram  700 A for the transmission of data packets for a software service through one or more interconnected networks via a first appliance. The method may be performed by one or more peer appliances in the network. Additionally, steps of the method may be performed in varying orders or concurrently. Furthermore, various steps may be added, removed, or combined in the method and still fall within the scope of the present invention. 
     At step  710 , a first appliance (such as appliance  104 ) receives data packets sent by a user destined for a software service from computer  102 . In step  720 , the first appliance extracts the destination IP address for the software service from the received data packets. At step  730 , the first appliance determines if the extracted destination IP address is in one of the subnets in the advertised metric table  400 . If not, the first appliance transmits the data packets destined for the software service to the destination IP address for the software service via default routing behavior in step  740 . If the destination IP address is in the advertised metric table  400 , the first appliance queries the advertised metric table  400  for the selected transit appliance for the destination IP address, in step  750 . While IP addresses are used in this example, the invention can also be applied to other network addressing types. 
     At step  760 A, the first appliance may optionally optimize the data packets destined for the software service. Data optimization techniques may comprise compression/decompression, deduplication, TCP acceleration, performance enhancing proxy, packet reconstruction, error correction, or any other technique for optimizing data transfer between network appliances or devices. For simplification purposes, the term ‘optimization encoding’ is used in the figures. However, a person of ordinary skill in the art would understand that any optimization technique may be applied. Optimization encoding and decoding are symmetric transformations of data, such as compression/decompression, deduplication, etc. For example, data packets that are compressed at a first appliance need to be decompressed at a second appliance. At step  760 B, the first appliance transmits the data packets for the software service to the optimal transit appliance with the selected performance metric. Optimization may be performed on a packet by packet basis, such that there is an encoded packet for each original packet, or optimization may be performed on parts of packets or across multiple packets, such that there is not a 1:1 correspondence between the original packets and the encoded packets. 
       FIG. 7B  is an exemplary flow diagram  700 B for the transfer of data packets for a software service through a transit appliance, also referred to as a second appliance. At step  770 A, a second appliance (such as transit appliance  106  from  FIG. 6 ) receives plain or encoded data packets representing data sent by a user destined for a software service from computer  102 . At step  770 B, the second appliance optionally applies optimization decoding of the data packets. If data packets from the first appliance were optimized in step  760 A in any way, such as encoded, then the packets may be decoded at step  770 B. 
     In step  772 , the second appliance performs network address translation to change the source network address in the data packets to its own local network address. At step  774 , the second appliance sends the modified data packets to the destination IP address of the requested software service. Response packets are received from the software service at step  776 . The second appliance then maps the destination address from the response packets to the original user&#39;s IP address (such as the IP address of computer  102 ), at step  778 . The data packets from the software service are then optionally encoded at step  780 A by the second appliance. This may be a similar step to the optimization technique applied at the first appliance in step  760 A, or a different optimization technique may be applied to the reply data packets. The data packets are transmitted back to the first appliance (or ingress appliance) at step  780 B. The first appliance transmits the response data packets from the software service to computer  102 . 
       FIG. 8  illustrates an exemplary screenshot of a graphical user interface (GUI)  800  for a user to select optimization of data traffic to and from particular software services. The GUI  800  may be shown on a display of a user device (not shown) such as a personal computer (PC), a tablet computer, a mobile device, or any other suitable device. In an example, the GUI  800  is shown on the display of the user device via a browser or some other software application. 
     In various embodiments, the GUI  800  has a listing in column  810  of software services that are available for optimization. The service listing in column  810  may be updated on a periodic fixed schedule, upon the direction of a network administrator, or upon a triggering event. Column  820  of the GUI is an optional column that can show one or more IP addresses or subnet associated with each service. For each service available for optimization, the GUI  800  can optionally also provide the selected transit appliance from the overlay network to the service, in column  830 . In column  840 , a network administrator or end user can select which service it would like to determine the optimal transit appliance for. In exemplary embodiments, an end user may choose to enable optimization only for services that are actually used, or for services that are used frequently. Even though only checkboxes are shown in the optimization table, other selectable items can be provided, such as radio buttons or the like. 
       FIG. 9  shows an exemplary global network of appliances in the overlay network. While there are only five appliances depicted in the figure, there can be any number of appliances connected to the overlay network, and they can be located in any geographic location around the world. A request for software service  110 A may originate from computer  102  in any appliance location. Each appliance is in communication with portal  114 , and maintains a copy of the service directory  200 , a measured metric table  300 , and an advertised metric table  400 . Each appliance also is in communication with the other global appliances, and advertises its performance metric with the peer appliances. Furthermore, each appliance in the network may provide data optimization techniques. The transit appliance for software service  110 A may be through any appliance in the global network. In exemplary embodiments, the transit appliance is the appliance geographically located closest to software service  110 A, but does not have to be. 
     Thus, methods and systems for determining a transit appliance for data traffic to and from a software service are disclosed. Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes can be made to these example embodiments without departing from the broader spirit and scope of the present application. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.