Flow-based Cost Query draft-gao-alto-fcs-01 Kai Gao 1 J. Jensen - PowerPoint PPT Presentation

Flow-based Cost Query draft-gao-alto-fcs-01 Kai Gao 1 J. Jensen Zhang 2 J. Austin Wang 2 Qiao Xiang 3 Y. Richard Yang 3 1 Tsinghua University 2 Tongji University 3 Yale University March 31@IETF 98

Flow-based Design in a Nutshell Cost Services: Cost Map (Non-Query Service), Filtered Cost Map, ECS (Query Service) Motivations: Flow correlation (CoFlow...) ● Extend the query scheme ➜ Augment request or introduce new media-type of request ➜ Fine-grained routing (OpenFlow, ECMP, MPLS...) ● Effect both request and response ➜ Why not introduce a new resource (service)? ( incomplete ) ➜ Why not introduce a unified resource (service)? ( complete ) ➜ Previous work: draft-wang-alto-ecs-flow : augment the syntax of TypedEndpointAddress -> EndpointURI ● draft-gao-alto-fcs : Introduce “application/alto-flowcost+json”, “application/alto-flowparams+json” ● Major update since -00: Claim draft-wang-alto-ecs-flow as the basic flow-based query design ● Rename draft-gao-alto-fcs as the advanced flow-based query design ● 2

Key Issues #1 How to encode a flow ● <src, dst> (downward compatible) ○ {attribute -> value} (novel specification) ○ #2 How to declare the capabilities ● “Boolean flow-query-support;”? ○ “JSONString support-attributes<1..*>;”? ○ TLV dependencies? ○ #3 How to encode a query scheme ● CommodityFilter? FlowNameFilter? FlowSpecFilter? ○ #4 How to deal with multipath ● Provide statistics? Exploration? Warning? ○ 3

#1 Flow Expression Encoding Basic Flow Encoding Advanced Flow Encoding Commodity-based Flow ID ● ● <src, dst> Same format as a PIDName ○ ○ Endpoint URI [RFC7285#Section 10.1] ● Typed header field ● ○ <protocol>:<address|name>[:<port>] ○ <protocol-name>:<field-name> Flow expression: Flow expression: { “ssh-flow”: { “src”: “tcp:192.168.1.2:80”, “ipv4:source”: “192.168.1.2”, “dst”: “tcp:192.168.1.3:51234” “ipv4:destination”: “192.168.1.3”, } “tcp:destination”: 22, “ethernet:vlan-id”: 20 } 4

#2 Capabilities and #3 Query Schemes Object { Object { JSONString cost-type-names<1..*>; JSONString cost-type-names<1..*>; TypedHeaderField required<1..*>; [JSONBool cost-constraints;] [TypedHeaderField optional<1..*>;] [JSONBool flow-based-filter;] [JSONBool cost-constraints;] [JSONString protocols<1..*>;] } FlowCostMapCapabilities; } FlowFilteredCostMapCapabilities; { // FCS IRD Example { // ECS IRD Example “cost-type-names”: [“pv-ane”], “cost-type-names”: [“pv-ane”], “required”: [“ipv4:src”, “ipv4:dst”], “flow-based-filter”: true, “optional”: [“tcp:src”, “tcp:dst”] “protocols”: [“ipv4”, “tcp”, “udp”] } } { // FCS Request Example { // ECS Request Example “cost-type”: ..., “cost-type”: {“cost-mode”: “path-vector”, “flows”: { “cost-metric”: “ane”}, “test-l3-flow”: { “flows”: [{“src”: “tcp:10.0.0.1:8080”, “ipv4:src”: “10.0.0.1”, “ipv4:dst”: “10.0.0.2”, “dst”: “tcp:10.0.0.2:51234”}] “tcp:src”: “8080”, “tcp:dst”: “51234”} 5 } }}

#4 Multipath Issue Notice that it is not a flow-based-specific issue. It exists for both flow-based query and non-flow-based query // Statistics (Recommended) { “test-l3-flow”: {“min”: 20, “max”: 40, “avg”: 30, “var”: 50}, } // How to deal with the path vector? // List all the potential paths { “test-l3-flow”: [20, 40], // Means two different path matching the same flow spec } // How to work with multi-cost extension together? // Warning { “test-l3-flow”: “MP”, } // The client may waste a query (this result is useless for the client) 6

Other Considerations Basic Flow-based Error Handling Advanced Flow-based Error Handling object-map { object-map { EndpointURI -> DstErrors; FlowId -> FlowCostError; } EndpointCostErrorMap; } FlowCostErrorMap; object-map { object { EndpointURI -> EndpointFilterError; [TypedHeaderField conflicts<2..*>;] [JSONString unsupported;] [TypedHeadreField missing<2..*>;] } DstErrors; [TypedHeaderField unsupported<1..*>;] } FlowFilterError; object { [JSONString conflicts<2..2>;] [JSONString unsupported;] } EndpointFilterError; 7

Open Discussions #0 Who defines flows better? ● Client-defined: specify the flow definition in the request -> TLV ○ dependencies? Server-defined: maybe in a prop-map, provided to the client for ○ querying #1 New cost service or unified property service? ● #2 Simple constraints or general query language? ● #3 Endpoint aggregation or flow aggregation? ● 8

#1 Flow-based Query by Using Property Map Open discussion: possible to use property map to implement flow-based query? Property Map to define the supported header fields and TLV dependencies ● Declare the supported header fields for each endpoints? ○ Property Map to define the supported flows ● List all supported flows? (Too complex. A huge map) ○ Property Map to provide the flow costs ● Depends on the flow definitions ○ 9

#2 General Query Across Resources Property Query Constraints ● { “properties”: [“ipv4:src”, “tcp:src”], “constraints”: [“[1] eq 8080”]} ○ Resource Dependency and Resource Query Joint ● “flow-cost-prop-map” uses “flow-spec-prop-map” ○ The client can send a joint query: ○ HTTP/1.1 OK { “flow-spec-prop-map”: { “properties”: [“ipv4:src”, “tcp:src”], “constraints”: [“[0] eq 10.0.0.1”, “[1] eq 8080”] }, “flow-cost-prop-map”: { “entities”: “flow-spec-prop-map.keys”, “properties”: [“cost”] } 10 }

#3 Flow Aggregation PID is an approach to achieve the endpoint aggregation ● Define FID to achieve the aggregation of flows? ● { “test-l3-flow-agg”: { “ipv4:src”: “10.0.1.0/24”, “ipv4:dst”: “10.0.2.0/24”, “eth:vlan-id”: “10” } } 11

Future Work Status: We are implementing the prototype in OpenDaylight ● Next Step: Considering to merge with Path Vector? ● Try to use Unified Property Map? ● Adopt as a WG item? ● 12

Thank you! 13

Backup Slides 14

Previous Version 15

Flow-based vs. Endpoint-based Object { Object { CostType cost-type; FlowFilterMap flows; [JSONString constraints<0..*>;] } FlowCostRequest : MultiCostRequestBase; EndpointFilter endpoints; Object { } ReqEndpointCostMap; [CostType cost-type;] [CostType multi-cost-types<1..*>;] Object { [CostType testable-cost-types<1..*>;] [EndpointDescriptor srcs<0..*>;] [JSONString constraints<0..*>;] [EndpointDescriptor dsts<0..*>;] [JSONString or-constraints<0..*><0..*>;] } EndpointFilter; } MultiCostRequestBase; EndpointDescriptor := Object-map { protocol : address : port | FlowId -> FlowFilter; protocol : address } FlowFilterMap; Object-map { TypedHeaderField -> JSONValue; } FlowFilter; 16

Flow-based vs. Endpoint-based (Cont.) { { “cost-type”: { “cost-type”: { “cost-mode”: “numerical”, “cost-mode”: “ordinal”, “cost-metric”: “routingcost” “cost-metric”: “routingcost” }, }, “flows”: { “endpoints”: { “l3-flow”: { “srcs”: [“ipv4:192.168.1.1”], “ipv4:source”: “192.168.1.1”, “dsts”: [ “ipv4:DESTination”: “192.168.1.2” “ssh:192.168.1.2”, }, “http:192.168.1.2”, “optional-l3-flow”: { “tcp:192.168.1.3:6655” “ipv4:sourcE”: “192.168.1.1”, ] “Ipv4:destination”: “192.168.1.2”, } “ethernet:sOuRce”: “12:34:56:78:00:01”, } “ethernet:destination”: “12:34:56:78:00:02” } } } 17

Flow-based vs. Endpoint-based (Cont.) Filter encoding: EndpointFilter -> FlowFilterMap ● Response encoding: EndpointCostMap -> FlowCostMap ● Capability: No special capabilities -> FlowCostCapabilities ● 18

Cost Confidence for Ambiguous Paths The problem of ambiguous paths exists for ● {"meta": {"cost-type": { "cost-mode": "numerical", both FCS/ECS "cost-metric": "routingcost" Cost confidence: indicate the ambiguity of a ● },}, query "flow-cost-map": { Examples: ● "l3-flow": 10, "l3-flow-aggr": 50, Combine the results of all paths and use standard ○ "optional-l3-flow": 5, deviation: }, 1 - | deviation / mean | "flow-cost-confidences": { Select only one path and use the probability: ○ "l3-flow": 70, P(|selected path|)/P(all possible path) "l3-flow-aggr": 40, "optional-l3-flow": 90 } } 19

Error and Warning Three kinds of errors: ● object-map { FlowId -> FlowCostError; Conflict/Missing/Unsupported } FlowCostErrorMap; Allow accurate location of errors ● Can be extended to allow partial ● object { [TypedHeaderField conflicts<2..*>;] failures and partial recoveries [TypedHeadreField missing<2..*>;] (useful when combined with [TypedHeaderField unsupported<1..*>;] incremental updates) } FlowFilterError; 20

Compatibility Support all cost types and possible extensions ● Multi-cost ○ Calendar ○ Path vector ○ Support incremental updates ● Have no side-effect on legacy clients/servers ● 21