ALTO WG K. Gao Internet-Draft Tsinghua University Intended status: Standards Track X. Wang Expires: January 9, 2017 C. Gu Tongji University Y. Yang Yale University G. Chen Huawei July 8, 2016 ALTO Extension: A Routing State Abstraction Service Using Declarative Equivalence draft-gao-alto-routing-state-abstraction-03.txt Abstract The Application-Layer Traffic Optimization (ALTO) protocol has defined multiple services (e.g., network maps, cost maps, filtered maps, the endpoint cost service, and the endpoint property service) to provide network state information to network applications. In a higher-level view, both the cost maps and the endpoint cost service can be considered as providing views into the routing state of a network (i.e., the path properties). A drawback of these existing services, however, is that they are static, application-oblivious views, without guidance from network applications. This document designs a new ALTO service named Routing State Abstraction using Declarative Equivalence (RSADE). Allowing applications to provide declarative guidance on the intended use of the network routing state, RSADE allows a network to compute compact, customized routing state abstraction beyond the existing services. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Gao, et al. Expires January 9, 2017 [Page 1] Internet-Draft Routing State Abstraction July 2016 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Multi-flow Scheduling Use Case . . . . . . . . . . . . . 4 3. The RSADE Service . . . . . . . . . . . . . . . . . . . . . . 6 3.1. FlowFilter . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. The Range Equivalence Condition . . . . . . . . . . . . . 8 4. Specification for RSADE Service . . . . . . . . . . . . . . . 11 4.1. Information Resource Directory . . . . . . . . . . . . . 11 4.2. Input . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The key services of the ALTO protocol [RFC7285] can be considered as information query services about the routing state of a network. Specifically, a cost map of an ALTO metric allows a network application to look up the end-to-end value of the given metric, for Gao, et al. Expires January 9, 2017 [Page 2] Internet-Draft Routing State Abstraction July 2016 the routing path(s) from a given source to a given destination. The endpoint cost service provides a similar service. The recent advance of newer network architectures such as SDN, however, reveals that the existing services may have limitations. First, the existing services distinguish routing state at the host level. This is reasonable in a traditional network such as a network using destination IP based routing. The emergence of new techniques such as SDN using OpenFlow may convert more networks to use more fine-grained routing, such as the 5-tuple (source and destination IP addresses, source and destination ports, and protocol) routing. In such a setting, revealing routing state (e.g., cost) at the granularity of end hosts may be too coarse. For example, for a network where port 80 HTTP traffic is routed differently from port 22 traffic, the existing services cannot provide the differentiation. Second, the existing (routing state query) ALTO services are designed for relatively simple network applications. More complex network applications, such as the multi-flow scheduling application [I-D.yang-alto-path-vector], may need more complex routing state information for better application-level coordination. Let f be the network application (or network component) and let view() be the function that constructs an abstract routing state view for f. One can see that view() may compute an on-demand, instead of static, view that will depend on f. The existing ALTO services do not provide this customization capability. A possibility to address the customization problem is that the network provides raw, complete routing state view. However, providing abstract views on top of raw network state, as ALTO does, can provide substantial benefits to both the network, which manages the network state, and the network applications, which consume the network state. First, a more compact abstract network state view can reduce the requirement on client scaling. The raw network state of a large network may consist of a large number of network devices. A consumer of such a large amount of information must be scalable. Second, an abstract network state view can better protect the privacy of the provider of the network. Third, an abstract network state view may substantially reduce the load of information updates. The objective of this document is to design an ALTO extension service named Routing State Abstraction using Declarative Equivalence (RSADE) to address the preceding two issues. Specifically, RSADE provides a simple, declarative API for a network application to specify its need (i.e., requirements) of routing and topology state, and the network computes a minimal, but equivalent routing state to the network application. For simplicity, this document focuses on extending the Gao, et al. Expires January 9, 2017 [Page 3] Internet-Draft Routing State Abstraction July 2016 endpoint cost service, leaving the aggregation aspects of using network aggregation maps as future work. This document is organized as follows. Section 2 replicates the multi-flow scheduling example from [I-D.yang-alto-path-vector]. Section 3 gives an overview of the service, and Section 3.2 gives more details on specifying state equivalence. Section 4 gives the specification of RSADE service. Section 5 and Section 6 discuss security and IANA considerations. 2. The Multi-flow Scheduling Use Case A foundation of the ALTO services is the routing cost value (for a given metric) for each pair of source and destination. Although simple, this foundation may not convey enough information to some applications. This document uses a simple use case in [I-D.yang-alto-path-vector] to illustrate the issue. See [I-D.lee-alto-app-net-info-exchange] for earlier, more comprehensive discussions. We use an example shown in Figure 1. The network has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches sw1/sw3 provide access on one side, s2/s4 provide access on the other side, and sw5-sw7 form the backbone. End hosts eh1 to eh4 are connected to access switches sw1 to sw4 respectively. Assume that the bandwidth of each link is 100 Mbps. Assume that the network is abstracted with 4 PIDs, with each representing the hosts at one access switch. +------+ | | --+ sw6 +-- / | | \ PID1 +-----+ / +------+ \ +-----+ PID2 eh1__| |_ / \ ____| |__eh2 | sw1 | \ +--+---+ +---+--+ / | sw2 | +-----+ \ | | | |/ +-----+ \_| sw5 +---------+ sw7 | PID3 +-----+ / | | | |\ +-----+ PID4 eh3__| |__/ +------+ +------+ \____| |__eh4 | sw3 | | sw4 | +-----+ +-----+ Figure 1: Raw Network Topology Gao, et al. Expires January 9, 2017 [Page 4] Internet-Draft Routing State Abstraction July 2016 +--------+---------------+ | Link | Description | +--------+---------------+ | link1 | sw1 <==> sw5 | | link2 | sw2 <==> sw7 | | link3 | sw3 <==> sw5 | | link4 | sw4 <==> sw7 | | link5 | sw5 <==> sw6 | | link6 | sw6 <==> sw7 | | link7 | sw7 <==> sw5 | +--------+---------------+ Table 1: Description of the Links Consider an application overlay (e.g., a large data transfer system) which needs to schedule the traffic among a set of end host source- destination pairs, say eh1 -> eh2, and eh3 -> eh4. The application can request a cost map (or endpoint cost service) providing end-to- end available bandwidth, using 'available bw' as cost-metric and 'numerical' as cost-mode, where the 'available bw' between two end hosts represents their available bandwidth, if no other applications use shared resources. Assume that the application receives from the cost map that both eh1 -> eh2 and eh3 -> eh4 have bandwidth 100 Mbps. It cannot determine that if it schedules the two flows together, whether it will obtain a total of 100 Mbps or 200 Mbps. This depends on whether the routing of the two flows shares a bottleneck in the underlying topology: o Case 1: If the two flows use different paths in the current routing state, for example, when the first uses sw1 -> sw5 -> sw7 -> sw2, and the second uses sw3 -> sw5 -> sw6 -> sw7 -> sw4. Then the application will obtain 200 Mbps. o Case 2: If the two flows share a bottleneck in the current routing state, for example, when both use the direct link sw5 -> sw7, then the application will obtain only 100 Mbps. To allow applications to distinguish the two aforementioned cases, the network needs to provide more details on the routing state. A naive solution to this problem, then, is to return the two complete, detailed routes and the available bandwidth of each link on the routes. But this may not be desirable, as the application may not need the details and/or may not have the permission to see networks details. Now consider what route abstraction can achieve. Assuming case 2 (shared bottleneck), it is sufficient for the network to return a Gao, et al. Expires January 9, 2017 [Page 5] Internet-Draft Routing State Abstraction July 2016 single abstract link for each flow: ane1(100Mbps), where ane stands for abstract network element, and the number in the number 100Mbps denotes its capacity. Consider a variation of the preceding case. Assume that the capacity of the link from sw1 to sw5 is 70 Mbps, while the rest are still at 100 Mbps. Then the abstract route from eh1 to eh2 becomes ane1(100Mbps) and ane2(70Mbps). 3. The RSADE Service The more the network knows about what a network application f needs regarding a routing state query, the more concise the network response can be. Hence, an extreme API is that the complete network application f (i.e., the code and related state) is sent to the network. This, however, can create substantial complexity in the routing-state query component, as even some simple program properties (e.g., halting) are already difficult to analyze. Also, in settings such as inter-domain, the owner of the function f may not want to provide the complete f to the network. Another extreme API is that each routing state query provides only the most basic information (i.e., the source and the destination). This, however, does not provide enough information for the routing- state service to compute efficient route abstraction/compression. Hence, the returned routes will be independent of individual functions, missing out opportunities on abstraction or compression. The routing state abstraction service tries to strike a balance between the two extremes. As a start, such an abstraction service, namely RSADE, is introduced in this document. Using a general abstraction mechanism called the _link elimination_, as described in Section 3.2.1, the service, however, is specialized for multiple-flow coordination, which is the common mathematical model for scenarios from simply using bandwidth as the ALTO routing cost to conducting traffic engineering in a real network. RSADE is short for Routing State Abstraction using Declarative Equivalence. As the name suggests, this service provides _equivalent_ routing state according to the consumer's demands which are described in a _declarative_ manner. Figure 2 gives the grammar to specify the query information that a network application sends to the network: Gao, et al. Expires January 9, 2017 [Page 6] Internet-Draft Routing State Abstraction July 2016 rs-query := flow-desc equiv-cond flow-desc := EndpointFilter | FlowFilter Figure 2: Grammar for RSADE The first component of a RSADE query is the description of the desired flow candidates, which can be either a EndpointFilter as defined in Section 11.3.2.3 from [RFC7285] or a FlowFilter as in Figure 3. A EndpointFilter represents a complete bipartite graph, with _srcs_ on one side and _dsts_ on the other, in a quite compressed way. Meanwhile, FlowFilter enables the application to designate the flows more precisely, which can reduce the computation overhead when the virtual bipartite graph is sparse. The second component of the query input is the equivalence condition. A particular type of equivalence condition, in the context of multiple-flow coordination, is the range equivalence condition. We give the detailed specification of the condition in Section 3.2. Upon receiving an RSADE request, the network retrieves the route for each flow, and then computes the result after compression (abstraction). RSADE may allow a network application to specify an indicator, on whether it wants to receive incremental updates to the query results, achieving push notification. The push notification is implemented using HTTP SSE [I-D.ietf-alto-incr-update-sse]. 3.1. FlowFilter Figure 3 provides the grammar of FlowFilter, which is a list of flow specifications each representing one flow in the network. For backward compatibility, a flow specification is described using a (src, dst) pair at the moment. However, it can be extended to support other properties as well, such as VLAN, HTTP proxy server or VPN gateways. The extensions of FlowFilter are beyond the scope of this document. FlowFilter := flow-list flow-list := flow-spec, [flow-list] flow-spec := generic-match-condition Figure 3: Grammar for FlowFilter Gao, et al. Expires January 9, 2017 [Page 7] Internet-Draft Routing State Abstraction July 2016 3.2. The Range Equivalence Condition 3.2.1. Link Elimination Let each A[i] be a vector for a given link attribute such as bandwidth, delay and so on. Let vector R[i] represent the result of route lookup for flow i, where R[i][e] is the fraction of traffic of flow i on link e, according to the current routing state. For example, the result of route lookup for the use case in Section 2 can be represented as the following: +--------+-------+-------+-----------------+-------------+-------+ | Link | R[0] | R[1] | A[1]/bandwidth | A[2]/delay | A[3] | +--------+-------+-------+-----------------+-------------+-------+ | link1 | 1 | 0 | 100M | 2ms | ... | | link2 | 1 | 0 | 100M | 5ms | ... | | link3 | 0 | 1 | 100M | 5ms | | | Link4 | 0 | 1 | 100M | 5ms | | | link5 | 1 | 1 | 100M | 7ms | | | link6 | 1 | 1 | 100M | 4ms | | +--------+-------+-------+-----------------+-------------+-------+ Table 2: Complete Routing State Although a routing-state query without abstraction/compression will return all of the data shown above, route abstraction/compression will select only a subset link attributes (columns) and some links (rows). Elimination of links from the complete result achieves compression but may result in loss of information to the application. Hence, a specification on conditions whether the elimination of a set of links from the complete result leads to information loss or not is the key to the problem definition. Such a specification, however, can be provided only by the application itself. 3.2.2. Input In the general case, the result from the routing-state query will become the input parameters for the algorithms in the network application to help make decisions. Let x denote the vector of the decision variables in the application. Then, one can identify that a generic structure of the application is to solve/optimize an objective function, obj(x), subject to two types of constraints on x: (1) those do not involve the results from the routing state query; and (2) those do. Let the first type limit x in X0. Regarding the second type, most algorithms typically handle only linear constraints, and hence the set S of constraints of this type will be of the format a_k x <= b_k, where a_k is a vector, and b_k a constant. Hence, it is in a_k or b_k where the result from the Gao, et al. Expires January 9, 2017 [Page 8] Internet-Draft Routing State Abstraction July 2016 routing-state query appears. Let A x <= b as a matrix format to represent the whole set of constraints. [Equivalent Routing-State Query] A declarative equivalence based routing-state query is one where the querier (application) declares X_0 and a set of constraints S = {a_k x <= b_k}. Based on the definition of equivalent routing-state query, the grammar for the equivalence condition is defined in Figure 4. equiv-cond := variable-list X0 link-constraint-list variable-list := variable-name[, variable-list] X0 := simple-constraint[, simple-constraint] simple-constraint := simple-expr CMP-OP simple-expr simple-expr := constant * variable-name[ + simple-expr] link-constraints-list := link-constraint[, link-constraint-list] link-constraint := link-expr CMP-OP link-expr link-expr := constant | attribute-name | variable-name | constant * link-expr | attribute-name * link-expr | link-expr + link-expr Figure 4: Grammar for Equivalence Condition 3.2.3. Response We use the terms defined below to better describe the abstracted routing state. [Equivalence] Two constraint sets S_1 and S_2 of a network function are equivalent if and only if they limit the decision variables in the same way: X_0 ^ {x: A_1 x <= b_1 } = X_0 ^ {x: A_2 x <= b_2 }. [Redundant] A constraint s is redundant to a constraint set S if and only if s in S and the two sets S and S\{s} are equivalent. [Minimal Constraint Set] A constraint set S is minimal if and only if for any s in S, s is not redundant. It can be seen that if the attribute of a link does not appear in a minimal constraint set, this link will have no effect on the querier application's decision making. In that case, eliminating the link would cause no information loss. Thus to minimize the routing state, this link must be eliminated from the routing-state result. Based on Gao, et al. Expires January 9, 2017 [Page 9] Internet-Draft Routing State Abstraction July 2016 this observation we define the response to an equivalent routing state query as below. [Equivalent Routing-State Response] A response to a declarative equivalence based routing-state query is the one containing all the links whose requested attributes appear in the minimal constraint set. To describe the routing state response, different output formats are used for different flow descriptions. For those specified by EndpointFilter, we will use the path vector format defined in [I-D.yang-alto-path-vector]. For those specified by FlowFilter, we will use an extended format defined in Section 4.3.1. An example of the equivalent routing state to a query with the following settings is given in Table 3: o There are two requested flows the same as in Table 2. o The variable list is [x, y]. o The X0 is empty o The link constraint list is [R[0] * x + R[1] * y < bandwidth] +-------+-------+-------+-----------------+ | Link | R[0] | R[1] | A[1]/bandwidth | +-------+-------+-------+-----------------+ | ane1 | 1 | 1 | 100M | +-------+-------+-------+-----------------+ Table 3: Abstracted Routing State for Querying Bandwidth A concern one may have is that the preceding definition may be limited. Consider the case of hierarchical networks, where the upper-layer network (i.e., the network application) conducts routing (traffic engineering) in its layer and uses RSADE to obtain the state of the lower layer. Let flows be the n(n-1) source-destination pairs in the upper layer network with n nodes. Let x be the set of decision variables controlling the routing in the upper-layer, where each element is the routing on each of the preceding flows. Let X_0 encode the constraints on traffic demand. We have the following result: [UTE Completeness] Any upper-layer routing (traffic engineering) algorithm where the goal of RSADE in the lower-layer network is to avoid congestion of shared links or shared risk groups can be implemented using the declarative equivalence based routing-state Gao, et al. Expires January 9, 2017 [Page 10] Internet-Draft Routing State Abstraction July 2016 query. We refer to this as the upper-layer traffic engineering (UTE). Let A = R and b = cap. Then the RSADE query returns a link only if the link may become a bottleneck in the upper layer network. 4. Specification for RSADE Service In this section we describe the specifications for the RSADE service. 4.1. Information Resource Directory We introduce the RSADE service as an extension to the Endpoint Cost Service. First we extend the cost type to indicate that this resource supports RSADE service. Second, we add a new capability named "network-attribute-names" to announce the names of network attributes that can be used in the link-constraints. The exact specifications of the corresponding network attributes will be announced in the meta field of an IRD, just like cost types. There are also other drafts proposing extensions on unified properties, such as [I-D.roome-alto-unified-props]. Gao, et al. Expires January 9, 2017 [Page 11] Internet-Draft Routing State Abstraction July 2016 { "meta": { "cost-types: { "rsade-cost-type: { "cost-metric": "rsade", "cost-mode": "path-vector", "description": "The cost type for RSADE service" } }, "network-attributes": { "bandwidth": ..., "link-capacity": ... } }, "resources": { "rsade-example": { "uri": "http://alto.example.com/ecs/rsade", "media-type": "application/alto-endpointcost+json", "accepts": "application/alto-endpointcostparams+json", "capabilities": { "cost-type-names": [ "rsade-cost-type" ], "network-attribute-names": [ "bandwidth", "link-capacity" ] } } } } Figure 5: IRD Extensions for RSADE 4.2. Input As described in Section 3.2.2, applications using the RSADE service should specify flows as well as the equivalence conditions of these flows. In this document, we define the input of RSADE service as RSQuery: Gao, et al. Expires January 9, 2017 [Page 12] Internet-Draft Routing State Abstraction July 2016 object { CostType cost-type; [EndpointFilter endpoints;] [FlowFilter flows;] RSEquivCond equiv-cond; } RSQuery; object { FlowSpec specs<1..*>; } FlowFilter; object { TypedEndpointAddress src; TypedEndpointAddress dst; } FlowSpec; object { VariableName variables<1..*>; [SimpleConstraint basic-constraints<0..*>;] LinkConstraint link-constraints<1..*>; } RSEquivCond; Figure 6: Specification for the RSQuery The VariableName should have the same format as the network attribute names, with no more than 32 characters and contains only the ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A) and the underscore '_'. Also they MUST not start with an ASCII numeric character (U+0030-U+0039). To avoid collision, the values in the network-attribute-names MUST not appear in the variables field. Otherwise the server SHOULD return an error with the "E_INVALID_FIELD_VALUE" code, as defined in [RFC7285]. Network attribute names MUST no appear in a SimpleConstraint and each LinkConstraint MUST contain at least 1 network attribute name and at least one variable name. The special network attribute, the routing ratio R, can always be used in a RSADE query and MUST appear as R[?] in a LinkConstraint. The valid index range is determined by the type of the flow-desc. For an EndpointFilter with N srcs and M dsts, the range will be N*M and the routing ratio for the flow between src_i and dst_j is R[(i-1)*M + j] where 1<=i<=N, 1<=j<=M. For an FlowFilter with N flows, it's much more straightforward: R[i] represents the routing ratio for the i-th flow. Gao, et al. Expires January 9, 2017 [Page 13] Internet-Draft Routing State Abstraction July 2016 4.3. Output As described in Section 3.2.3, the response to a declarative equivalence based routing-state query should include flow specifications and the corresponding minimal constraints. Different flow specifications have different format of response. For those specified by EndpointFilter, we will use the path vector format defined in [I-D.yang-alto-path-vector]. Here we define the format of response for FlowFilter. 4.3.1. Response for FlowFilter object { CostType cost-type; FlowFilter flows; RSEquivCond min-constraints; } RSResponse; Figure 7: Specification for the FlowFilter RSResponse The minimal constraints in RSResponse are generated based on both the equivalence conditions submitted by applications and also the link constraints in the network. The minimal constraints have the same format of RSEquivCond that includes simple-constraints and link- constraints. 5. Security Considerations This document has not conducted its security analysis. 6. IANA Considerations This document requires the definition of a new cost-mode named path- vector. 7. Acknowledgments The author thanks discussions with Jun Bi and Andreas Voellmy. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Gao, et al. Expires January 9, 2017 [Page 14] Internet-Draft Routing State Abstraction July 2016 8.2. Informative References [I-D.ietf-alto-incr-update-sse] Roome, W. and Y. Yang, "ALTO Incremental Updates Using Server-Sent Events (SSE)", draft-ietf-alto-incr-update- sse-02 (work in progress), April 2016. [I-D.lee-alto-app-net-info-exchange] Lee, Y., Dhody, D., Wu, Q., Bernstein, G., and T. Choi, "ALTO Extensions to Support Application and Network Resource Information Exchange for High Bandwidth Applications in TE networks", draft-lee-alto-app-net-info- exchange-04 (work in progress), October 2013. [I-D.roome-alto-unified-props] Roome, W., "Extensible Property Maps for the ALTO Protocol", draft-roome-alto-unified-props-00 (work in progress), July 2015. [I-D.yang-alto-path-vector] Bernstein, G., Gao, K., Lee, Y., Roome, W., Scharf, M., and Y. Yang, "ALTO Extension: Path Vector Cost Mode", draft-yang-alto-path-vector-03 (work in progress), July 2016. [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, . Authors' Addresses Kai Gao Tsinghua University 30 Shuangqinglu Street Beijing 100084 China Email: gaok12@mails.tsinghua.edu.cn Gao, et al. Expires January 9, 2017 [Page 15] Internet-Draft Routing State Abstraction July 2016 Xin (Tony) Wang Tongji University 4800 CaoAn Road Shanghai 210000 China Email: xinwang2014@hotmail.com Chen Gu Tongji University 4800 CaoAn Road Shanghai 210000 China Email: gc19931011jy@gmail.com Y. Richard Yang Yale University 51 Prospect St New Haven CT USA Email: yry@cs.yale.edu G. Robert Chen Huawei Nanjing China Email: chenguohai@huawei.com Gao, et al. Expires January 9, 2017 [Page 16]