Re: [alto] Some opinions about cost calendar

[Dawn Chan <[e-mail]>]

Hi Sabine,
Sorry for the late reply. And please see my reply inline.
Regards,
Dawn
On 1 Jul 2017, at 1:28 AM, Randriamasy, Sabine (Nokia - FR/Nozay) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Dawn,

Thanks a lot for your review and feedback.
Please see my answers inline,
Thanks,
Sabine


From: Dawn Chan [mailto:[e-mail]]
Sent: 21 June 2017 05:58
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Some opinions about cost calendar

Hi authors of alto-cost-calendar and all,
After reviewing the draft cost calendar, I think there are two points that could be specified more clearly in the cost calendar design.
First, in Section 4.1.1, for a multi-cost aware client, if the number of values of field “calendared” is less than the “cost-type-names” queried, the ALTO server may return an ERROR.
[SR     ] The text clearly says the client MUST add an array of N boolean values corresponding to the N cost types requested. Do you mean we should add a sentence saying that if the size of this array is different from N the server will return an error?
Yes, that’s what I mean, and I see the changes in the new version, thanks.
Another problem related to the field “calendared” is that, if there is a “false” in field “calendared”for a certain cost type while cost types are “true”(for example, the client wants “num-routingcost” to be calendared while do not want “num-latency” to be calendared), when will the cost value of “num-latency” be returned? Will it be returned together with “num-routingcost” after some time intervals?
[SR     ] The ALTO Server MUST return single values as specified in RFC7285 for those cost types for which no calendar is requested. This is written in section 4.3 but you are right, it should be better specified in sections 4.2.2 and 4.1.2. Thanks for pointing this.

Second, the following is the example of he capability of Filtered Cost Map in Section 3.3. As we can see, the cost-type “num-routing-cost” and “num-pathbandwidth” share the same “time-interval-size” and “number-of-intervals”, so they are listed in one “calendar-attributes”.
"capabilities" : {
              "cost-constraints" : true,
              "cost-type-names"  : [ "num-routingcost", "num-pathbandwidth",
                                     "string-service-status" ],
              "calendar-attributes" : [
                 {"cost-type-names" : [ "num-routingcost", "num-pathbandwidth" ],
                  "time-interval-size" : "1 hour",
                  "number-of-intervals" : 24
                 },
                 {"cost-type-names" : "string-service-status",
                  "time-interval-size" : "30 minute",
                  "number-of-intervals" : 48
                 }
               ] // end calendar-attributes
              "uses": [ "my-default-network-map" ]
              }
}

However, the object  CalendarAttributes defined in Section 3.1 is following, it does not support multiple cost-type-names in a single CalendarAttributes currently
object{
     [JSONString   cost-type-name;]
     JSONString    time-interval-size;
     JSONNumber    number-of-intervals;
 } CalendarAttributes;
[SR     ] Agree, this member will be mandatory and an <1**N> array thanks for pointing this

Another point is that in Section 4.2.1, the object ReqEndpointCostMap is extended as follows (a new field calendared is added). It extends the query format of legacy endpoint cost query, we may also need to extend the query format of multi-cost aware query(a new field “calendared” add to the query).
object {
     CostType       cost-type;
     [JSONBoolean    calendared<1..*>;]
     EndpointFilter endpoints;
   } ReqEndpointCostMap;
   object {
     [TypedEndpointAddr srcs<0..*>;]
     [TypedEndpointAddr dsts<0..*>;]
   } EndpointFilter;
[SR     ] Agree, I’ll add some text on Multi-Cost requests

That’s my opinions about the draft cost-calendar. Wish to hear your ideas, thanks.
[SR     ] Thanks

Best Regards,
Dawn