Piotr,
I'm delighted to discuss this!
I forgot that (unlike metrics) modes are not extensible and new ones
cannot be added by registering them with the IANA. I suspect most clients
would have the foresight to anticipate that new modes might be added
someday, and quietly ignore unknown modes. But you are perfectly correct:
a client just might reject the IRD altogether.
The only problem with your suggestion is that it does not allow GET-mode
requests. A client can still get a full map, it just has to do a POST
request instead. In the past, some folks have thought that was limiting,
because proxies do not cache POST requests.
Fortunately I am not one of those people. So unless someone objects
vigorously, I like your approach.
But I suggest we expand it into an omitted-value compression option for
any cost map, rather than a marker for a strict-metric cost. Specifically,
suppose we define a map-compression extension that can reduce the size of
*any* cost map. A client that understands the compression extension sends
a POST request with this parameter:
"use-compression": true
A legacy server will ignore that parameter, and will return a map as
defined in 7285.
But a server that understands the extension realizes it can add three new
fields to the meta of the response. They are optional, and give implicit
values for omitted cost points:
"symmetric": true
"reflexive-value": 0
"default-value": 50
If symmetric is true, then if c(x,y) is specified in the map, but c(y,x)
is not, set c(y,x) to c(x,y). Note that does NOT mean that all costs are
symmetric. It just means they are symmetric unless otherwise specified.
If reflexive-value is specified, and c(x,x) is omitted, then set c(x.x) to
reflexive-value.
If default-value is specified, and c(x,y) is omitted, and is not defined
by symmetric or reflexive-value, then set c(x,y) to default-value.
What do folks think of that?
- Wendy Roome
On 06/01/2015, 17:33, "Piotr Wydrych" <[email protected]> wrote:
>Although (IMO) metrics cannot be used in a general traffic management
>ALTO use-case, such an extension may be important for some deployments.
>
>W dniu 2015-06-01 o 18:29, Wendy Roome pisze:
>>Thus a client which knows about the strict-mode extension will request
>>strict mode, and will supply the implicit costs. But a legacy client will
>>ignore the unknown mode, and will request the numerical mode instead. So
>>the legacy client still will get a valid geo-distance cost map, with all
>>the cost points. It just won't be as efficient.
>
>RFC says:
> A cost mode is encoded as a string. The string MUST have a value of
> either "numerical" or "ordinal".
>
>Thus, a legacy client may break down and discard whole IRD containing
>"strict" cost-mode. Clients should ignore unknown fields, but not let
>incorrect values go through. Something that may work is adding a new
>field "strict-metric" field to CostType and forcing metric-enabled
>clients to use cost map filtering service. E.g., IRD may say:
>
> "meta" : {
> "cost-types": {
> "num-geo": {
> "cost-mode" : "numerical",
> "cost-metric": "priv:geodistance",
> "strict-metric": true
> }
> }
>
>Then, if a client (any one) GETs a cost map, it will get the full map.
>If a legacy client POSTs for a cost map, it should not add
>"strict-metric" field if it does not know its meaning. Thus, it will get
>all cost pairs again. Finally, a metric-enabled client may POST
>
> POST /costmap/filtered HTTP/1.1
> Host: alto.example.com
> Content-Type: application/alto-costmapfilter+json
> Content-Length: ...
> Accept: application/alto-costmap+json,application/alto-error+json
>
> {
> "cost-type" : {"cost-mode": "numerical",
> "cost-metric": "routingcost",
> "strict-metric": true
> },
> "pids" : { "srcs" : [], "dsts" : [] }
> }
>
>to request a reduced version of the full map. Of course, it may still
>filter a map by providing PIDs.
>
>Looking forward for further discussion on this topic :-)
>
>Best regards,
>Piotr 'GhosT' Wydrych
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
