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]] *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
