Wendy, On Friday, May 29, 2015, Wendy Roome <[email protected]<mailto:[email protected]>> wrote: "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! :-)"
I am pretty sure someone has actually tried to sell me one of these and can find it in the lab (but was not the purchaser). To date its loss rate is close to 100%. It is treated more like a very secure firewall than a router and is placed beside a tin pale that is a bit bucket someone purchased long ago. :D On a serious note, I agree with you that only one mode would be supported on the server . Please note that an ordinal ranking of a metric may exist if there are too many entries that have the same value in the original metric. We do this quite often as an operator but we *always* give this metric a different name in order to emphasize the ranking aspect. 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. Lyle PS - Are we looking to perform an interop in July or the next meeting? From: Wendy Roome [mailto:[email protected]] Sent: Friday, May 29, 2015 12:06 PM To: Y. Richard Yang Cc: [email protected]; Bertz, Lyle T [CTO]; Hans Seidel; [email protected] Subject: Re: [alto] Interop test 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. 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 protected]<mailto:[email protected]>> Date: Fri, May 29, 2015 at 12:24 To: Wendy Roome <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Bertz, Lyle T [CTO]" <[email protected]<mailto:[email protected]>>, Hans Seidel <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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. ________________________________ 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.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
