Subject: [alto] New ALTO I-D: draft-gao-alto-fcs

From: Gao Kai <[email-masked]>
Date: Sat, 9 Jul 2016 09:43:22 +0800

Dear all,

We have submitted a new draft[1] in which anew service typenamed flow
cost service is introduced.  The extension allows clients to specify
queries at the flow level, which might result in more accurate costs
especially in a network using new forwarding abstractions such as
OpenFlow.  The flow cost service can also reduce the redundancy of
endpoint cost maps in certain scenarios, mostly the flow scheduling
problem such as VM migrationor large-volume data transfer coordination.

Your comments and opinions are highly appreciated!

Thanks!

Regards,
Kai

[1] https://datatracker.ietf.org/doc/draft-gao-alto-fcs/

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Thu, 21 Jul 2016 10:57:40 +0000

Hi Kai,

Thanks a lot for this proposal, it is a great idea to differentiate path costs wrt flow parameters. A couple of years ago there were discussions to extend the cost value format so as to provide several values depending on so-called qualitative parameters. This draft on the Openflow case is a progress in that direction.

I would have a couple of questions and rough ideas illustrated with an example below.

--- Section 2.3 Cost Confidence and example in section 3.7:
It is valuable to guess the level of reliability of cost values. It may be useful as well for the application clients to have an idea on the value range with indicators such as "+/- X%" (I am not claiming any format here). They would both reflect the confidence and the value range. For instance a value like "20 +/- 200%" may be interpreted differently than "20 +/- 10%". Do you think it makes sense?

--- Section 3 Flow cost service
In addition to flow parameters such as "eth S and D", path costs may be refined wrt considerations such as SLA, access type or other qualitative parameters to be identified.
It would be nice to gather those qualitative parameters in a IRD so that ALTO clients have a list in which to pick parameters wrt which to evaluate path costs.

Having this flexible list, the IRD may then associate an ID "Pi" to each param and the ALTO Server could deliver values in an array such as V1, V2, V3 that would be associated to an array of Pi allowing an easy mapping together with a light encoding.

Do you think you could then consider creating new resources rather than a new media-type?

A rough example (again, names are examples)

-------------------------

IRD capabilities for a flow-cost-map-resource could include:

"capabilities" : {
…..
   "cost-type-names" : [ "num-routingcost",  "num-hopcount" ],
   "flow-parameter-names" : [access-type,
                                                           SLA,
                                                           ethernet source-destination, ... ]
}

A response may have the following example members (please don't blame the syntax errors)

{
"meta" : {
  ...
  "cost-types" : {"cost-mode": "numerical", "cost-metric": "routingcost"},
  "flow-parameters" : [access-type : A1,
                                            SLA : S1,
                                            ethernet source-destination : ["12:34:56:78:00:01",
                                                                                                          "12:34:56:78:00:02"]  ],
  }

   "endpoint-cost-map" : {
   "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89": [15, 5, 12],
      "ipv4:203.0.113.45": [4, 23, 13]
   }
   "ipv6:2001:db8::1:0": {
      "ipv4:198.51.100.34": [16, 5, 14],
      "ipv6:2001:db8::10": [10, 2, 15]
   }
}

-------------------------

Of course a fully fleshed example would be better. I just wanted first to sense opinions and see if you think this makes sense.

Thanks
Sabine

De : alto [mailto:[email-masked]] De la part de Gao Kai
Envoyé : samedi 9 juillet 2016 03:43
À : IETF ALTO
Objet : [alto] New ALTO I-D: draft-gao-alto-fcs

Dear all,

We have submitted a new draft [1] in which a new service type named flow cost service is introduced.  The extension allows clients to specify queries at the flow level, which might result in more accurate costs especially in a network using new forwarding abstractions such as OpenFlow.  The flow cost service can also reduce the redundancy of endpoint cost maps in certain scenarios, mostly the flow scheduling problem such as VM migration or large-volume data transfer coordination.

Thanks!

Regards,
Kai

---

From: Gao Kai <[email-masked]>
Date: Thu, 21 Jul 2016 21:29:05 +0800

Hi Sabine,

Thanks very much for your comments.  Please see below.

On 21/07/16 18:57, Randriamasy, Sabine (Nokia - FR) wrote:
>
> Hi Kai,
>
>  
>
> Thanks a lot for this proposal, it is a great idea to differentiate
> path costs wrt flow parameters. A couple of years ago there were
> discussions to extend the cost value format so as to provide several
> values depending on so-called qualitative parameters. This draft on
> the Openflow case is a progress in that direction.
>
>  
>
> It is valuable to guess the level of reliability of cost values. It
> may be useful as well for the application clients to have an idea on
> the value range with indicators such as "+/- X%" (I am not claiming
> any format here). They would both reflect the confidence and the value
> range. For instance a value like "20 +/- 200%" may be interpreted
> differently than "20 +/- 10%". Do you think it makes sense?
>
I agree.  The cost-confidence is motivated a lot from the concept of
confidence interval which is similar to what you are describing.  I
believe such metrics are not limited to FCS but can be useful for
services like cost map/ECS too.  I'd very much like to adopt this part
into another draft if the working group wants to push forward such
extensions.
> In addition to flow parameters such as "eth S and D", path costs may
> be refined wrt considerations such as SLA, access type or other
> qualitative parameters to be identified.
>
> It would be nice to gather those qualitative parameters in a IRD so
> that ALTO clients have a list in which to pick parameters wrt which to
> evaluate path costs.
>
That's a very good suggestion and we definitely should consider these
parameters.  The first version of the draft concerns more on the fields
OpenFlow can provide because we are more familiar with that.
>
>  
>
> Having this flexible list, the IRD may then associate an ID "Pi" to
> each param and the ALTO Server could deliver values in an array such
> as V1, V2, V3 that would be associated to an array of Pi allowing an
> easy mapping together with a light encoding.
>
>  
>
I believe it is an option, like you demonstrate in the example below. 
We did consider making FCS share the same media-type with ECS, since
they have a lot in common.  For example, all the extensions to the ECS
can be adopted for FCS as well and all ECS queries can be converted to
equivalent FCS queries.

Personally I think the biggest difference between FCS and ECS is how the
query is filtered.  In ECS, we have EndpointFilter which is represented
by two address lists, while in FCS, the filter is described using flows.

However, the flow-based filter is superior to the endpoint-based filter
in some scenarios we encounter, basically where a request cannot be
divided into separate queries.  In such cases, the connection candidates
are something like A1 -> {B1, B2, B3}, A2 -> {C1, C2, C3}, ... If we use
an endpoint-based filter, the resulted endpoint-map would have a lot of
redundant items while a flow-based filter can be more precise.

Of course, we may consider use some thing like: {A1: [B1, B2, B3], A2:
[C1, C2, C3]}

Unfortunately either approach may lead to compatibility problems with
legacy ECS clients, which is probably the most determinant reason why we
decide to introduce a new media-type.
>                                             ethernet
> source-destination : ["12:34:56:78:00:01",
>
>                                                                                                           "12:34:56:78:00:02"] 
> ],
>
>   }
>
>  
>
>    "endpoint-cost-map" : {
>
>    "ipv4:192.0.2.2": {
>
> Of course a fully fleshed example would be better. I just wanted first
> to sense opinions and see if you think this makes sense.
>
>  
>
> Thanks
>
> Sabine
>
>  
>
> *De :*alto [mailto:[email-masked]] *De la part de* Gao Kai
> *Envoyé :* samedi 9 juillet 2016 03:43
> *À :* IETF ALTO
> *Objet :* [alto] New ALTO I-D: draft-gao-alto-fcs
>
>  
>
> Dear all,
>
> We have submitted a new draft [1] in which a new service type named
> flow cost service is introduced.  The extension allows clients to
> specify queries at the flow level, which might result in more accurate
> costs especially in a network using new forwarding abstractions such
> as OpenFlow.  The flow cost service can also reduce the redundancy of
> problem such as VM migration or large-volume data transfer coordination.
>

Regards,
Kai

---

From: Jensen Zhang <[email-masked]>
Date: Fri, 22 Jul 2016 01:16:26 +0800

Hi Sabine, Kai,

Three comments below:

1. About cost confidence design, actually I think it can be simpler. Cost
confidence can be expressed as a cost-metrics without introducing any new
fields. Following is a simple example (the first param in the cost is
routingcost, and the second is cost confidence):

{
"meta": {
  "cost-type": "numerical",
  "cost-metric": "routingcost-with-confidence"
},
"flow-cost-map": {
  "flow1": [30, 90],
  "flow2": [50, 70]
}
}

Because I think indeed cost confidence is a statistical parameter.

2. A major design FCS want to introduce is the flow-based design. Because
we want to make ALTO work on some non-peer scenarios easily. So we use the
flow as the atom in the query filter, rather than the peer. We think it may
be helpful to push ALTO to more application scenarios. We are still
discussing how to encode a flow and try to find a clean and expressive flow
encoding. Considering introducing qualitative parameters is a good
suggestion.

3. Actually, the major challenge FCS is how to make the client indicate a
FCS query easily. In many cases, expressing a flow clearly is difficult. It
may be also associated with ambiguous paths problem. If we want to make FCS
feasible, we have to solve this problem.

Regards,
Jensen

On Thu, Jul 21, 2016 at 9:29 PM, Gao Kai <[email-masked]>
wrote:

> Thanks a lot for this proposal, it is a great idea to differentiate path
> costs wrt flow parameters. A couple of years ago there were discussions to
> extend the cost value format so as to provide several values depending on
> so-called qualitative parameters. This draft on the Openflow case is a
> progress in that direction.
>
>
>
> It is valuable to guess the level of reliability of cost values. It may be
> useful as well for the application clients to have an idea on the value
> range with indicators such as "+/- X%" (I am not claiming any format here).
> They would both reflect the confidence and the value range. For instance a
> value like "20 +/- 200%" may be interpreted differently than "20 +/- 10%".
> Do you think it makes sense?
>
> confidence interval which is similar to what you are describing.  I believe
> such metrics are not limited to FCS but can be useful for services like
> cost map/ECS too.  I'd very much like to adopt this part into another draft
> if the working group wants to push forward such extensions.
>
>
>
> In addition to flow parameters such as "eth S and D", path costs may be
> refined wrt considerations such as SLA, access type or other qualitative
> parameters to be identified.
>
> It would be nice to gather those qualitative parameters in a IRD so that
> ALTO clients have a list in which to pick parameters wrt which to evaluate
> path costs.
>
> Having this flexible list, the IRD may then associate an ID "Pi" to each
> param and the ALTO Server could deliver values in an array such as V1, V2,
> V3 that would be associated to an array of Pi allowing an easy mapping
> together with a light encoding.
>
>
>
> I believe it is an option, like you demonstrate in the example below.  We
> did consider making FCS share the same media-type with ECS, since they have
> a lot in common.  For example, all the extensions to the ECS can be adopted
> for FCS as well and all ECS queries can be converted to equivalent FCS
> queries.
>
> query is filtered.  In ECS, we have EndpointFilter which is represented by
> two address lists, while in FCS, the filter is described using flows.
>
> However, the flow-based filter is superior to the endpoint-based filter in
> some scenarios we encounter, basically where a request cannot be divided
> into separate queries.  In such cases, the connection candidates are
> something like A1 -> {B1, B2, B3}, A2 -> {C1, C2, C3}, ... If we use an
> endpoint-based filter, the resulted endpoint-map would have a lot of
> source-destination, ... ]
>
> }
>
>
>
>
>
> Of course a fully fleshed example would be better. I just wanted first to
> sense opinions and see if you think this makes sense.
>
>
>
> Thanks
>
> Sabine
>
>
>
> *De :* alto [mailto:[email-masked] <[email-masked]>] *De la
> part de* Gao Kai
> We have submitted a new draft [1] in which a new service type named flow
> OpenFlow.  The flow cost service can also reduce the redundancy of endpoint
> cost maps in certain scenarios, mostly the flow scheduling problem such as
> VM migration or large-volume data transfer coordination.
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>