Subject: Re: [alto] Representing strict cost metrics

From: Wendy Roome <[email-masked]>
Date: Mon, 01 Jun 2015 12:29:38 -0400

Assuming we go forward with strict metrics, here is how we could do it
without breaking legacy clients.

There are two separate issues. One is letting clients know that a metric
obeys the requirements for a formal metric. That can be handled by
requiring anyone who registers a metric with the IANA to say whether or
not it is a formal metric.

The second issue is how to take advantage of the redundancy. If the server
just omitted the zero-diagonal and the lower half of the cost map for any
metric defined as strict, then a legacy client (or a smart client using a
legacy ALTO access library) will get an incomplete cost map. We can solve
that problem by defining a new cost mode, say "strict". This means that
for this cost-type, the server will omit the 0-diagonal and the lower half
of the cost map. The client is expected deduce those values.

Then if (say) the metric geo-distance obeys the formal metric rules, a
server can offer geo-distance in *both* the numerical & strict modes. The
strict-mode cost map omits the redundant cost points, while the
numerical-mode cost map includes them.

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.

Does that sound reasonable?

	- Wendy

On 05/31/2015, 22:39, "Bertz, Lyle T [CTO]" <[email-masked]>
wrote:

>Richard,
>
>You are not too far off at all.  We need to think about this carefully.
>The team I work in is looking to set up topology information in such a
>way that NFV MANO and VIM decisions are simple while still providing some
>traditional transport optimization.
>
>I also think we may need theorems for aggregation of metrics.  I'll have
>to dust off old work by various folks to see if it has not already been
>figured out.
>
>Since cost maps are directed there is no reason why we can't compute max
>and sum distance.  This is practically an exercise left to the reader.
>The symmetric case would be new though.
>
>wrt the July question we may be able to do some work with the old code
>and there may be other code available as well but that will be quite new
>and full of bugs.   I hope to confirm this before the end of June.
>
>Lyle
>

---

From: Piotr Wydrych <[email-masked]>
Date: Mon, 01 Jun 2015 23:33:49 +0200

Hello Wendy,

Although (IMO) metrics cannot be used in a general traffic management 
ALTO use-case, such an extension may be important for some deployments.

> 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
-- 
Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl .. http://wydrych.net/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

---

From: Wendy Roome <[email-masked]>
Date: Tue, 02 Jun 2015 11:05:23 -0400

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

---

From: Piotr Wydrych <[email-masked]>
Date: Tue, 02 Jun 2015 17:24:52 +0200

Hi Wendy, All,

> vigorously, I like your approach.

That's the price of nice services - you cannot cache them. And you 
shouldn't cache a lot of non-standard ALTO responses if you do not know 
client capabilities. Contrary, in a closed deployment (when you know 
CAPA of server and clients), you can always deploy intelligent caches 
that can store replies to POSTs.

Thus, +1 for "non-cacheability is not an issue".

> *any*  cost map.

+1. I like it. It's seems to be generic, simple, and easy to understand.

Best regards,
Piotr 'GhosT' Wydrych