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 protected]>
wrote:
> 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.
>
>
>
> 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?
>
> 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.
>
>
>
> --- 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.
>
> 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.
>
>
>
> Do you think you could then consider creating new resources rather than a
> new media-type?
>
>
>
> 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.
>
> 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 protected] <[email protected]>] *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.
>
> Your comments and opinions are highly appreciated!
>
> Thanks!
>
> Regards,
> Kai
>
> [1] https://datatracker.ietf.org/doc/draft-gao-alto-fcs/
>
>
> Regards,
> Kai
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
