Subject: Re: [alto] Interop test

From: Jan Seedorf <[email-masked]>
Date: Mon, 1 Jun 2015 15:10:26 +0000

Regarding the date/time: the chairs can likely only make it on one of the following evenings during the IETF week: MON, WED, THU. We are aiming at 3-4h. Does that work for the people interested?

We have contacted the secretariat to tentatively reserve a room etc.

 - Jan

-----Original Message-----
From: alto [mailto:[email-masked]] On Behalf Of Y. Richard Yang
Sent: Samstag, 30. Mai 2015 12:48
To: Bertz, Lyle T [CTO]
Cc: Wendy Roome; [email-masked]
Subject: Re: [alto] Interop test

It is great to open email and see these discussions!

First, answer to Lyle's P.S. question: We are looking at an interop in the July IETF meeting. Does this work for you? We sure hope that your team can participate.

I agree that denoting some metrics to be a formal metric is a great idea. An immediate benefit coming to mind is that it allows compression, for example, only half of the cost matrix need to transmitted.

I particularly liked the idea of defining the (network) graph metrics.
Your suggestion  appear to me to have two directions:
(1) still use the cost map framework and defining graph metrics between pairs of PIDs (i.e., metrics between a pair of nodes in a graph);
(2) provide overall network (graph) properties; that is, provide summary properties of the overall network topology (periphery comes to mind).

I can see a unifying framework such as there is a hierarchy of network graphs, and at each level, one can define properties on a network node or a pair of nodes. Assume the highest level is a single node representing the overall topology, and then such a compound node can have properties such as center/periphery).

Am I too off in understanding your ideas?

Thanks!

Richard

On 5/29/15, Bertz, Lyle T [CTO] <[email-masked]> wrote:
> Wendy,
>
>
>
> I worked on asymmetric distance theory in graphs - specifically max 
> distance and sum distance so I can definitely say the asymmetry is not an issue and
> you should assume that asymmetric metrics exist in a digraph.   In fact,
> distance is defined at the minimum value of the directed distance from 
> u to v or v to u.
>
>
>
> wrt to your statement d(x,x)=0 is correct because of granularity (that x is
> actually a new set where and x1 and x2 are actually involved).   Such
> summarization would be better described as common subgraph such as a 
> periphery, center, status or median.  For example, if x1 and x2 are in the
> center or periphery we would expect status measurements to be similar.   In
> general we would not measure distance between x1 and x2 but but merely 
> talk about periphery elements as 'x'.  Precision is a whole other 
> matter as well.
>
>
>
> I think identifying metrics that follow formal metric definition is
> definitely a great idea.   For clients and servers we can identify other
> graph metrics.  The two that come to mind are center and periphery of a
> graph.   Where asymmetry is present we can apply max and sum distance to
> yield the center and periphery versions for max and sum distance.
>
>
>
> These metrics and definitions are used quite often in computing edge 
> of networks, how to merge two networks together, Steiner cut selections, etc.
> Periphery is the most interesting as it tells a lot about the status 
> of node traffic and hints for placement, e.g. nfv instance selection 
> in MANO when implementing a VNF FG - I could see that being useful for 
> both client and servers.
>
>
>
> Lyle
>
>
>
> ________________________________
> From: Wendy Roome <[email-masked]>
> Sent: Friday, May 29, 2015 4:06 PM
> To: Bertz, Lyle T [CTO]; Y. Richard Yang
> Cc: [email-masked]; Hans Seidel; [email-masked]
> Subject: Re: [alto] Interop test
>
> Lyle,
>
> I haven't used metric spaces since the days of keypunches, so it took 
> a while to blow the cobwebs out of that memory bank. :-)
>
> I don't think ALTO cost metrics could ever meet the requirements for a 
> metric space. The problems:
>
> * A true metric d(x,y) must be defined for all x & y. ALTO does not 
> require that the cost be defined for all pairs.
>
> * For a metric, d(x,y) = d(y,x) for all x,y. ALTO costs represent 
> communication links, and are potentially asymmetric. Eg,  the download 
> bandwidth can be higher than the upload bandwidth.
>
> * For a metric, d(x,x) = 0 for all x. For ALTO, the cost within a PID 
> frequently is greater than 0.
>
> * For a metric, d(x,y) = 0 means x = y. We *might* be able to define 
> ALTO costs so that is possible, but I have my doubts.
>
> * For a metric, d(x,z) <= d(x,y) + d(y,z) for all y. For ALTO, that is 
> tempting requirement, and I cannot think of an obvious counter 
> example. But I doubt that would help without the other requirements.
>
> So we could not require *every* ALTO cost metric to qualify as a 
> mathematical metric. But we could define a particular cost as 
> satisfying those rules, and (say) identify it in the IRD.  Can you 
> explain how that would benefit clients or servers? One obvious 
> advantage is that the cost matrix could be smaller, because its 
> symmetric and the center diagonal is 0.
>
> - Wendy Roome
>
> From: "Bertz, Lyle T [CTO]"
> <[email-masked]<mailto:[email-masked]>>
> Date: Fri, May 29, 2015 at 16:03
> To: Wendy Roome
> <[email-masked]<mailto:[email-masked]>>, "Y. 
> Richard Yang" <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>, Hans Seidel 
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]
> g>>
> Subject: RE: [alto] Interop test
>
> I had not put together the comparison applying to the same requests.   That
> makes matters convenient as the included data only applies to the response.
>
> Without formal metric compliance though there are a lot of algorithms 
> that could not be reliably applied.  I think we should consider this 
> as we move forward in developing ALTO.  It may be worthwhile to 
> clarify matters in a future update.
>
> From: Wendy Roome [mailto:[email-masked]]
> Sent: Friday, May 29, 2015 2:45 PM
> To: Bertz, Lyle T [CTO]; Y. Richard Yang
> Cc: [email-masked]<mailto:[email-masked]>; Hans Seidel; 
> [email-masked]<mailto:[email-masked]
> >
> Subject: Re: [alto] Interop test
>
> Interesting point!  RFC 7285 does NOT require cost metrics -- 
> numerical or ordinal -- to follow the requirements for a formal 
> metric. Other than the values must be non-negative.
>
> In particular, there is no requirement that d(x,x) = 0, or that d(x,y) 
> = 0 iff x = y.
>
> Costs are directed, so symmetry isn't even appropriate.
>
> I guess I would expect a numeric metric to follow the triangle 
> inequality, more or less, but there is no formal requirement for it do so.
>
> Incidentally, for ordinal mode costs, the values are only comparable 
> to other costs in the same request. In other words, if an ordinal cost 
> in a filtered cost map is 0, that just means it is the lowest cost for 
> the set of sources & destinations you requested. It is NOT the lowest 
> cost for the full map.
>
>                 - Wendy Roome
>
>
> From: "Bertz, Lyle T [CTO]"
> <[email-masked]<mailto:[email-masked]>>
> Date: Fri, May 29, 2015 at 15:21
> To: Wendy Roome
> <[email-masked]<mailto:[email-masked]>>, "Y. 
> Richard Yang" <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>, Hans Seidel 
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]
> g>>
> Subject: RE: [alto] Interop test
>
> I have a much larger question about ordinal rank in 7285, is it the 
> expectation that ordinal ranks are true metrics in practice.  In other 
> words are they or even the original metrics true mathematical metrics, i.e.
> non-negative, have symmetry, coincidence axiom and the triangle inequality.
> Further are they formally ultrametrics or intrinsic?
>
> I only ask because depending on the answer we can add services for max 
> distance, sum distance and the like that apply graph theory to the 
> resulting maps.  Who know, I may even be able to apply my only graph 
> theories to them but I will keep such aspirations low at the moment.
>
>
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for 
> the sole use of the recipient(s). Any use by others is prohibited. If 
> you are not the intended recipient, please contact the sender and 
> delete all copies of the message.
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for 
> the sole use of the recipient(s). Any use by others is prohibited. If 
> you are not the intended recipient, please contact the sender and 
> delete all copies of the message.
>

--
Richard

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: Wendy Roome <[email-masked]>
Date: Mon, 01 Jun 2015 11:25:35 -0400

Any of those times are fine with me. I plan to be there from Sunday thru
Saturday (when my spouse learned the conference was in Prague, she said I
had two choices: take her there for the full week, or else find a divorce
attorney. :-))

On 06/01/2015, 11:10, "Jan Seedorf" <[email-masked]> wrote:

>Regarding the date/time: the chairs can likely only make it on one of the
>following evenings during the IETF week: MON, WED, THU. We are aiming at
>3-4h. Does that work for the people interested?
>

---

From: Yale <[email-masked]>
Date: Tue, 2 Jun 2015 02:49:59 +0000 (UTC)

Dear Lyle,
It is interesting to see the introduction of requirement on topology information to simplify NFV MANO and VIM decisions. I see either explicit or implicit support of NFV entities in ALTO info resources. If you have some initial results or requirements, it will be cool to know.Aggregation of metrics will be a very interesting capability. I feel that the draft of computing topology compression using PV is also along this direction. A metric can be a higher-than-one dimension vector. Hence, I can see the possibility of building hierarchical network graphs in two ways: bottom up, where aggregation of metrics may allow faster computation of the same metric from lower layer pieces; or top down, where lower layer graphs are guided by metrics (e.g. each sub graph has max bounded by half of upper layer). I need to think more about this. Please do share pointers to those of us who are very interested in the topic, if you find pointers.It will be cool to have you in the July interop. Which software does not have bugs :-) Thanks!Richard
    _____________________________
From: Bertz, Lyle T [CTO] <[email-masked]>
Sent: Monday, June 1, 2015 10:39 AM
Subject: Re: [alto] Interop test
To: Y. Richard Yang <[email-masked]>
Cc:  <[email-masked]>, Hans Seidel <[email-masked]>, Wendy Roome <[email-masked]>

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: [email-masked] <[email-masked]> on behalf of Y. Richard Yang <[email-masked]>
Sent: Saturday, May 30, 2015 5:48 AM
To: Bertz, Lyle T [CTO]
Cc: Wendy Roome; [email-masked]; Hans Seidel
Subject: Re: [alto] Interop test

First, answer to Lyle's P.S. question: We are looking at an interop in
the July IETF meeting. Does this work for you? We sure hope that your
team can participate.

I agree that denoting some metrics to be a formal metric is a great
idea. An immediate benefit coming to mind is that it allows
compression, for example, only half of the cost matrix need to
transmitted.

I particularly liked the idea of defining the (network) graph metrics.
Your suggestion  appear to me to have two directions:
(1) still use the cost map framework and defining graph metrics
between pairs of PIDs (i.e., metrics between a pair of nodes in a
graph);
(2) provide overall network (graph) properties; that is, provide
summary properties of the overall network topology (periphery comes to
mind).

I can see a unifying framework such as there is a hierarchy of network
graphs, and at each level, one can define properties on a network node
or a pair of nodes. Assume the highest level is a single node
representing the overall topology, and then such a compound node can
have properties such as center/periphery).

Thanks!

Richard

On 5/29/15, Bertz, Lyle T [CTO] <[email-masked]> wrote:
> Wendy,
>
>
>
> I worked on asymmetric distance theory in graphs - specifically max distance
> and sum distance so I can definitely say the asymmetry is not an issue and
> distance is defined at the minimum value of the directed distance from u to
> v or v to u.
>
>
>
> general we would not measure distance between x1 and x2 but but merely talk
> about periphery elements as 'x'.  Precision is a whole other matter as
> well.
>
>
>
> These metrics and definitions are used quite often in computing edge of
> networks, how to merge two networks together, Steiner cut selections, etc.
> Periphery is the most interesting as it tells a lot about the status of node
> traffic and hints for placement, e.g. nfv instance selection in MANO when
> implementing a VNF FG - I could see that being useful for both client and
> servers.
>
>
>
> Lyle
>
>
>
> I haven't used metric spaces since the days of keypunches, so it took a
> while to blow the cobwebs out of that memory bank. :-)
>
> * A true metric d(x,y) must be defined for all x & y. ALTO does not require
> that the cost be defined for all pairs.
>
> * For a metric, d(x,y) = 0 means x = y. We *might* be able to define ALTO
> costs so that is possible, but I have my doubts.
>
> tempting requirement, and I cannot think of an obvious counter example. But
> I doubt that would help without the other requirements.
>
> mathematical metric. But we could define a particular cost as satisfying
> those rules, and (say) identify it in the IRD.  Can you explain how that
> would benefit clients or servers? One obvious advantage is that the cost
> matrix could be smaller, because its symmetric and the center diagonal is
> 0.
>
> - Wendy Roome
>
> <[email-masked]<mailto:[email-masked]>>, "Y. Richard
> Yang" <[email-masked]<mailto:[email-masked]>>
> <[email-masked]<mailto:[email-masked]>>
> Without formal metric compliance though there are a lot of algorithms that
> could not be reliably applied.  I think we should consider this as we move
> forward in developing ALTO.  It may be worthwhile to clarify matters in a
> future update.
>
> [email-masked]<mailto:[email-masked]>
> Interesting point!  RFC 7285 does NOT require cost metrics -- numerical or
> ordinal -- to follow the requirements for a formal metric. Other than the
> values must be non-negative.
>
> In particular, there is no requirement that d(x,x) = 0, or that d(x,y) = 0
> iff x = y.
>
> I guess I would expect a numeric metric to follow the triangle inequality,
> more or less, but there is no formal requirement for it do so.
>
> Incidentally, for ordinal mode costs, the values are only comparable to
> other costs in the same request. In other words, if an ordinal cost in a
> filtered cost map is 0, that just means it is the lowest cost for the set of
> sources & destinations you requested. It is NOT the lowest cost for the full
> map.
>
>                 - Wendy Roome
>
>
> <[email-masked]<mailto:[email-masked]>>, "Y. Richard
> Yang" <[email-masked]<mailto:[email-masked]>>
> <[email-masked]<mailto:[email-masked]>>
> expectation that ordinal ranks are true metrics in practice.  In other words
> are they or even the original metrics true mathematical metrics, i.e.
> distance, sum distance and the like that apply graph theory to the resulting
> maps.  Who know, I may even be able to apply my only graph theories to them
> but I will keep such aspirations low at the moment.
>
>
>
> This e-mail may contain Sprint proprietary information intended for the sole
> use of the recipient(s). Any use by others is prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies of the
> message.
>
> This e-mail may contain Sprint proprietary information intended for the sole
> use of the recipient(s). Any use by others is prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies of the
> message.
>

--
Richard

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Hans Seidel <[email-masked]>
Date: Tue, 02 Jun 2015 09:00:09 +0200

Richard

On 29.05.2015 20:24, Y. Richard Yang wrote:
>
>
> On Saturday, May 30, 2015, Wendy Roome <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I thought RFC 7285 required order-consistency between numerical &
>     ordinal modes for the same metric. But I cannot find that
>     requirement. Too bad! I would have added that if I realized it
>     wasn't there.
>
>
> I remembered that the removal of the consistency requirement was a 
> conscious decision, not an omission, to reduce the load of consistency 
> checking. I buy your point below of a server supporting only one, in 
> the sense of providing the maximum allowed by the privacy concern.
>
> Regarding supporting both in the interop, I will be happy to wait a 
> bit to hear others' opinions.

I agree that providing both numerical and ordinal mode for the same cost 
metric makes little sense from a real world perspective. For the 
interop, I think both should be covered. Since Wendy already proposed 
cost maps for routingcost and hopcount in her initial mail, I suggest 
providing a numerical cost map for one metric and an ordinal for the other.

Hans

>
> Richard
>
>
>     But if we take off our lawyer hats, and look at RFC 7285 as an
>     agreement between friends, rather than a formal contract between
>     adversaries, then I think it is reasonable to say that if the
>     ordinal mode costs do not preserve the order of the numerical
>     costs, then that server is wrong.
>
>     Similarly, a router is allowed to drop packets, and I do not think
>     there is any formal requirement that it cannot drop *every*
>     packet. So theoretically you could glue eight jacks to a block of
>     hardwood and market it as a router. Maybe you could avoid getting
>     charged for fraud. Just don't expect anyone to buy more than one! :-)
>
>     And looking at it from a real-world perspective, the whole concept
>     is irrelevant. The only reason for defining ordinal mode is to
>     allow a server to hide the numerical costs. For example, if the
>     numerical costs to three PIDs are 10, 11 and 100, a client can
>     deduce that the middle pid is close. If the costs are 10, 99 and
>     100, a client can deduce that the middle pid is distant. If the
>     ordinal costs are 1,2,3, a client cannot deduce anything other
>     than 1 is better than 2 is better than 3.
>
>     So if a server offers numerical costs, there is no advantage for
>     it to also offer ordinal mode costs.
>
>     And if numerical costs are available, there is no advantage to a
>     client to use ordinal costs. Maybe if the client could assume the
>     ordinal costs are 1,2,3,… -- but the client cannot.
>
>     So in practice, no server will offer both numerical & ordinal mode
>     for the same metric.
>
>     That means a formal compliance test should only require one mode
>     or the other, but not both. However, keep the interop simple,
>     unless someone objects, I suggest we require both modes.
>
>     - Wendy
>
>     From: "Y. Richard Yang" <[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>     Date: Fri, May 29, 2015 at 12:24
>     To: Wendy Roome <[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>     Cc: "[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "Bertz, Lyle T
>     [CTO]" <[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Hans
>     Seidel <[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>>,
>     "[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>"
>     <[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>         and it can verify that ordinal cost values are consistent with
>         the order of the known numerical values.
>
>
>     This is a reasonable validation. An issue is that RFC7285
>     specifies only that "An ALTO server MUST support at least one of
>     the following modes:  numerical and ordinal." I believe that
>     RFC7285 chose to not specify the consistency between the two
>     modes. Hence, this is beyond compliance, right? Hence, I feel that
>     separating RFC7285-conforming and beyond can be helpful.
>
>
>
> -- 
> Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 2 Jun 2015 04:12:46 -0400

On Tuesday, June 2, 2015, Hans Seidel <[email-masked]> wrote:

> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> ordinal modes for the same metric. But I cannot find that requirement. Too
>> bad! I would have added that if I realized it wasn't there.
>>
>
> checking. I buy your point below of a server supporting only one, in the
> sense of providing the maximum allowed by the privacy concern.
>
>  Regarding supporting both in the interop, I will be happy to wait a bit
> to hear others' opinions.
>
>
> metric makes little sense from a real world perspective. For the interop, I
> think both should be covered. Since Wendy already proposed cost maps for
> routingcost and hopcount in her initial mail, I suggest providing a
> numerical cost map for one metric and an ordinal for the other.
>

 This proposal makes sense to me. I support it.

Richard

>> adversaries, then I think it is reasonable to say that if the ordinal mode
>> costs do not preserve the order of the numerical costs, then that server is
>> wrong.
>>
>> there is any formal requirement that it cannot drop *every* packet. So
>> theoretically you could glue eight jacks to a block of hardwood and market
>> it as a router. Maybe you could avoid getting charged for fraud. Just don't
>> expect anyone to buy more than one! :-)
>>
>>  And looking at it from a real-world perspective, the whole concept is
>> irrelevant. The only reason for defining ordinal mode is to allow a server
>> to hide the numerical costs. For example, if the numerical costs to three
>> PIDs are 10, 11 and 100, a client can deduce that the middle pid is close.
>> If the costs are 10, 99 and 100, a client can deduce that the middle pid is
>> distant. If the ordinal costs are 1,2,3, a client cannot deduce anything
>> other than 1 is better than 2 is better than 3.
>>
>>  So if a server offers numerical costs, there is no advantage for it to
>> also offer ordinal mode costs.
>>
>>  And if numerical costs are available, there is no advantage to a client
>> to use ordinal costs. Maybe if the client could assume the ordinal costs
>> are 1,2,3,… -- but the client cannot.
>>
>>  So in practice, no server will offer both numerical & ordinal mode for
>> the same metric.
>>
>>  That means a formal compliance test should only require one mode or the
>> other, but not both. However, keep the interop simple, unless someone
>> objects, I suggest we require both modes.
>>
>>  - Wendy
>>
>>  From: "Y. Richard Yang" <[email-masked]>
>> To: Wendy Roome <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>, "Bertz, Lyle T [CTO]" <
>> [email-masked]>, Hans Seidel <[email-masked]>, "
>> [email-masked]" <[email-masked]>
>>>  and it can verify that ordinal cost values are consistent with the
>>> order of the known numerical values.
>>>
>>
>>  This is a reasonable validation. An issue is that RFC7285 specifies
>> only that "An ALTO server MUST support at least one of the following modes:
>>  numerical and ordinal." I believe that RFC7285 chose to not specify the
>> consistency between the two modes. Hence, this is beyond compliance, right?
>> Hence, I feel that separating RFC7285-conforming and beyond can be helpful.
>>
>
>
> --
> Richard
>
>
>

-- 
Richard

---

From: Wendy Roome <[email-masked]>
Date: Tue, 02 Jun 2015 10:17:46 -0400

I suggest a slightly different approach: we specify the numerical values for
routingcost & hopcount. Then let each server decide whether it wants to
present numerical or ordinal versions. The only requirement is that a server
MUST provide a routingcost cost map, either numerical or ordinal. Servers
can provide whatever additional resources they want, and clients can fetch &
validate any resources they recognize.

We do not define ordinal values, but allow servers to assign whatever values
they want as long as the ordering is consistent with the numerical values we
specify. That is sufficient to allow a client to verify the ordinal values.

- Wendy Roome

From:  Hans Seidel <[email-masked]>
Date:  Tue, June 2, 2015 at 03:00
To:  "Y. Richard Yang" <[email-masked]>
Cc:  Wendy Roome <[email-masked]>, "Bertz, Lyle T [CTO]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [alto] Interop test

On 29.05.2015 20:24, Y. Richard Yang wrote:
> On Saturday, May 30, 2015, Wendy Roome <[email-masked]> wrote:
>> I thought RFC 7285 required order-consistency between numerical & ordinal
>> modes for the same metric. But I cannot find that requirement. Too bad! I
>> would have added that if I realized it wasn't there.
> 
> I remembered that the removal of the consistency requirement was a conscious
> decision, not an omission, to reduce the load of consistency checking. I buy
> your point below of a server supporting only one, in the sense of providing
> the maximum allowed by the privacy concern.
> 
> Regarding supporting both in the interop, I will be happy to wait a bit to
> hear others' opinions.

Hans

---

From: 郭华明 <[email-masked]>
Date: Wed, 3 Jun 2015 09:10:21 +0800 (GMT+08:00)

I think that we just specify the numerical & ordinal values for routingcost cost map, then let each server decide whether it wants to present numerical or ordinal versions. The hopcount cost map is no need to specify, as it is not a MUST in
RFC 7285.

-----原始邮件-----
发件人:"Wendy Roome" <[email-masked]>
发送时间:2015-06-02 22:17:46 (星期二)
收件人: "Hans Seidel" <[email-masked]>, "Y. Richard Yang" <[email-masked]>
抄送: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
主题: Re: [alto] Interop test

I suggest a slightly different approach: we specify the numerical values for routingcost & hopcount. Then let each server decide whether it wants to present numerical or ordinal versions. The only requirement is that a server MUST provide a routingcost cost map, either numerical or ordinal. Servers can provide whatever additional resources they want, and clients can fetch & validate any resources they recognize.

We do not define ordinal values, but allow servers to assign whatever values they want as long as the ordering is consistent with the numerical values we specify. That is sufficient to allow a client to verify the ordinal values.

- Wendy Roome

Cc: Wendy Roome <[email-masked]>, "Bertz, Lyle T [CTO]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

I thought RFC 7285 required order-consistency between numerical & ordinal modes for the same metric. But I cannot find that requirement. Too bad! I would have added that if I realized it wasn't there.

I remembered that the removal of the consistency requirement was a conscious decision, not an omission, to reduce the load of consistency checking. I buy your point below of a server supporting only one, in the sense of providing the maximum allowed by the privacy concern.

Regarding supporting both in the interop, I will be happy to wait a bit to hear others' opinions.
I agree that providing both numerical and ordinal mode for the same cost metric makes little sense from a real world perspective. For the interop, I think both should be covered. Since Wendy already proposed cost maps for routingcost and hopcount in her initial mail, I suggest providing a numerical cost map for one metric and an ordinal for the other. 

Hans

--

----------------
Best!

Huaming Guo

China Academy of Information and Communications Technology (CAICT)

No.36 A Nanlishi Road, Xicheng District, Beijing 100037, China