Patent Publication Number: US-11658902-B2

Title: Session monitoring using metrics of session establishment

Description:
This application claims the benefit of U.S. Provisional Application No. 63/014,477, filed on Apr. 23, 2020, the entire content of which is incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     This disclosure generally relates to computer networks, and, more specifically, routing packets within computer networks. 
     BACKGROUND 
     A computer network is a collection of interconnected computing devices that can exchange data and share resources. Example computing devices include routers, switches, and other Layer 2 (L2) network devices that operate within Layer 2 of the Open Systems Interconnection (OSI) reference model, i.e., the data link layer, and Layer 3 (L3) network devices that operate within Layer 3 of the OSI reference model, i.e., the network layer. Network devices within computer networks often include a control unit that provides control plane functionality for the network device and forwarding components for routing or switching data units. 
     The computing devices may establish a “network session” (also referred to herein as “session”) to enable communication between devices on a computer network. A session may be bidirectional in that the session includes packets traveling in both directions between a first device and a second device. For example, a session includes a forward packet flow originating from a first device and destinated for a second device and a reverse packet flow originating from the second device and destined for the first device. The forward and reverse packet flows of the session are related to one another in that the source address and source port of the forward packet flow is the same as the destination address and destination port of the reverse packet flow, and the destination address and destination port of the forward packet flow is the same as the source address and source port of the reverse packet flow. To establish a session, computing devices may use one or more communication session protocols including Transmission Control Protocol (TCP), Transport Layer Security (TLS), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), etc. 
     SUMMARY 
     In general, the disclosure describes techniques for monitoring a session using metrics of session establishment for the session. A client device may establish a session to access a network service instantiated by a network service instance (also referred to herein as a “service instance”). After the session is established, traffic is forwarded along a forward path and a reverse path between the client device and the service instance. In some examples, a session may fail to be established, an existing session may longer be established, or the session may underperform according to session performance requirements (e.g., requirements defined by a Software License Agreement (SLA)). This may occur even when no operation problem exists, e.g., with the path or router interfaces on an intermediary network between the client device and the network service instance. For example, a client device may attempt to establish a first communication session (e.g., TLS session) with a first network service instance. The first network service instance may successfully complete the key exchange phase and the server parameters phase of the TLS handshake, but fail to complete the authentication phase of the TLS handshake. Thus, the first TLS session between the client device and the first network service instance fails to establish, even though no problem exists at the link, network, or transport levels (e.g., OSI reference model Layers 2, 3, or 4) between the client device and the first network service instance. Typically, a router may be unable to detect problems at the session level (e.g., OSI reference model Layer 5), and therefore may be unable to reroute network traffic at the session level where the paths and interfaces to service instance  104  is properly operating. Furthermore, rerouting traffic at Layers 2, 3, or 4, may disrupt other sessions that share an interface of the router or similar path as the problematic session but remain operable. 
     In accordance with the techniques of the disclosure, a router generates one or more metrics of session establishment for a session. For example, a router as described herein may obtain metrics of session establishment (also referred to herein as “session establishment metrics”) and use such metrics to determine that whether a session has been established (or fails to be established) between a client device and a network service instance and/or whether the established session does not meet session performance requirements (also referred to herein as “session requirements”). The router may use the session metrics and session performance requirements to determine whether to switch the network traffic for the session between the client device and the network service instance from a first path to a second path so as to ensure compliance with the session performance requirements without disrupting other, operable sessions that traverse the first path. 
     For example, an intermediate network comprises a plurality of routers and is positioned between a client device and a network service instance hosted by a server. A first router within the intermediate network is connected to the network service instance via a first path and a second path that is different than the first path. For example, the first path and the second path may each include at least one router that is different or at least one interface of the same router that is different, etc. The first router forwards, along the first path, network traffic for a session between the client device and the network service instance. 
     In some examples, the first router is configured to perform session-based routing for the session between the client device and the network service instance. For example, the first router modifies a first packet of at least one of a forward packet flow and a reverse packet flow of the session to include a header comprising a source address of the first router and a destination address of a second router along the first path and a portion of metadata specifying a session identifier for the session. 
     The first router obtains one or more metrics of session establishment of the session between the client device and the network service instance. The metrics of session establishment may describe data related to the successful or unsuccessful establishment of one or more sessions. For example, the session establishment metrics may include, e.g., a time elapsed to establish the session, a number of sessions that successfully establish, a number of sessions that fail to establish due to timeout, a number of sessions that fail to establish due to an unreachable destination, a number of sessions that close prior to session establishment, etc. The first router may derive the metrics of session establishment by monitoring the state of the first session prior to, during, or after establishment. 
     The first router receives one or more session performance requirements for the session between the client device and the network service instance, which may include SLA requirements for the session. The first router compares the metrics to the session performance requirements. In response to determining that the one or more metrics of session establishment of the session do not satisfy the one or more session performance requirements for the session, the first router forwards, along the second path, the network traffic for the session between the client device and the network service instance. In some examples, the first router modifies a second packet of at least one of the forward packet flow and the reverse packet flow of the session to include a header comprising a source address of the first router and a destination address of a third router along the second path and the portion of metadata specifying the session identifier for the session. 
     In some examples, the first router removes the first path from inclusion in a session load balancer that load balances customer traffic associated with the network service along different paths. Additionally, a router as described herein may use such metrics to select one or more sessions, detect blackholing of traffic, determine that a session does not satisfy SLA requirements, or to load balance customer traffic associated with a network service across different paths. 
     The techniques of the disclosure may provide specific improvements to the computer-related field of computer networking and path selection that have practical applications. For example, the techniques of the disclosure may enable a router to monitor a state of a session to determine whether the session has established, and generate metrics related to whether the session has established. A router as described herein may use such metrics to perform path selection and routing at the session level (e.g., OSI reference model Layer 5), as opposed to other routers which may be only able to perform path selection and routing at the link, network, or transport levels (e.g., OSI reference model Layers 2, 3, or 4). Accordingly, such a router may provide more efficient and granular routing of customer traffic within the network. 
     Additionally, a router as described herein may use metrics of session establishment to determine whether a session satisfies SLA requirements, and in response, select a different path or interface for transporting network traffic associated with the session, so as to ensure compliance with the SLA. Such a router as described herein may therefore detect networking problems at the session level, (e.g., OSI reference model Layer 5), even where no problem exists with an interface or path at the link, network, or transport levels (e.g., OSI reference model Layers 2, 3, or 4), and perform actions to ensure compliance with session-level SLA requirements. 
     Additionally, the techniques of the disclosure may enable a router as described herein to switch from using a first interface or path to forward network traffic associated with an underperforming session to using a second interface or path to forward the network traffic associated with underperforming session, without tearing down the first path or deactivating the first interface. Therefore, the techniques of the disclosure may enable the router to reroute traffic for an underperforming session without adversely affecting other sessions that perform according to SLA requirements but, e.g., share a path with the underperforming session, or use the same interface as the underperforming session. Thus, a router as described herein may provide more granular and efficient routing of customer traffic over other routers that may be required to tear down a path or deactivate an interface associated with an underperforming session. 
     In one example, this disclosure describes a method comprising: receiving, by a first router of a plurality of routers of a network connecting a client device to a network service instance hosted by a server, one or more session performance requirements for a session between the client device and the network service instance, the session comprising a forward packet flow and a reverse packet flow, wherein the first router is connected to the network service instance via a first path on the network and a second path on the network, the second path being different from the first path; forwarding, by the first router and along the first path, network traffic for the session between the client device and the network service instance, the forwarding including modifying a first packet of at least one of the forward packet flow and the reverse packet flow of the session to include: a header comprising a source address of the first router and a destination address of a second router of the plurality of routers along the first path; and a portion of metadata specifying a session identifier for the session; obtaining, by the first router, one or more metrics of session establishment of the session; determining, by the first router, that the one or more metrics of session establishment of the session do not satisfy the one or more session performance requirements for the session; and in response to determining that the one or more metrics of session establishment of the session do not satisfy the one or more session performance requirements for the session, forwarding, by the first router and along the second path, the network traffic for the session between the client device and the network service instance, the forwarding including modifying a second packet of at least one of the forward packet flow and the reverse packet flow of the session to include: a header comprising a source address of the first router and a destination address of a third router of the plurality of routers along the second path; and the portion of metadata specifying the session identifier for the session. 
     In another example, this disclosure describes a first router of a plurality of routers of a network, the first router comprising: processing circuitry; and a memory operably coupled to the processing circuitry and comprising instructions configured to cause the processing circuitry to: receive one or more session performance requirements for a session between a client device and a network service instance hosted by a server, the session comprising a forward packet flow and a reverse packet flow, wherein the first router is connected to the network service instance via a first path on the network and a second path on the network, the second path being different from the first path, and wherein the network connects the client device to the network service instance; forward, along the first path, network traffic for the session between the client device and the network service instance, the forwarding including modifying a first packet of at least one of the forward packet flow and the reverse packet flow of the session to include: a header comprising a source address of the first router and a destination address of a second router of the plurality of routers along the first path; and a portion of metadata specifying a session identifier for the session; obtaining, by the first router, one or more metrics of session establishment of the session; determine that the one or more metrics of session establishment of the session do not satisfy the one or more session performance requirements for the session; and in response to determining that the one or more metrics of session establishment of the session do not satisfy the one or more session performance requirements for the session, forward, along the second path, the network traffic for the session between the client device and the network service instance, the forwarding including modifying a second packet of at least one of the forward packet flow and the reverse packet flow of the session to include: a header comprising a source address of the first router and a destination address of a third router of the plurality of routers along the second path; and the portion of metadata specifying the session identifier for the session. 
     In another example, this disclosure describes a non-transitory, computer-readable medium comprising instructions that, when executed, are configured to cause processing circuitry of a first router of a plurality of routers of a network to: receive one or more session performance requirements for a session between a client device and a network service instance hosted by a server, the session comprising a forward packet flow and a reverse packet flow, wherein the first router is connected to the network service instance via a first path on the network and a second path on the network, the second path being different from the first path, and wherein the network connects the client device to the network service instance; forward, along the first path, network traffic for the session between the client device and the network service instance, the forwarding including modifying a first packet of at least one of the forward packet flow and the reverse packet flow of the session to include: a header comprising a source address of the first router and a destination address of a second router of the plurality of routers along the first path; and a portion of metadata specifying a session identifier for the session; obtaining, by the first router, one or more metrics of session establishment of the session; determine that the one or more metrics of session establishment of the session do not satisfy the one or more session performance requirements for the session; and in response to determining that the one or more metrics of session establishment of the session do not satisfy the one or more session performance requirements for the session, forward, along the second path, the network traffic for the session between the client device and the network service instance, the forwarding including modifying a second packet of at least one of the forward packet flow and the reverse packet flow of the session to include: a header comprising a source address of the first router and a destination address of a third router of the plurality of routers along the second path; and the portion of metadata specifying the session identifier for the session. 
     The details of one or more examples of the techniques of this disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques will be apparent from the description and drawings, and from the claims. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG.  1    is a block diagram illustrating an example computer network system in accordance with the techniques of the disclosure. 
         FIG.  2    is a block diagram illustrating an example router in accordance with the techniques of the disclosure. 
         FIGS.  3 A and  3 B  are block diagrams illustrating an example computer network system that performs path selection based on metrics of session establishment in accordance with the techniques of the disclosure. 
         FIG.  4    is a flowchart illustrating an example operation in accordance with the techniques of the disclosure. 
     
    
    
     Like reference characters refer to like elements throughout the figures and description. 
     DETAILED DESCRIPTION 
       FIG.  1    is a block diagram illustrating example computer network system  2  in accordance with the techniques of the disclosure. In the example of  FIG.  1   , computer network system  2  includes service provider networks  150 A- 150 D (collectively, “service provider networks  150 ”) configured to provide Wide Area Network WAN) connectivity to disparate customer networks  140 A- 140 B (“customer networks  140 ”). Routers  110 A- 110 I (collectively, “routers  110 ”) of service provider networks  150  provide client device  100  and server  103  associated with customer networks  140  with access to service provider networks  150  via customer edge devices  102 A- 102 B (collectively, “CE devices  102 ”). In some examples, customer network  140 A is an enterprise network. In some examples, customer network  140 B is a cloud service provider (CSP) network that provides a network service to client device  100  in the form of service instance  104  hosted by server  103 . Customer network  140 A is depicted as having a single client device  100  for ease of illustration. Typically, customer network  140 A includes many client devices  100 , each of which may access CSP network  140 B to access one or more network services. Communication links  16 A- 16 G (collectively, links “16”) may be Ethernet, ATM or any other suitable network connections. 
     CE devices  102  and routers  110  are illustrated as routers in the example of  FIG.  1   . However, techniques of the disclosure may be implemented using any router, such as switches, routers, gateways, or other suitable routers that may send and receive network traffic. Customer networks  140  may be networks for geographically separated sites of an enterprise, for example. Each of customer networks  140  may include additional customer equipment, such as, one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other routers not depicted in  FIG.  1   . The configuration of computer network system  2  illustrated in  FIG.  1    is merely an example. For example, computer network system  2  may include any number of customer networks  140 . Nonetheless, for ease of description, only customer networks  140 A- 140 B are illustrated in  FIG.  1   . 
     Service provider networks  150  represent one or more publicly accessible computer networks that are owned and operated by one or more service providers. Although computer network system  2  is illustrated in the example of  FIG.  1    as including multiple interconnected service provider networks  150 , in other examples computer network system  2  may alternatively include a single service provider network that provides connectivity between customer networks  140 . A service provider is usually a large telecommunications entity or corporation. Each of service provider networks  150  is usually a large Layer-Three (L3) computer network, where reference to a layer followed by a number refers to a corresponding layer in the Open Systems Interconnection (OSI) model. Each service provider network  150  is an L3 network in the sense that it natively supports L3 operations as described in the OSI model. Common L3 operations include those performed in accordance with L3 protocols, such as the Internet Protocol (IP). L3 is also known as a “network layer” in the OSI model and the term L3 may be used interchangeably with the phrase “network layer” throughout this disclosure. 
     Although not illustrated, each service provider network  150  may be coupled to one or more networks administered by other providers, and may thus form part of a large-scale public network infrastructure, e.g., the Internet. Consequently, customer networks  140  may be viewed as edge networks of the Internet. Each service provider network  150  may provide computing devices within customer networks  140 , such as client devices  100  and destination devices  103 , with access to the Internet, and may allow the computing devices within customer networks  140  to communicate with each other. 
     Although additional routers are not shown for ease of explanation, it should be understood that system  2  may comprise additional network and/or computing devices such as, for example, one or more additional switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other routers. Moreover, although the elements of system  2  are illustrated as being directly coupled, it should be understood that one or more additional network elements may be included along any of network links  16 , such that the network elements of system  2  are not directly coupled. 
     Each service provider network  150  typically provides a number of residential and business services for customer networks  140 , including residential and business class data services (which are often referred to as “Internet services” in that these data services permit access to the collection of publicly accessible networks referred to as the Internet), residential and business class telephone and/or voice services, and residential and business class television services. 
     Session-Based Routing 
     In some examples, routers  110  may implement a stateful, session-based routing scheme that enables each router  110  to independently perform path selection and traffic engineering. The use of session-based routing may enable routers  110  to eschew the use of a centralized controller, such as a Software-Defined Networking (SDN) controller to perform path selection and traffic engineering. In this way, routers  110  may be more efficient and scalable for large networks where the use of an SDN controller would be infeasible. Furthermore, the use of session-based routing may enable routers  110  to eschew the use of tunnels, thereby saving considerable network resources by obviating the need to perform encapsulation and decapsulation at tunnel endpoints. In some examples, routers  110  implement session-based routing as Secure Vector Routing (SVR), provided by Juniper Networks, Inc. 
     In the example of  FIG.  1   , client device  100  of system  2  establishes session  40  with service instance  104 . Routers  110  facilitate establishment of session  40  by transporting network traffic between client device  100  and service instance  104 . In some examples, client device  100  may be considered a “source” device in that client device  100  originates sessions  40  between client device  100  and service instance  104 , e.g., client device  100  is the “source” of the first packet of the forward flow of the session. Session  40  includes a forward packet flow originating from client device  100  and destined for service instance  104  hosted by server  103  and a reverse packet flow originating from service instance  104  and destined for client device  100 . A forward flow for session  40  traverses a first path including, e.g., client device  100 , CE device  102 A, routers  110 A,  110 D, and  110 E- 110 I, CE device  102 B, and server  103 . As described in more detail below, after determining session establishment metrics for session  40  fails to satisfy session performance requirements, routers  110  may dynamically select a second path over which to forward network traffic for session  40  (represented in  FIG.  1    as session  40 ′). A forward flow for session  40 ′ traverses the second path, which includes, e.g., client device  100 , CE device  102 A, routers  110 A,  110 C, and  110 E- 110 I, CE device  102 B, and server  103 . As depicted in the example of  FIG.  1   , at least a portion of the first path and second path are the same (e.g., first and second paths both include routers  110 A and  110 E- 110 I). However, the first and second paths diverge in that the first path traverses router  110 D, while the second path traverses router  110 C. 
     Client device  100  may establish session  40  according to one or more communication session protocols including TCP, TLS, UDP, or ICMP, etc. For example, to establish session  40  according to TCP such that data may be exchanged according to TCP, client device  100  and service instance  104  perform a three-way handshake. Client device  100  sends a first packet comprising a “SYN” flag to service instance  104 . Service instance  104  acknowledges receipt of the first packet by responding to client device  100  with a second packet comprising a “SYN-ACK” flag. Client device  100  acknowledges receipt of the second packet by responding to service instance  104  with a third packet comprising an “ACK” flag. After sending the third packet, session  40  is established according to TCP and client device  100  and service instance  104  may exchange data with one another via session  40 . Additional example information regarding TCP is described in “TRANSMISSION CONTROL PROTOCOL,” Request for Comments (RFC) 793, Internet Engineering Task Force (IETF), September 1981, available at https://tools.ietf.org/html/rfc793, the entire contents of which are incorporated herein by reference. 
     To establish session  40  according to TLS session, client device  100  and service instance  104  perform a TLS handshake to establish a secure connection is in place before transferring data. The TLS handshake occurs in three phases: a key exchange phase, a server parameters phase, and a authentication phase. In the key exchange phase, client device  100  sends a ClientHello message that includes cipher and key information. Service instance  104  responds with a ServerHello message, which indicates negotiated connection parameters. The combination of the ClientHello and the ServerHello determines the shared keys. During the server parameters phase, service instance  104  sends an EncryptedExtensions message followed by a CertificateRequest message to establish the server parameters. Finally, during the authentication phase, client device  100  and service instance  104  exchange authentication messages. Specifically, service instance  104  sends an optional Certificate message, a CertificateVerify message, and a Finished message. Upon receiving the messages from service instance  104 , client device  100  responds with its Authentication messages, e.g., a Certificate message, a CertificateVerify message (if requested), and a Finished message. After client device  100  transmits the Finished message, the handshake is complete, and client device  100  and service instance  104  may exchange data with one another via session  40  according to TLS. Additional example information regarding TLS is described in “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, IETF, August 2008, available at https://tools.ietf.org/html/rfc5246; and “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, IETF, August 2018, available at https://tools.ietf.org/html/rfc8446, the entire contents of each of which are incorporated herein by reference. 
     UDP is a connectionless protocol in that client device  100  does not verify that the service instance  104  is capable of receiving data prior to transmitting data. To establish session  40  according to UDP, client device  100  transmits a first packet to service instance  104 . Session  40  may be considered “established” according to UDP upon receipt by client device  100  of any packet from service instance  104 , which implies that service instance  104  successfully received the first packet from client device  100 , responded, and client device  100  was able to receive the response from service instance  104 . Additional example information regarding UDP is described in “User Datagram Protocol,” RFC 768, IETF, Aug. 28, 1980, available at https://tools.ietf.org/html/rfc768, the entire contents of which are incorporated herein by reference. 
     ICMP is a control protocol, unlike TCP, TLS, or UDP, which are transport protocols. An ICMP packet does not carry application data, but instead is used for diagnostic, control, or error messages. Like UDP, ICMP is a connectionless protocol in that client device  100  does not verify that service instance  104  is capable of receiving data prior to transmitting an ICMP message. To establish session  40  according to ICMP, client device  100  transmits a first packet to service instance  104 . Session  40  may be considered “established” according to ICMP upon receipt by client device  100  of any packet from service instance  104 , which implies that service instance  104  successfully received the first packet from client device  100 , responded, and client device  100  was able to receive the response from service instance  104 . Additional example information regarding ICMP is described in “INTERNET CONTROL MESSAGE PROTOCOL,” RFC 792, IETF, September 1981, available at https://tools.ietf.org/html/rfc792, the entire contents of which are incorporated herein by reference. 
     In the example of  FIG.  1   , when router  110 A receives a packet for the forward packet flow originating from client device  100  and destined for server  103 , router  110 A determines whether the packet belongs to a new session (e.g., is the “first” packet or “lead” packet of session  40 ). In some examples, router  110 A determines whether a source address, source port, destination address, destination port, and protocol of the first packet matches an entry in a session table. 
     If no such entry exists, router  110 A determines that the packet belongs to a new session and creates an entry in the session table. Furthermore, if the packet belongs to a new session, router  110 A may generate a session identifier for session  40 . The session identifier may comprise, e.g., a source address and source port of client device  100 , a destination address and destination port of server  103 , and a protocol used by the first packet. Router  110 A may use the session identifier to identify subsequent packets as belonging to the same session. 
     In some examples, routers  110  perform stateful routing for session  40 . This means that routers  110  forward each packet of the forward packet flow of session  40  sequentially and along the same forward network path. As described herein, the “same” forward path means the same routers  110  that form a segment or at least a portion between a device originating the packet and a device to which the packet is destined (and not necessarily the entire network path between the device originating the packet and the device to which the packet is destined). Further, routers  110  forward each packet of the return flow of session  40  sequentially and along the same return network path. The forward network path for the forward packet flow of session  40  and the return network path of the return flow of session  40  may be the same path, or different paths. By ensuring that each packet of a flow is forwarded sequentially and along the same path, routers  110  maintain the state of the entire flow at each router  110 , thereby enabling the use of stateful packet services, such as Deep Packet Inspection (DPI). 
     In the example of  FIG.  1   , a stateful routing session may be established from ingress router  110 A through intermediate routers  110 C- 110 H to egress router  110 I. In this example, router  110 A determines that the first packet is an unmodified packet and the first packet of new session  40 . Router  110 A modifies the first packet to include metadata specifying the session identifier (e.g., the original source address, source port, destination address, and destination port). Router  110 A replaces the header of the modified first packet to specify a source address that is an address of router  110 A, a source port that is a port via which router  110 A forwards the modified first packet toward server  103 , a destination address that is an address of the next hop to which router  110 A forwards the first packet (e.g., an address of router  110 D), and a destination port that is a port of the next hop to which router  110 A forwards the first packet (e.g., a port of router  110 D). 
     Router  110 A may further identify a network service associated with session  40 . For example, router  110 A may compare one or more of a source address, source port, destination address, or destination port for the session to a table of service address and port information to identify a service associated with the session. Examples of network services include Hypertext Transfer Protocol (HTTP), a firewall service, a proxy service, packet monitoring or metrics services, etc. For example, router  110 A may determine that the forward packet flow of session  40  specifies a destination address and destination port assigned to service instance  104  of server  103 , which is an instance of a particular network service. Router  110 A may thereafter store an association between session  40  with the identified network service. As another example, if the source port and/or destination port for session  40  is 80, router  110 A may determine that session  40  is associated with an HTTP service. In other examples, router  110 A may determine that one or more of a source address, source port, destination address, or destination port for session  40  belong to a block of address or ports indicative that a particular service is associated with session  40 . 
     In some examples, router  110 A uses the determined network service for session  40  to select a forward path for forwarding the first packet and each subsequent packet of the forward packet flow of session  40  toward server  103 . In this fashion, router  110 A may perform service-specific path selection to select a network path that best suits the requirements of the service. In contrast to a network topology that uses an SDN controller to perform path selection, each router  110  performs path selection. Further, the use of session-based routing enables each router  110  to make routing decisions at the service- or application-level, in contrast to conventional routers that are only able to make routing decisions at the flow level. 
     Router  110 A forwards the modified first packet to router  110 D. Additionally, router  110 A stores the session identifier for session  40  such that, upon receiving subsequent packets for session  40 , router  110 A may identify the subsequent packets as belonging to the same session  40  and forward the subsequent packets along the same path as the first packet. 
     Intermediate router  110 D receives the modified first packet and determines whether the modified first packet includes metadata specifying the session identifier. In response to determining that the modified first packet includes metadata specifying the session identifier, intermediate router  110 D determines that router  110 D is not an ingress device such that router  110 D does not attach metadata specifying the session identifier. 
     As described above with respect to router  110 A, router  110 D determines whether the packet belongs to a new session (e.g., is the “first” packet or “lead” packet of the session) by determining whether a source address, source port, destination address, destination port, and protocol of the first packet matches an entry in a session table. If no such entry exists, router  110 D determines that the packet belongs to a new session and creates an entry in the session table. Furthermore, if the packet belongs to a new session, router  110 D generates a session identifier for the session. The session identifier used by router  110 D to identify the session for the first packet may be different from the session identifier used by router  110 A to identify the same session for the first packet, because each router  110 A,  110 D uses the header source address, source port, destination address, and destination port of the first packet to generate the session identifier, and this header information may be modified by each preceding router  110  as each router  110  forwards the first packet along the forward path. Furthermore, each router  110  may store this header information to identify a previous router  110  (or “waypoint”) and a next router  110  (or “waypoint”) such that each router  110  may reconstruct the same forward path and reverse path for each subsequent packet of the session. 
     Router  110 D replaces the header of the modified first packet to specify a source address that is an address of router  110 D, a source port that is a port via which router  110 D forwards the modified first packet toward server  103 , a destination address that is an address of the next hop to which router  110 D forwards the first packet (e.g., an address of router  110 E for session  40  along the first path), and a destination port that is a port of the next hop to which router  110 D forwards the first packet (e.g., a port of router  110 E). Router  110 D forwards the modified first packet to router  110 D. Additionally, router  110 D stores the session identifier for the session such that, upon receiving subsequent packets for the session, router  110 D may identify subsequent packets as belonging to the same session and forward the subsequent packets along the same path as the first packet. 
     Subsequent intermediate routers  110 E- 110 H process the modified first packet in a similar fashion as routers  110 A and  110 D such that routers  110  forward the subsequent packets of the session along the same path as the first packet. Further, each router  110  stores a session identifier for the session, which may include an identification of the previous router  110  along the network path. Thus, each router  110  may use the session identifier to forward packets of the reverse packet flow for the session along the same network path back to client device  100 . 
     A router  110  that may forward packets for a forward packet flow of the session to a destination for the packet flow is an egress, or “terminus” router. In the foregoing example, router  110 I is a terminus router because router  110 I may forward packets to CE device  102 B for forwarding to server  103 . Router  110 I receives the modified first packet that comprises the metadata specifying the session identifier (e.g., the original source address, source port, destination address, and destination port). Router  110 I identifies the modified first packet as destined for a service terminating at router  110 I by determining that the destination source address and destination source port specified in the metadata of the modified lead packet corresponds to a destination reachable by router  110 I (e.g., server  103  via CE device  102 B). Router  110 I recovers the original first packet by removing the metadata from the modified first packet and using the metadata to modify the header of the first packet to specify the original source address, source port, destination address, and destination port. Router  110 I forwards the recovered first packet to CE device  102 B for forwarding to server  103 . The use of session-based routing may therefore form a series of waypoints (e.g., routers  110 ) interconnected by path “segments” (e.g., end-to-end route vectors between each waypoint). 
     Additional information with respect to session-based routing and SVR is described in U.S. Pat. No. 9,729,439, entitled “COMPUTER NETWORK PACKET FLOW CONTROLLER,” and issued on Aug. 8, 2017; U.S. Pat. No. 9,729,682, entitled “NETWORK DEVICE AND METHOD FOR PROCESSING A SESSION USING A PACKET SIGNATURE,” and issued on Aug. 8, 2017; U.S. Pat. No. 9,762,485, entitled “NETWORK PACKET FLOW CONTROLLER WITH EXTENDED SESSION MANAGEMENT,” and issued on Sep. 12, 2017; U.S. Pat. No. 9,871,748, entitled “ROUTER WITH OPTIMIZED STATISTICAL FUNCTIONALITY,” and issued on Jan. 16, 2018; U.S. Pat. No. 9,985,883, entitled “NAME-BASED ROUTING SYSTEM AND METHOD,” and issued on May 29, 2018; U.S. Pat. No. 10,200,264, entitled “LINK STATUS MONITORING BASED ON PACKET LOSS DETECTION,” and issued on Feb. 5, 2019; U.S. Pat. No. 10,277,506, entitled “STATEFUL LOAD BALANCING IN A STATELESS NETWORK,” and issued on Apr. 30, 2019; U.S. Pat. No. 10,432,522, entitled “NETWORK PACKET FLOW CONTROLLER WITH EXTENDED SESSION MANAGEMENT,” and issued on Oct. 1, 2019; and U.S. Patent Application Publication No. 2020/0403890, entitled “IN-LINE PERFORMANCE MONITORING,” published on Dec. 24, 2020, the entire content of each of which is incorporated herein by reference in its entirety. 
     Exchanging Service and Topology State Information 
     In some examples, to implement session-based routing, each router  110  maintains a local repository of service and topology state information for each other router  110 . The service and topology state information includes services reachable from each router  110 , as well as a network topology from each router for reaching these services. Each router  110  may transmit changes in the services reachable from the router  110  and/or changes in the network topology for reaching the services from the router to a central repository, e.g., a server. Further, each router  110  may receive service and topology state information for each other router  110  in system  2  from the central repository. 
     In the foregoing example, router  110 A receives a packet, determines session  40  for the forward packet flow comprising the packet, determines a service associated with session  40 , and selects a network path for forwarding the packet. Router  110 A may use its local copy of the service and topology state information for each router  110  to select the network path for forwarding the packet. For example, router  110 A may use the identified service associated with the packet and a network topology for reaching the identified service to select a network path that comports with an SLA requirement or other session performance requirements for the service. Router  110 A may then forward the packet and subsequent packets for the forward packet flow of session  40  along the selected path. In this fashion, router  110 A may perform service-specific path selection in that router  110  may use criteria specific to the service associated with the packet to select a network path that best suits the requirements of the service. 
     In some examples, interfaces of routers  110  may be assigned to one or more “neighborhoods.” A “neighborhood” is defined as a label applied to an interface of a router  110 . The routers  110  within the same neighborhood are capable of forming a peering relationship with one another. For example, each router  110  having an interface to which a neighborhood label is applied is reachable over a Layer-3 network to each other router  110  having an interface to which the same neighborhood label is applied. In some examples, one or more neighborhoods may be aggregated into a “district.” A district is a logical grouping of one or more neighborhoods. Typically, an Autonomous System (AS) (also referred to herein as an “Authority”) may be divided into one or more districts, each district including one or more neighborhoods. 
     In some examples, each router  110  maintains a local repository of service and topology state information only for those other routers  110  within the same neighborhood. In some examples, each router  110  maintains a local repository of service and topology state information only for those other routers  110  within the same district of neighborhoods. As an example, each service provider network  150  may be considered to be a different “district,” wherein each subdomain within each service provider network  150  may be considered to be a neighborhood within that district. In this example, each router  110 A and  110 B within service provider network  150 A may maintain service and topology state information only for one another, and not for routers  110 C- 110 I. Similarly, each router  110 D and  110 C within service provider network  150 B may maintain service and topology state information only for one another, and not for routers  110 A- 110 B or  110 E- 110 I. In other examples, an administrator may assign one or more service provider networks  150  into one or more districts, one or more neighborhoods, or a combination of districts and neighborhoods as suits the needs of network system  2 . 
     Additional information with respect to the exchange of service and topology state information is described in U.S. Patent Application Publication No. 2020/0366590, entitled “CENTRAL AUTHORITY FOR SERVICE AND TOPOLOGY EXCHANGE,” published on Nov. 19, 2020; U.S. Patent Application Publication No. 2020/0366599, entitled “SOURCE-BASED ROUTING,” published on Nov. 19, 2020; U.S. Patent Application Publication No. 2020/0366598, entitled “SERVICE AND TOPOLOGY EXCHANGE PROTOCOL,” published on Nov. 19, 2020; U.S. Patent Application Publication No. 2020/0366589, entitled “ROUTING USING SEGMENT-BASED METRICS,” published on Nov. 19, 2020; and U.S. patent application Ser. No. 16/050,722, entitled “NETWORK NEIGHBORHOODS FOR ESTABLISHING COMMUNICATION RELATIONSHIPS BETWEEN COMMUNICATION INTERFACES IN AN ADMINISTRATIVE DOMAIN,” filed on Jul. 31, 2018, the entire content of each of which is incorporated herein by reference in its entirety. 
     Session Monitoring Using Metrics of Session Establishment. 
     In accordance with the techniques of the disclosure, one or more of routers  110  monitor session  40  along the first path between client device  100  and service instance  104  using one or more metrics of the establishment of session  40 . The first path comprises, e.g., router  110 A,  110 D, and  110 E- 110 I. Client device  100  may attempt to establish session  40  with service instance  104  to access a network service instantiated by service instance  104 . In this example, session  40  comprises a forward flow originating from client device  100  and destined for service instance  104  and a reverse flow originating from service instance  104  and destined for client device  100 . Further, routers  110  transport session  40  via a first path traversing routers  110 A,  110 D, and  110 E- 110 I. After session  40  is established, routers  110  may forward traffic along the forward path and the reverse path between client device  100  and service instance  104 . To establish session  40 , routers  110  may use communication session protocol, such as TCP, TLS, UDP, or ICMP. 
     In some examples, router  110 A is configured to perform session-based routing for session  40  between client device  100  and service instance  104 . For example, router  110 A modifies a first packet of at least one of a forward packet flow and a reverse packet flow of session  40  to include a header comprising a source address of router  110 A and a destination address of router  110 D along the first path and a portion of metadata specifying a session identifier for session  40 , as described above. For session  40 , router  110 D modifies the first packet to include a header comprising a source address of router  110 D and a destination address of router  110 E along the first path and a portion of metadata specifying a session identifier for session  40 , and so on. 
     In some examples, session  40  may fail to establish, session  40  may originally be established but cease to be established, or session  40  may underperform according to session performance requirements (e.g., SLA requirements). This may occur even where router  110 A is unable to identify a problem with its peer network devices (e.g., links  16 A,  16 B, and interfaces of CE device  102 A and router  110 D and routers  110  are properly functioning). 
     As an illustration where session  40  is a TLS session, client device  100  may attempt to establish TLS session  40  with service instance  104 . Service instance  104  may successfully complete the key exchange phase and the server parameters phase of the TLS handshake, but fail to complete the authentication phase of the TLS handshake due to instability of link  16 D between routers  110 D and  110 E. Thus, session  40  between client device  100  and service instance  104  fails to establish, even though router  110 A is not able to identify a problem at the link, network, or transport levels (e.g., OSI reference model Layers 2, 3, or 4) with its peer network devices (e.g., links  16 A,  16 B, and interfaces of CE device  102 A and router  110 D and routers  110  are properly functioning). Typically, a router may be unable to detect problems at the session level (e.g., OSI reference model Layer 5), and therefore may be unable to reroute network traffic at the session level where the links and interfaces to a next hop is properly operating. Furthermore, rerouting traffic at Layers 2, 3, or 4, e.g., by terminating path  16 B to router  110 D, may disrupt other sessions that share path  16 B (or a same interface of router  110 A) with session  40  but remain operable. 
     In accordance with the techniques of the disclosure, router  110 A generates one or more metrics of session establishment of session  40 . Router  110 A obtains session establishment metrics and uses such metrics to determine whether session  40  does not meet session performance requirements. Furthermore, router  110 A may use the session metrics and session performance requirements to determine whether to switch the network traffic for session  40  between client device  100  and service instance  104  from a first path to a second path so as to ensure compliance with the session performance requirements without disrupting other, operable sessions that share the same interface or path as underperforming session  40 . 
     For example, router  110 A obtains session establishment metrics for session  40  between client device  100  and service instance  104 . The session establishment metrics describe data related to the successful or unsuccessful establishment of session  40 . The metrics may describe, e.g., data related to the successful or unsuccessful establishment of session  40 . For example, the session establishment metrics may include a time elapsed to establish session  40 , a number of times session  40  successfully establishes, a number of times session  40  fails to establish due to timeout, a number of times session  40  fails to establish due to an unreachable destination, a number of times session  40  closes prior to TCP session establishment, or a number of times session  40  closes prior to TLS session establishment, etc. In some examples, the session establishment metrics comprise metrics over a sliding window of time, the length of the sliding window configurable by an administrator. For example, router  110 A may monitor a state of session  40  to determine whether a TCP or TLS session handshake completes, or whether a first return packet for a return flow is sent for a UDP or ICMP session. Router  110 I may derive the metrics of session establishment by monitoring the performance and/or state of session  40  prior to, during, or after establishment, as described in more detail below. In some examples, router  110 A obtains session establishment metrics for multiple sessions between client device  100  and service instance  104 . Additional description with regards to monitoring the state of session  40  is provided with respect to  FIG.  2   . 
     In some examples, router  110 A may receive session performance requirements for session  40 . The session performance requirements may be, in some examples, one or more SLA requirements for session  40 . In some examples, the one or more session performance requirements specify one or more of: a maximum time permitted to establish the session; a minimum number of times that the session is required to successfully establish for a predetermined number of attempts to establish the session, a maximum number of times the session may fail to establish due to timeout over a predetermined time; a maximum number of times the session may fail to establish due an unreachable destination over a predetermined time; a maximum number of times the session may close prior to TCP session establishment over a predetermined time; or a maximum number of times the session may close prior to TLS session establishment over a predetermined time, etc. 
     Router  110 A compares the session establishment metrics of session  40  to the session performance requirements for session  40 . In response to determining that the metrics do not satisfy the session performance requirements for session  40 , router  110 A selects a second path comprising routers  110 A,  110 C, and  110 E- 110 I for forwarding the network traffic for session  40  between the client device and the network service instance (depicted in  FIG.  1    as session  40 ′). In some examples where session  40  successfully establishes but does not comply with SLA requirements, router  110 A may continue to use the first path to forward network traffic for session  40  between client device  100  and network service instance  104  prior to transferring session  40  to the second path as session  40 ′. After switching to use of the second path, router  110 A forward network traffic for session  40 ′ between client device  100  and network service instance  104 B. 
     In some examples, router  110 A is configured to perform session-based routing for session  40 ′ between client device  100  and service instance  104 . For example, router  110 A modifies a second packet of at least one of the forward packet flow and the reverse packet flow of session  40 ′ to include a header comprising a source address of router  110 A and a destination address of router  110 D along the second path and a portion of metadata specifying the session identifier for session  40 ′, as described above. For session  40 ′, router  110 C modifies the second packet to include a header comprising a source address of router  110 C and a destination address of router  110 E along the second path and a portion of metadata specifying a session identifier for session  40 ′, and so on. 
     As depicted in the example of  FIG.  1   , a single service instance  104  is hosted by server  103 . In other examples not depicted in  FIG.  1   , a plurality of servers  103  each may host multiple service instances of the same or different service types. In some examples, at least one of a forward path, a reverse path, or an interface of a router  110  associated with the first path traversed by session  40  is different from at least one of a forward path, a reverse path, or an interface of a router  110  associated with the second path traversed by session  40 ′. 
     In the example of  FIG.  1   , ingress router  110 A generates session establishment metrics and performs traffic engineering based on such session establishment metrics as described above. However, in other examples, other routers, such as intermediate routers  110 D- 110 H or egress router  110 I may additionally or alternatively generate session establishment metrics and perform traffic engineering and path selection based on session establishment metrics in accordance with the techniques of the disclosure. 
     In some examples, router  110 A removes the first path which transports network traffic for session  40  from inclusion in a session load balancer that load balances customer traffic associated with the network service to different paths. For example, the session load balancer may include a plurality of paths between ingress network device  110 A and egress network device  110 I. Upon receiving a request from a client to provide the client with access to a network service instantiated by service instance  104 , the session load balancer selects an available path through service provider network(s)  150  with which to connect client device  100  to service instance  104 . By removing the first path from inclusion in the session load balancer, router  110 A may avoid assigning client device  100  to path that does not satisfy SLA requirements for session  40 . In some examples, router  110 A may use session establishment metrics to select one or more sessions, detect blackholing of traffic, determine that a session does not satisfy SLA requirements, or to load balance customer traffic associated with a network service across different sessions. 
     The techniques of the disclosure may enable router  110 A to monitor the state of session  40  and generate metrics related to establishment of session  40 . Router  110 A may use such metrics to perform path selection and routing at the session level (e.g., OSI reference model Layer 5), as opposed to other routers which may be only able to perform path selection and routing at the link, network, or transport levels (e.g., OSI reference model Layers 2, 3, or 4). Accordingly, router  110 A may provide more efficient and granular routing of customer traffic within network system  2 . 
     Additionally, router  110 A may use metrics of session establishment to determine whether session  40  satisfies SLA requirements, and in response, select a different path or interface for transporting network traffic associated with session  40  (e.g., session  40 ′), so as to ensure compliance with the SLA. Router  110 A may therefore detect networking problems at the session level, (e.g., OSI reference model Layer 5), even where router  110 A is unable to detect a problem with an interface or path at the link, network, or transport levels (e.g., OSI reference model Layers 2, 3, or 4), and perform actions to ensure compliance with session-level SLA requirements. 
       FIG.  2    is a block diagram illustrating example router  110  in accordance with the techniques of the disclosure. In general, router  110  may be an example of one of routers  110  of  FIG.  1   . In this example, router  110  includes interface cards  226 A- 226 N (“IFCs  226 ”) that receive packets via incoming links  228 A- 228 N (“incoming links  228 ”) and send packets via outbound links  230 A- 230 N (“outbound links  230 ”). IFCs  226  are typically coupled to links  228 ,  230  via a number of interface ports. Router  110  also includes a control unit  202  that determines routes of received packets and forwards the packets accordingly via IFCs  226 . 
     Control unit  202  may comprise routing engine  204  and packet forwarding engine  222 . Routing engine  204  operates as the control plane for router  110  and includes an operating system that provides a multi-tasking operating environment for execution of a number of concurrent processes. Routing engine  204  communicates with other routers, e.g., such as routers  110  of  FIG.  1   , to establish and maintain a computer network, such as computer network system  2  of  FIG.  1   , for transporting network traffic between one or more customer devices. Routing protocol daemon (RPD)  208  of routing engine  204  executes software instructions to implement one or more control plane networking protocols  212 . For example, protocols  212  may include one or more routing protocols, such as Border Gateway Protocol (BGP)  220 , for exchanging routing information with other routing devices and for updating routing information base (RIB)  206 , Multiprotocol Label Switching (MPLS) protocol  214 , and Internet Group Management Protocol (IGMP)  221 . Protocols  212  may further include one or more communication protocols, such as TCP, UDP, TLS, or ICMP. 
     RIB  206  may describe a topology of the computer network in which router  110  resides, and may also include routes through the shared trees in the computer network. RIB  206  describes various routes within the computer network, and the appropriate next hops for each route, i.e., the neighboring routing devices along each of the routes. Routing engine  204  analyzes information stored in RIB  206  and generates forwarding information for forwarding engine  222 , stored in Forwarding information base (FIB)  224 . FIB  224  may associate, for example, network destinations with specific next hops and corresponding IFCs  226  and physical output ports for output links  230 . FIB  224  may be a radix tree programmed into dedicated forwarding chips, a series of tables, a complex database, a link list, a radix tree, a database, a flat file, or various other data structures. 
     FIB  224  may also include lookup structures. Lookup structures may, given a key, such as an address, provide one or more values. In some examples, the one or more values may be one or more next hops. A next hop may be implemented as microcode, which when executed, performs one or more operations. One or more next hops may be “chained,” such that a set of chained next hops perform a set of operations for respective different next hops when executed. Examples of such operations may include applying one or more services to a packet, dropping a packet, and/or forwarding a packet using an interface and/or interface identified by the one or more next hops. 
     Session table  235  stores information for identifying sessions. For example, services table  232  comprises one or more entries that specify a session identifier. In some examples, the session identifier comprises one or more of a source address, source port, destination address, destination port, or protocol associated with a forward flow and/or a reverse flow of the session. As described above, when routing engine  204  receives a packet for a forward packet flow originating from client device  100  and destined for server  103  of  FIG.  1   , routing engine  204  determines whether the packet belongs to a new session (e.g., is the “first” packet or “lead” packet of session  40 ). To determine whether the packet belongs to a new session, routing engine  204  determines whether session table  235  includes an entry corresponding to a source address, source port, destination address, destination port, and protocol of the first packet. If an entry exists, then the session is not a new session. If no entry exists, then the session is new and routing engine  204  generates a session identifier for the session and stores the session identifier in session table  235 . Routing engine  204  may thereafter use the session identifier stored in session table  235  for the session to identify subsequent packets as belonging to the same session. 
     Services table  232  stores information that routing engine  204  may use to identify a service associated with a session. For example, services table  232  comprises one or more entries that specify a service identifier and one or more of a source address, source port, destination address, destination port, or protocol associated the service. In some examples, routing engine  204  may query services table  232  with one or more of a source address, source port, destination address, destination port, or protocol of a session for a received packet to determine a service associated with a session. For example, routing engine  204  may determine a service identifier based on a correspondence of a source address, source port, destination address, destination port, or protocol in services table  232  to a source address, source port, destination address, destination port, or protocol specified by a session identifier. Routing engine  204  retrieves, based on the service associated with the packet, one or more service policies  234  corresponding to the identified service. The service policies may include, e.g., a path failover policy, a Dynamic Host Configuration Protocol (DHCP) marking policy, a traffic engineering policy, a priority for network traffic associated with the session, etc. Routing engine  204  applies, to the packet, the one or more service policies  234  that correspond to the service associated with the packet. 
     In accordance with the techniques of the disclosure, routing engine  204  generates metrics  236  for the establishment of sessions between client device  100  of  FIG.  1    and one or more service instances  104  of servers  103  of  FIG.  1   . Routing engine  204  may use metrics  236  for session establishment to select one or more sessions, detect blackholing of traffic, determine that a session does not satisfy SLA requirements, to load balance customer traffic associated with the network service across different paths, or to perform path selection, etc. 
     For example, routing engine  204  receives session performance requirements  238  for session  40  of  FIG.  1    between client device  100  and network service instance  104 . In some examples, session performance requirements  238  may include one or more SLA requirements for session  40 . In some examples, routing engine  204  receives session performance requirements  238  from an administrator or orchestration device, such as a Software-Defined Networking (SDN) controller. 
     In some examples, the one or more session performance requirements specify one or more of: a maximum time permitted to establish the session; a minimum number of times that the session is required to successfully establish for a predetermined number of attempts to establish the session, a maximum number of times the session may fail to establish due to timeout over a predetermined time; a maximum number of times the session may fail to establish due an unreachable destination over a predetermined time; a maximum number of times the session may close prior to TCP session establishment over a predetermined time; or a maximum number of times the session may close prior to TLS session establishment over a predetermined time, etc. 
     Routing engine  204  forwards, via IFC  226 A, network traffic associated with session  40  between client device  100  and network service instance  104  along a first path. Examples of sessions include a TCP session, a TLS session, a UDP session, an ICMP session, etc. Routing engine  204  obtains metrics  236  of the establishment of session  40 . In some examples, session state monitor  242  of routing engine  204  monitors a state of session  40  to determine whether session  40  successfully establishes. For example, session state monitor  242  may monitor a state of session  40  to determine whether a TCP or TLS session handshake completes, or whether a first return packet for a return flow is sent for a UDP or ICMP session. In some examples, routing engine  204  may derive the metrics of session establishment by monitoring, via session state monitor  242 , the performance and/or state of session  40  prior to, during, or after establishment. 
     The metrics may describe, e.g., data related to the successful or unsuccessful establishment of session  40 , and/or the performance of the session (e.g., latency, jitter, packet loss, etc.). For example, the session establishment metrics may include a time elapsed to establish session  40 , a number of times session  40  successfully establishes, a number of times session  40  fails to establish due to timeout, a number of times session  40  fails to establish due to an unreachable destination, a number of times session  40  closes prior to TCP session establishment, or a number of times session  40  closes prior to TLS session establishment, etc. In some examples, the session establishment metrics comprise metrics over a sliding window of time, the length of the sliding window configurable by an administrator. 
     A key indicator of service instance performance is a time required to establish a TCP session between, e.g., client device  100  and server  103  hosting service instance  104 . This session establishment metric is effectively a time required for client device  100  or service instance  104  to receive a first data packet after the session is established. This metric may provide more useful information for routing decisions than a packet transmission rate because the time required to establish the TCP session is both directional and end-to-end. Importantly, routing engine  204  may use this information as a measure of SLA compliance to influence path selection by routing engine  204 . 
     Routing engine  204  creates and gathers session establishment metrics on a per service, per interface, per destination, and/or per traffic-class basis. This level of granularity provides more accurate information on how network treatment and performance by routing engine  204  impacts application behavior. In some examples, routing engine  204  collects session establishment metrics in protocol based buckets, such as TCP, UDP, ICMP, and TLS. Each protocol has its own determination of what qualifications need to be met for a session to become established, as described above. In turn, routing engine  204  applies protocol- and/or application-specific handling of each of these types of sessions which are defined by what is considered established. 
     In accordance with the techniques of the disclosure, session state monitor  242  of routing engine  204  monitors a state of each session according to the protocol of the session. For example, session state monitor  242  is capable of determining a state of each session according to a state machine for the relevant protocol to determine whether or not the session has established. Routing engine  204  generates the session establish metrics based on various data related to the establishment of the session (or failure to establish the session). 
     For example, as described above, to establish a TCP session such that data may be exchanged according to TCP, client device  100  and service instance  104 , for example, perform a three-way TCP handshake. Client device  100  sends a first packet (transported by router  110 ) comprising a “SYN” flag to service instance  104 . Service instance  104  acknowledges receipt of the first packet by responding to client device  100  with a second packet comprising a “SYN-ACK” flag (transported by router  110 ). Client device  100  acknowledges receipt of the second packet by responding to service instance  104  with a third packet comprising an “ACK” flag. After sending the third packet, the TCP session is established such that client device  100  and service instance  104  may exchange data with one another via the TCP session. In further accordance with TCP, in response to each packet sent from client device  100  to service instance  104 , service instance  104  responds with an acknowledgement packet (and vice versa). Session state monitor  242  monitors the state of the TCP handshake performed by client device  100  and service instance  104  to monitor the progress of the TCP handshake. Session state monitor  242  determines that the TCP session is established when session state monitor  242  detects an acknowledgement of a first packet that contains a data payload from, e.g., one of client device  100  and service instance  104 , after session state monitor  242  determines that client device  100  and service instance  104  have completed the TCP handshake for the session. The time required to detect the acknowledgement of the first packet that contains the data payload after client device  100  and service instance  104  have completed the TCP handshake for the session is referred to herein as a “time to first data packet” for the TCP session. 
     In some examples, session state monitor  242  models a state machine of the TCP protocol to monitor the progression of establishment of the TCP session. In some examples, session state monitor  242  determines one or more of a time to first data packet for the TCP session, a minimum time to reach the established state for the TCP session, a maximum time to reach the established state for the TCP session, a mean time to reach the established state for the TCP session, a count of how many TCP sessions reach the established state, a count of how many TCP sessions fail to establish due to time out, a count of how many TCP sessions fail to establish due to destination unreachable, or a count of how many TCP sessions close prior to establishment. 
     As another example, to establish a TLS session such that data may be exchanged according to TLS, client device  100  and service instance  104  perform a three-way TLS handshake comprising the key exchange phase, the server parameters phase, and the authentication phase. Session state monitor  242  monitors the state of the TLS handshake performed by client device  100  and service instance  104  to monitor the progress of the TLS handshake. Session state monitor  242  determines that the TLS session is established when session state monitor  242  detects an acknowledgement of a first packet that contains a data payload from, e.g., one of client device  100  and service instance  104 , after session state monitor  242  determines that client device  100  and service instance  104  have completed the TLS handshake for the session (e.g., a “time to first data packet”). The time required to detect the acknowledgement of the first packet that contains the data payload after client device  100  and service instance  104  have completed the TLS handshake for the session is referred to herein as a “time to first data packet” for the TLS session. 
     In some examples, session state monitor  242  models a state machine of the TLS protocol to monitor the progression of establishment of the TLS session. In some examples, session state monitor  242  determines one or more of a time to first data packet for the TLS session, a minimum time to reach the established state for the TLS session, a maximum time to reach the established state for the TLS session, a mean time to reach the established state for the TLS session, a count of how many TLS sessions reach the established state, a count of how many TLS sessions fail to establish due to time out, a count of how many TLS sessions fail to establish due to destination unreachable, or a count of how many TLS sessions close prior to establishment. 
     As another example, for a UDP session between client device  100  and service instance  104 , session state monitor  242  identifies a first UDP packet for the session originating from client device  100  and destined for service instance  104 . Session state monitor  242  may consider the UDP session to be established in response to detecting a packet for the session sent along a reverse path (e.g., originating from service instance  104  and destined for client device  100 ). The presence of traffic along the reverse path implies that service instance  104  successfully received the first UDP packet from client device  100  and responded. 
     In some examples, session state monitor  242  models a state machine of the UDP protocol to monitor the progression of establishment of the UDP session. In some examples, session state monitor  242  determines one or more of a time to first data packet for the UDP session, a minimum time to reach the established state for the UDP session, a maximum time to reach the established state for the UDP session, a mean time to reach the established state for the UDP session, a count of how many UDP sessions reach the established state, a count of how many UDP sessions fail to establish due to time out, or a count of how many UDP sessions fail to establish due to destination unreachable. 
     As another example, for an ICMP session between client device  100  and service instance  104 , session state monitor  242  identifies a first ICMP packet for the session originating from client device  100  and destined for service instance  104 . Session state monitor  242  may consider the ICMP session to be established in response to detecting a packet for the session sent along a reverse path (e.g., originating from service instance  104  and destined for client device  100 ). The presence of traffic along the reverse path implies that service instance  104  successfully received the first ICMP packet from client device  100  and responded. 
     In some examples, session state monitor  242  models a state machine of the ICMP protocol to monitor the progression of establishment of the ICMP session. In some examples, session state monitor  242  determines one or more of a time to first data packet for the ICMP session, a minimum time to reach the established state for the ICMP session, a maximum time to reach the established state for the ICMP session, a mean time to reach the established state for the ICMP session, a count of how many ICMP sessions reach the established state, a count of how many ICMP sessions fail to establish due to time out, or a count of how many ICMP sessions fail to establish due to destination unreachable. 
     In some examples, the session establishment metrics generated by routing engine  204  include a time to a first data packet for a session. For example, for a TCP session, this metric specifies a time required for client device  100  or service instance  104  to receive an acknowledgement of a first data packet after a TCP handshake is completed. As another example, for a TLS session, this metric specifies a time required for client device  100  or service instance  104  to receive an acknowledgement of a first data packet after a TLS handshake is completed. For a UDP session, this metric specifies a time required for client device  100  or service instance  104  to receive a first data packet along a return path of the UDP session. For an ICMP session, this metric specifies a time required for client device  100  or service instance  104  to receive a first data packet along a return path of the ICMP session. 
     In some examples, the session establishment metrics generated by routing engine  204  include a time to establish a session. This metric may include a minimum time to establish the session, a maximum time to establish the session, and a mean time to establish the session. The time from session start to when the session reaches an established state is defined per-protocol, as described above. In some examples, for a TLS session, the time to establish a session is calculated from a TCP establishment start time instead of from a session start time. 
     An example of a session establishment metric generated by routing engine  204  and specifying a time to establish a session is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway 
               
               
                 destination-reachability tcp time-to-establishment 
               
               
                 Tue 2020 Mar. 31 20:33:26 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 time-to-establishment 
               
            
           
           
               
               
               
               
               
               
               
            
               
                 Metric 
                 Node 
                 Service 
                 Network-interface 
                 Destination-prefix 
                 Traffic-class 
                 Value 
               
               
                   
               
               
                 max 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                   
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                   
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                   
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                 min 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                   
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                   
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                   
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                   
               
               
                 Completed in 0.02 seconds 
               
            
           
         
       
     
     An example of a session establishment metric generated by routing engine  204  and specifying a maximum time to establish a session is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway 
               
               
                 destination-reachability tcp time-to-establishment max 
               
               
                 Tue 2020 Mar. 31 20:39:12 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 Maximum time to establishment 
               
            
           
           
               
               
               
               
               
               
            
               
                   
                   
                 Network- 
                 Destination- 
                 Traffic- 
                   
               
               
                 Node 
                 Service 
                 interface 
                 prefix 
                 class 
                 Value 
               
               
                   
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                   
               
               
                 Completed in 0.02 seconds 
               
            
           
         
       
     
     An example of a session establishment metric generated by routing engine  204  and specifying a minimum time to establish a session is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway 
               
               
                 destination-reachability tcp time-to-establishment min 
               
               
                 Tue 2020 Mar. 31 20:39:25 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 Minimum time to establishment 
               
            
           
           
               
               
               
               
               
               
            
               
                   
                   
                 Network- 
                 Destination- 
                 Traffic- 
                   
               
               
                 Node 
                 Service 
                 interface 
                 prefix 
                 class 
                 Value 
               
               
                   
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                   
               
               
                 Completed in 0.02 seconds 
               
            
           
         
       
     
     In some examples, the session establishment metrics generated by routing engine  204  include a number of sessions that reach establishment. The number of sessions that reach establishment is a count of how many sessions reach the established state, defined on a per-protocol basis as described above. In some examples, the number of sessions that reach establishment is a number of sessions that reach establishment over a predetermined amount of time. 
     An example of a session establishment metric generated by routing engine  204  and specifying a number of sessions that reach establishment is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway 
               
               
                 destination-reachability tcp established 
               
               
                 Tue 2020 Mar. 31 20:38:29 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 TCP sessions that were successfully established 
               
            
           
           
               
               
               
               
               
               
            
               
                   
                   
                 Network- 
                 Destination- 
                 Traffic- 
                   
               
               
                 Node 
                 Service 
                 interface 
                 prefix 
                 class 
                 Value 
               
               
                   
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                   
               
            
           
         
       
     
     In some examples, the session establishment metrics generated by routing engine  204  include a number of sessions that time out before establishing. The number of sessions that time out before establishing is a count of how many sessions time out without ever reaching establishment, defined on a per-protocol basis as described above. In some examples, the number of sessions that time out before establishing is a number of sessions that time out before establishing over a predetermined amount of time. In some examples, the TLS bucket of this metric is incremented only when the TCP established state has been reached but before the TLS established state has been reached. 
     An example of a session establishment metric generated by routing engine  204  and specifying a number of sessions that time out before establishing is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway 
               
               
                 destination-reachability tcp timeout-before-establishment 
               
               
                 Tue 2020 Mar. 31 20:40:21 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 Timed out TCP sessions before establishment 
               
            
           
           
               
               
               
               
               
               
            
               
                   
                   
                 Network- 
                 Destination- 
                 Traffic- 
                   
               
               
                 Node 
                 Service 
                 interface 
                 prefix 
                 class 
                 Value 
               
               
                   
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                   
               
               
                 Completed in 0.02 seconds 
               
            
           
         
       
     
     In some examples, the session establishment metrics generated by routing engine  204  include a number of sessions that fail to establish due to an unreachable destination. The number of sessions that fail to establish due to an unreachable destination is a count of how many sessions could not complete because the destination was unreachable. In some examples, routing engine  204  determines that the destination is unreachable in response to receiving an ICMP destination message unreachable for the session. In some examples, the number of sessions that time out before establishing is a number of sessions that fail to establish due to an unreachable destination over a predetermined amount of time. 
     In some examples, this metric may not apply across UDP, ICMP, TCP, TLS, and so may specify the specific protocol or application name of the metric. An example of a session establishment metric generated by routing engine  204  and specifying a number of TCP sessions that sessions that fail to establish due to an unreachable destination is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway 
               
               
                 destination-reachability tcp unreachable 
               
               
                 Tue 2020 Mar. 31 20:41:06 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 TCP unreachable 
               
            
           
           
               
               
               
               
               
               
            
               
                   
                   
                 Network- 
                 Destination- 
                 Traffic- 
                   
               
               
                 Node 
                 Service 
                 interface 
                 prefix 
                 class 
                 Value 
               
               
                   
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                   
               
               
                 Completed in 0.02 seconds 
               
            
           
         
       
     
     In some examples, the session establishment metrics generated by routing engine  204  include a number of sessions closed before establishment of a TCP session. This metric may include a number of sessions that are closed by a reset or fin message before the session has finished the TCP handshake and data has been acknowledged. This may occur due to server  103  responding to a SYN from client device  100  with a reset or a proxy message terminating a session that server  103  cannot complete. In some examples, the number of sessions closed before establishment of a TCP session is a number of sessions closed before establishment of a TCP session over a predetermined amount of time. 
     An example of a session establishment metric generated by routing engine  204  and specifying a number of sessions closed before establishment of a TCP session is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway 
               
               
                 destination-reachability tcp close-before-establishment 
               
               
                 Tue 2020 Mar. 31 20:41:56 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 Closed TCP sessions before establishment 
               
            
           
           
               
               
               
               
               
               
            
               
                   
                   
                 Network- 
                 Destination- 
                 Traffic- 
                   
               
               
                 Node 
                 Service 
                 interface 
                 prefix 
                 class 
                 Value 
               
               
                   
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                   
               
               
                 Completed in 0.02 seconds 
               
            
           
         
       
     
     In some examples, the session establishment metrics generated by routing engine  204  include a number of sessions closed before establishment of a TLS session. This metric may include a number of sessions that are closed by a reset or fin message after TCP establishment but before the session has finished the TLS handshake and data has been acknowledged. In some examples, the number of sessions closed before establishment of a TLS session is a number of sessions closed before establishment of a TLS session over a predetermined amount of time. 
     An example of a session establishment metric generated by routing engine  204  and specifying a number of sessions closed before establishment of a TLS session is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway 
               
               
                 destination-reachability tls close-before-establishment 
               
               
                 Tue 2020 Mar. 31 20:42:30 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 Closed TlS sessions before establishment 
               
            
           
           
               
               
               
               
               
               
            
               
                   
                   
                 Network- 
                 Destination- 
                 Traffic- 
                   
               
               
                 Node 
                 Service 
                 interface 
                 prefix 
                 class 
                 Value 
               
               
                   
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 high 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 low 
                 0 
               
               
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 medium 
                 0 
               
               
                   
               
               
                 Completed in 0.02 seconds 
               
            
           
         
       
     
     In some examples, to begin collection of service establishment metrics as described above, an administrator configures routing engine  204  with a service route configured to enable reachability detection. An example of such a service route that enables reachability detection is set forth below: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 service-route 
               
            
           
           
               
               
               
            
               
                   
                 name 
                 service-agent1 
               
               
                   
                 nat-target 
                 1.2.3.4 
               
               
                   
                 service-name 
                 web 
               
               
                   
                 service-route-policy 
                 sap1 
               
               
                   
                 reachability-detection 
                 true 
               
               
                   
                 enabled 
               
            
           
           
               
            
               
                 next-hop 
               
            
           
           
               
               
               
            
               
                   
                 node-name 
                 slice1 
               
               
                   
                 interface 
                 intf1 
               
               
                   
                 gateway-ip 
                 1.1.1.2 
               
               
                   
                   
               
            
           
         
       
     
     In some examples, an administrator configures routing engine  204  to filter reachability by destination prefix by traffic class. An example of such a configuration is set forth below: 
     
       
         
           
               
            
               
                   
               
               
                 admin@t116-dut1.t116# show stats highway destination-reachability destination-prefix 
               
               
                 192.168.56.51 traffic-class best-effort 
               
               
                 Tue 2020 Mar. 31 20:44:47 UTC 
               
               
                 Retrieving statistics . . . 
               
               
                 Destination Reachability Statistics 
               
            
           
           
               
               
               
               
               
               
               
            
               
                 Metric 
                 Node 
                 Service 
                 Network-interface 
                 Destination-prefix 
                 Traffic-class 
                 Value 
               
               
                   
               
               
                 icmp established 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 icmp time-to-establishment max 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 icmp time-to-establishment min 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 icmp timeout-before-establishment 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 icmp unreachable 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tcp close-before-establishment 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tcp established 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tcp time-to-establishment max 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tcp time-to-establishment min 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tcp timeout-before-establishment 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tcp unreachable 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tls close-before-establishment 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tls established 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tls time-to-establishment max 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tls time-to-establishment min 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 tls timeout-before-establishment 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 udp established 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 udp time-to-establishment max 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 udp time-to-establishment min 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 udp timeout-before-establishment 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                 udp unreachable 
                 t116-dut1 
                 foo 
                 controlKniIf 
                 192.168.56.51 
                 best-effort 
                 0 
               
               
                   
               
               
                 Completed in 0.03 seconds 
               
            
           
         
       
     
     Routing engine  204  compares metrics  236  for session establishment for session  40  to session performance requirements  238  for session  40 . In response to determining that metrics  236  for session establishment for session  40  do not satisfy session performance requirements  238  for session  40 , routing engine  204  forwards, via IFC  226 B, network traffic associated with session  40  between client device  100  and network service instance  104  along a second path as session  40 ′. In some examples where session  40  successfully establishes but does not comply with session performance requirement  238 , routing engine  204  may continue to use IFC  226 A to forward network traffic between client device  100  and network service instance  104  prior to switching to forwarding network traffic between client device  100  and network service instance  104  via IFC  226 B. 
     In some examples, routing engine  204  may use metrics  236  for session establishment for session  40  to determine whether latency of network traffic associated with session  40  exceeds session performance requirements  238  or whether blackholing of network traffic associated with session  40  is occurring. For example, if routing engine  204  determines that latency of network traffic associated with session  40  is high, routing engine  204  may maintain the use of the first path over which network traffic for session  40  is forwarded even if session  40  exceeds session performance requirements  238 . As another example, if routing engine  204  determines that blackholing of network traffic associated with session  40  is occurring, routing engine  204  may cease forwarding network traffic associated with session  40  over the first path and switch to using the second path to forward the network traffic associated with session  40 ′ between client device  100  and network service instance  104 . 
     In some examples, routing engine  204  may use metrics  236  for session establishment for session  40  to determine whether to include or exclude a path from session load balancer  240 . Session load balancer  240  operates to load balance customer traffic associated with a network service across different paths of a plurality of paths, such as the first path and second path over which network traffic for respective sessions  40  and  40 ′ of  FIG.  1    are forwarded. By performing load balancing, session load balancer  240  may evenly distribute customer traffic of client device  100  across paths and interfaces, thereby reducing the likelihood that a particular session  40  or a particular router  110  may become overutilized, thereby causing network congestion, or underutilized, thereby allowing available network resources to go unused. For example, if routing engine  204  determines that metrics  236  for session establishment for session  40  do not satisfy session performance requirements  238  for session  40 , routing engine  204  may determine that session  40  is overutilized. Routing engine  204  may remove the first path over which network traffic associated with session  40  is forwarded from session load balancer  240  to avoid the first path to forward customer traffic, thereby reducing the likelihood that the customer traffic may not satisfy SLA requirements. 
       FIGS.  3 A and  3 B  are block diagrams illustrating example computer network system  300  that performs path selection based on metrics of session establishment in accordance with the techniques of the disclosure.  FIGS.  3 A and  3 B  are described with respect to  FIGS.  1  and  2    for convenience. For example, system  300  may be an example of system  2  of  FIG.  1   . Routers  110 A,  110 C, and  110 D may be examples of  110 A,  110 C, and  110 D of  FIG.  1    or router  110  of  FIG.  2   . Router  110 A includes IFCs  226 A- 226 C (collectively, “IFCs  226 ”). 
     In the example of  FIGS.  3 A- 3 B , server  103  hosts service instance  104 A, which instantiates a first network service. Server  103  further hosts service instance  104 B, which instantiates a second network service. In some examples, the first network service comprises an HTTP service over a TCP session accessed via port  80  of server  103 . In some examples, the second network service comprises a TLS session accessed via port  443  of server  103 . 
     Router  110 A is connected to server  103  via a first path comprising link  316 B, router  110 D, and link  316 D and a second path comprising link  316 C, router  110 C, and link  316 E. In some examples, the first path comprises a path across a broadband network. In some examples, the second path comprises a path across a mobile network. 
     Session  340 A comprises a first forward packet flow along a first forward path (e.g., the first path comprising link  316 B, router  110 D, and link  316 D) and a first reverse packet flow along a first reverse path (e.g., link  316 D, router  110 D, and link  316 B) between client device  100  and network service instance  104 A hosted by server  103 . Session  340 B comprises a second forward packet flow along the first path (e.g., link  316 A, router  110 A, link  316 B, router  110 D, and link  316 D) and a second reverse packet flow along a reverse of the first path between client device  100  and network service instance  104 B hosted by server  103 . Both session  340 A and session  340 B ingress via IFC  226 A of router  110 A and egress via IFC  226 B of router  110 A. 
     Router  110 A forwards, along the first path comprising link  316 A, router  110 A, link  326 B, router  110 D, and link  316 D, network traffic for session  340 A. In some examples, router  110 A perform session-based routing for session  340 A between client device  100  and network service instance  104 A. For example, router  110 A modifies a first packet of at least one of a forward packet flow and a reverse packet flow of session  340 A to include a header comprising a source address of router  110 A and a destination address of router  110 D along the first path and a portion of metadata specifying a session identifier for session  340 A. 
     In the example of  FIG.  3 A , router  110 A receives one or more session performance requirements for session  340 A. In some examples, the one or more session performance requirements comprise one or more SLA requirements. In some examples, the one or more session performance requirements specify one or more of: a maximum time permitted to establish session  340 A; a minimum number of times that session  340 A is required to successfully establish for a predetermined number of attempts to establish session  340 A, a maximum number of times session  340 A may fail to establish due to timeout over a predetermined time; a maximum number of times session  340 A may fail to establish due an unreachable destination over a predetermined time; a maximum number of times session  340 A may close prior to TCP session establishment over a predetermined time; or a maximum number of times session  340 A may close prior to TLS session establishment over a predetermined time, etc. 
     Router  110 A obtains one or more metrics of session establishment of session  340 A. For example, the metrics of session establishment may include, e.g., a time elapsed to establish session  340 A, a number of times session  340 A successfully establishes, a number of times session  340 A fails to establish due to timeout, a number of times session  340 A fails to establish due to an unreachable destination, a number of times session  340 A closes prior to TCP session establishment, or a number of times session  340 A closes prior to TLS session establishment, etc. Router  110 A may derive the metrics of session establishment by monitoring the performance and/or state of the first session prior to, during, or after establishment. 
     Router  110 A determines that the one or more metrics of session establishment of session  340 A do not satisfy the one or more session performance requirements for session  340 A. For example, router  110 A may determine that a time elapsed to establish session  340 A exceeds a maximum time permitted to establish session  340 A as set by an SLA requirement for session  340 A. As another example, router  110 A may determine that a number of times session  340 A fails to establish due to timeout exceeds a maximum number of times session  340 A is permitted to establish due to timeout over a predetermined time, as set by an SLA requirement for session  340 A. 
     In some examples, in response to determining that the one or more metrics of session establishment of session  340 A do not satisfy the one or more session performance requirements for session  340 A, router  110 A excludes the first path along which network traffic for session  340 A is forwarded from a session load balancer (e.g., session load balancer  240  of  FIG.  2   ). For example, router  110 A removes a route specifying that service instance  104  is reachable via the first path comprising link  316 A, router  110 A, link  316 B, router  110 D, and link  316 D from inclusion in session load balancer  240 . Subsequently, when establishing a session between client device  100  and a service instance  104  of the first network service, session load balancer  240  may exclude the first path from a set of paths with which router  110 A may use to provide client device  100  with access to service instance  104 A of server  103 . 
     As depicted in the example of  FIG.  3 B , in response to determining that the one or more metrics of session establishment of session  340 A do not satisfy the one or more session performance requirements for session  340 A, router  110 A switches from forwarding network traffic associated with session  340 A across the first path (e.g., link  316 A, router  110 A, link  316 B, router  110 D, and link  316 D) to forwarding network traffic associated with session  340 A across a second path (e.g., link  316 A, router  110 A, link  316 C, router  110 C, and link  316 E) (represented as session  340 A′ in  FIG.  3 B ). The network traffic of session  340 A′ ingresses via IFC  226 A of router  110 A, but egresses via IFC  226 C. Router  110 A switches from forwarding network traffic associated with session  340 A along the first path to forwarding network traffic associated with session  340 A′ along the second path between client device  100  and network service instance  104 A. In some examples, router  110 A ceases use of the first path for lack of compliance with the one or more session performance requirements. 
     In some examples, router  110 A perform session-based routing for session  340 A′ between client device  100  and network service instance  104 A. For example, router  110 A modifies a second packet of at least one of a forward packet flow and a reverse packet flow of session  340 A to include a header comprising a source address of router  110 A and a destination address of router  110 C along the second path and a portion of metadata specifying a session identifier for session  340 A. 
     Router  110 A further receives one or more session performance requirements for session  340 B and one or more metrics of session establishment of session  340 B. Router  110 A determines that the one or more metrics of session establishment of session  340 B satisfy the one or more session performance requirements for session  340 B. Therefore, because session  340 B complies with the session performance requirements for session  340 B, when router  110 A switches from using the first path for network traffic of session  340 A to using the second path for network traffic of session  340 A′, router  110 A may avoid interrupting the forwarding of network traffic associated with session  340 B over the first path (e.g., by avoiding disabling IFC  226 B or tearing down link  316 B). 
     Therefore, where session  340 A is underperforming, the techniques of the disclosure may enable router  110 A to switch from the use of the first path over which session  340 A is forwarded to the use of a different path or interface (e.g., link  316 C and/or IFC  226 C), without tearing down path  316 B or deactivating IFC  226 B associated with underperforming session  340 A. Therefore, router  110 A may select a different path for network traffic of underperforming session  340 A without adversely affecting session  340 B, which performs according to SLA requirements but shares link  316 B with underperforming session  340 A and/or uses the same IFC  226 B associated with underperforming session  340 A. Thus, router  110 A may provide more granular and efficient routing of customer traffic as compared to other routers that may be required to tear down a path or deactivate an interface associated with an underperforming session. 
       FIG.  4    is a flowchart illustrating an example operation in accordance with the techniques of the disclosure. Specifically,  FIG.  4    depicts an example for monitoring a session using metrics of session establishment for the session.  FIG.  4    is described with respect to router  110 A of  FIGS.  3 A- 3 B  for convenience. However, the operation depicted in  FIG.  4    may additionally be implemented by routers  110  of system  2  of  FIG.  1    or router  110  of  FIG.  2   . Session  340 A comprises a first forward packet flow along a first forward path and a first reverse packet flow along a first reverse path between client device  100  and network service instance  104  hosted by server  103 . 
     In the example of  FIG.  4   , router  110 A receives one or more session performance requirements for session  340 A between client device  100  and network service instance  104  hosted by server  103  ( 402 ). In some examples, the one or more session performance requirements comprise one or more SLA requirements. In some examples, the one or more session performance requirements specify one or more of: a maximum time permitted to establish session  340 A; a minimum number of times that session  340 A is required to successfully establish for a predetermined number of attempts to establish session  340 A, a maximum number of times session  340 A may fail to establish due to timeout over a predetermined time; a maximum number of times session  340 A may fail to establish due an unreachable destination over a predetermined time; a maximum number of times session  340 A may close prior to TCP session establishment over a predetermined time; or a maximum number of times session  340 A may close prior to TLS session establishment over a predetermined time, etc. 
     Router  110 A forwards, along a first path comprising link  316 A, router  110 A, link  326 B, router  110 D, and link  316 D, network traffic for session  340 A ( 404 ). In some examples, router  110 A perform session-based routing for session  340 A between client device  100  and network service instance  104 A. For example, router  110 A modifies a first packet of at least one of a forward packet flow and a reverse packet flow of session  340 A to include a header comprising a source address of router  110 A and a destination address of router  110 D along the first path and a portion of metadata specifying a session identifier for session  340 A. 
     Router  110 A obtains one or more metrics of session establishment of session  340 A ( 406 ). For example, the metrics of session establishment may include, e.g., a time elapsed to establish session  340 A, a number of times session  340 A successfully establishes, a number of times session  340 A fails to establish due to timeout, a number of times session  340 A fails to establish due to an unreachable destination, a number of times session  340 A closes prior to TCP session establishment, or a number of times session  340 A closes prior to TLS session establishment, etc. Router  110 A may derive the metrics of session establishment by monitoring the performance and/or state of the first session prior to, during, or after establishment. 
     Router  110 A determines that the one or more metrics of session establishment of session  340 A do not satisfy the one or more session performance requirements for session  340 A ( 408 ). For example, router  110 A may determine that a time elapsed to establish session  340 A exceeds a maximum time permitted to establish session  340 A as set by an SLA requirement for session  340 A. As another example, router  110 A may determine that a number of times session  340 A fails to establish due to timeout exceeds a maximum number of times session  340 A is permitted to establish due to timeout over a predetermined time, as set by an SLA requirement for session  340 A. 
     In response to determining that the one or more metrics of session establishment of session  340 A do not satisfy the one or more session performance requirements for session  340 A, router  110  forwards, along a second path comprising link  316 A, router  110 A, link  326 C, router  110 C, and link  316 E, network traffic for session  340 A (depicted as session  340 A′ in  FIGS.  3 A- 3 B ) ( 410 ). In some examples, router  110 A perform session-based routing for session  340 A′ between client device  100  and network service instance  104 A. For example, router  110 A modifies a second packet of at least one of a forward packet flow and a reverse packet flow of session  340 A to include a header comprising a source address of router  110 A and a destination address of router  110 C along the second path and a portion of metadata specifying a session identifier for session  340 A. 
     In some examples, in response to determining that the one or more metrics of session establishment of session  340 A do not satisfy the one or more session performance requirements for session  340 A, router  110 A optionally excludes the first path from a session load balancer (e.g., session load balancer  240  of  FIG.  2   ). For example, router  110 A removes the first path from inclusion in session load balancer  240 . Subsequently, when selecting a path for a session between client device  100  and service instance  104 , session load balancer  240  may exclude the first path comprising link  316 A, router  110 A, link  326 B, router  110 D, and link  316 D from a set of paths with which router  110 A may use to provide client device  100  with access to the network service via service instance  104 . 
     The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit comprising hardware may also perform one or more of the techniques of this disclosure. 
     Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components. 
     The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable storage medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer readable storage media may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer readable media. 
     Various examples have been described. These and other examples are within the scope of the following claims.