Re: [alto] Interop test

Hans Seidel <hseidel@...>


On 29.05.2015 20:24, Y. Richard Yang wrote:

On Saturday, May 30, 2015, Wendy Roome <w.roome@...> 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.



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" <yry@...>
Date: Fri, May 29, 2015 at 12:24
To: Wendy Roome <w.roome@...>
Cc: "alto@..." <alto@...>, "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@...>, Hans Seidel <hseidel@...>, "alto-dev@..." <alto-dev@...>
Subject: Re: [alto] Interop test

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.


Join to automatically receive all group messages.