[alto] Some opinions about cost calendar

[Dawn Chan <[e-mail]>]

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. 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?

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;

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;

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

Best Regards,
Dawn