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

▶
flow based cost query
SMART_READER_LITE
LIVE PREVIEW

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

Aug 29, 2023 456 likes •771 views

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:

slide-1
SLIDE 1

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

slide-2
SLIDE 2

Flow-based Design in a Nutshell

2

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
slide-3
SLIDE 3

Key Issues

3

  • #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?

slide-4
SLIDE 4

Flow expression: { “src”: “tcp:192.168.1.2:80”, “dst”: “tcp:192.168.1.3:51234” }

#1 Flow Expression Encoding

Advanced Flow Encoding

  • Flow ID

○ Same format as a PIDName [RFC7285#Section 10.1]

  • Typed header field

○ <protocol-name>:<field-name>

Flow expression: “ssh-flow”: { “ipv4:source”: “192.168.1.2”, “ipv4:destination”: “192.168.1.3”, “tcp:destination”: 22, “ethernet:vlan-id”: 20 }

4

Basic Flow Encoding

  • Commodity-based

○ <src, dst>

  • Endpoint URI

○ <protocol>:<address|name>[:<port>]

slide-5
SLIDE 5

Object { JSONString cost-type-names<1..*>; [JSONBool cost-constraints;] [JSONBool flow-based-filter;] [JSONString protocols<1..*>;] } FlowFilteredCostMapCapabilities; { // ECS IRD Example “cost-type-names”: [“pv-ane”], “flow-based-filter”: true, “protocols”: [“ipv4”, “tcp”, “udp”] } { // ECS Request Example “cost-type”: {“cost-mode”: “path-vector”, “cost-metric”: “ane”}, “flows”: [{“src”: “tcp:10.0.0.1:8080”, “dst”: “tcp:10.0.0.2:51234”}] }

#2 Capabilities and #3 Query Schemes

5

Object { JSONString cost-type-names<1..*>; TypedHeaderField required<1..*>; [TypedHeaderField optional<1..*>;] [JSONBool cost-constraints;] } FlowCostMapCapabilities; { // FCS IRD Example “cost-type-names”: [“pv-ane”], “required”: [“ipv4:src”, “ipv4:dst”], “optional”: [“tcp:src”, “tcp:dst”] } { // FCS Request Example “cost-type”: ..., “flows”: { “test-l3-flow”: { “ipv4:src”: “10.0.0.1”, “ipv4:dst”: “10.0.0.2”, “tcp:src”: “8080”, “tcp:dst”: “51234”} }}

slide-6
SLIDE 6

// 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)

#4 Multipath Issue

6

Notice that it is not a flow-based-specific issue. It exists for both flow-based query and non-flow-based query

slide-7
SLIDE 7

Basic Flow-based Error Handling

  • bject-map {

EndpointURI -> DstErrors; } EndpointCostErrorMap;

  • bject-map {

EndpointURI -> EndpointFilterError; [JSONString unsupported;] } DstErrors;

  • bject {

[JSONString conflicts<2..2>;] [JSONString unsupported;] } EndpointFilterError;

Other Considerations

Advanced Flow-based Error Handling

  • bject-map {

FlowId -> FlowCostError; } FlowCostErrorMap;

  • bject {

[TypedHeaderField conflicts<2..*>;] [TypedHeadreField missing<2..*>;] [TypedHeaderField unsupported<1..*>;] } FlowFilterError;

7

slide-8
SLIDE 8

Open Discussions

8

  • #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?
slide-9
SLIDE 9

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

#1 Flow-based Query by Using Property Map

9

slide-10
SLIDE 10
  • 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:

#2 General Query Across Resources

10

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”] } }

slide-11
SLIDE 11
  • PID is an approach to achieve the endpoint aggregation
  • Define FID to achieve the aggregation of flows?

#3 Flow Aggregation

11

{ “test-l3-flow-agg”: { “ipv4:src”: “10.0.1.0/24”, “ipv4:dst”: “10.0.2.0/24”, “eth:vlan-id”: “10” } }

slide-12
SLIDE 12

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?

Future Work

12

slide-13
SLIDE 13

Thank you!

13

slide-14
SLIDE 14

Backup Slides

14

slide-15
SLIDE 15

Previous Version

15

slide-16
SLIDE 16

Flow-based vs. Endpoint-based

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

16

slide-17
SLIDE 17

Flow-based vs. Endpoint-based (Cont.)

{ “cost-type”: { “cost-mode”: “numerical”, “cost-metric”: “routingcost” }, “flows”: { “l3-flow”: { “ipv4:source”: “192.168.1.1”, “ipv4:DESTination”: “192.168.1.2” }, “optional-l3-flow”: { “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” } } } { “cost-type”: { “cost-mode”: “ordinal”, “cost-metric”: “routingcost” }, “endpoints”: { “srcs”: [“ipv4:192.168.1.1”], “dsts”: [ “ssh:192.168.1.2”, “http:192.168.1.2”, “tcp:192.168.1.3:6655” ] } }

17

slide-18
SLIDE 18

Flow-based vs. Endpoint-based (Cont.)

  • Filter encoding: EndpointFilter -> FlowFilterMap
  • Response encoding: EndpointCostMap -> FlowCostMap
  • Capability: No special capabilities -> FlowCostCapabilities

18

slide-19
SLIDE 19

Cost Confidence for Ambiguous Paths

  • The problem of ambiguous paths exists for

both FCS/ECS

  • Cost confidence: indicate the ambiguity of a

query

  • Examples:

○ Combine the results of all paths and use standard deviation: 1 - | deviation / mean | ○ Select only one path and use the probability: P(|selected path|)/P(all possible path)

19

{"meta": {"cost-type": { "cost-mode": "numerical", "cost-metric": "routingcost" },}, "flow-cost-map": { "l3-flow": 10, "l3-flow-aggr": 50, "optional-l3-flow": 5, }, "flow-cost-confidences": { "l3-flow": 70, "l3-flow-aggr": 40, "optional-l3-flow": 90 } }

slide-20
SLIDE 20

Error and Warning

  • Three kinds of errors:

Conflict/Missing/Unsupported

  • Allow accurate location of errors
  • Can be extended to allow partial

failures and partial recoveries (useful when combined with incremental updates)

20

  • bject-map {

FlowId -> FlowCostError; } FlowCostErrorMap;

  • bject {

[TypedHeaderField conflicts<2..*>;] [TypedHeadreField missing<2..*>;] [TypedHeaderField unsupported<1..*>;] } FlowFilterError;

slide-21
SLIDE 21

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

slide-22
SLIDE 22

Summary

  • Expand the ID space for endpoints (support fine-grained routing)

○ Original (ECS): IP addresses/prefixes ○ draft-wang-alto-ecs-flow: Tuples encoded as URI ○ FCS: Tuples similar to OpenFlow match

  • Introduce the flow-based filter

○ Use case: flow scheduling ○ ECS may not be efficient

  • Response and errors

○ Flow-based cost map ○ Cost confidence: evaluating the effects of ambiguous paths ○ Flow-based error map

22

slide-23
SLIDE 23

Future work

Design related:

  • How can clients give accurate queries?
  • How about if the client cannot decide the flow configuration?

○ For example, a client must query a flow with tcp:source port for fine-grained result. But the client cannot decide which tcp:source port will be used when the application executed.

Implementation related:

  • How to explore ambiguous paths efficiently to compute cost confidence

23

slide-24
SLIDE 24

Motivation: Fine-grained Routing

Network routing trends to be fine-grained

24

H1 H3 SW1 SW2 SW3 Flow1 (tcp:dest==21) Flow2 (tcp:dest==22)

O Expressive O Accurate

H2 Flow3 (tcp:dest==443)

slide-25
SLIDE 25

Motivation: Fine-grained Routing

Network routing trends to be fine-grained

25

H1 H3 SW1 SW2 SW3

O Expressive O Accurate

H2

slide-26
SLIDE 26

Motivation: Fine-grained Routing

Network routing trends to be fine-grained

26

H1 H3 SW1 SW2 SW3

O Expressive O Accurate

H2

slide-27
SLIDE 27

Motivation: Fine-grained Routing

Network routing trends to be fine-grained

27

H1 H3 SW1 SW2 SW3

O Expressive O Accurate

H2

slide-28
SLIDE 28

Motivation: Fine-grained Routing

Network routing trends to be fine-grained

28

H1 H3 SW1 SW2 SW3 Flow1 (tcp:dest==21) Flow2 (tcp:dest==22)

O Expressive O Accurate

H2

slide-29
SLIDE 29

Motivation: Flow correlation

Flow correlation: the costs of different flows are related

29

H1 H3 SW1 SW3 Flow1 Flow2

O Side-effect O Non-peer

H2 SW2 SW4 H4 SW5 SW6 Flow3 Flow4