Subject: Re: [alto] Equivalence of various identifiers from an ALTO Server

From: Wendy Roome <[email-masked]>
Date: Fri, 17 May 2013 09:19:40 -0400

I'd make an even stronger statement: a client MUST NOT compare ordinal
costs between different response messages, even from the same service. A
client MAY compare one ordinal value against another ordinal in the same
response, but that's all.

For example, suppose a client fetches a full ordinal cost map twice in
close succession. The ordinal values in the second response may be
completely different from those in the first response, even if there was
no change in underlying network performance.

Put it another way: When a client requests an ordinal cost mode, the ALTO
Server MAY apply a non-linear order-preserving transformation to the
underlying numerical costs, and that transform MAY vary from request to
request.

IHMO, I thought the reason for defining ordinal costs was to allow an ALTO
server to obfuscate the underlying numerical costs. So if the server was
really paranoid, and will to expend the cycles, it might very well use a
different obfuscation algorithm for each request.

	- Wendy Roome

>Date: Thu, 16 May 2013 21:51:30 +0100
>From: Ben Niven-Jenkins <[email-masked]>
>Subject: Re: [alto] Equivalence of various identifiers from an ALTO
>	Server
>
>(BTW I'm not sure you can compare a filtered costmap against a full cost
>map if the costs are ordinal)
>
>Ben

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 17 May 2013 15:42:41 -0400

On Fri, May 17, 2013 at 9:19 AM, Wendy Roome <[email-masked]>wrote:

> costs between different response messages, even from the same service.

This allows better better concurrency and should be clarified.

> A

Why add a MAY? The current wording (Sec. 6.2) is "If the Cost Mode is
'ordinal', the Path Cost of each communicating pair is relative to the m*n
entries."  In other words, a response returns m*n entries, where each entry
is a number (ranking). The current spec does not specify that the m*n
numbers are distinct, and hence the response may contain entries with the
same value. Consider an example of two two sources (S1, S2) and three
destinations (D1, D2, D3), and a response as the following:

S1 -> D1: 1
S1 -> D2: 2
S1 -> D3: 2
S2 -> D1: 1
S2 -> D2: 2
S2 -> D3: 3

The interpretation is (~ means equivalent):
S1 -> D1 ~ S2 -> D1
<
S1 -> D2 ~ S1 -> D3 ~ S2 -> D2
<
S2 -> D3

In other words, it defines a partial ordering. Is this what you are
referring to in terms of MAY?

Richard

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

---

From: Wendy Roome <[email-masked]>
Date: Fri, 17 May 2013 15:54:38 -0400

By "MAY", all I meant was that "We won't insist that the client compare the
values against each other." After all, a client might just print them, as I
think the bake-off clients did.

s/MAY/may/   :-)

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Fri, May 17, 2013 15:42
To:  Wendy Roome <[email-masked]>
Cc:  IETF ALTO <[email-masked]>
Subject:  Re: [alto] Equivalence of various identifiers from an ALTO Server

S1 -> D1: 1
S1 -> D2: 2
S1 -> D3: 2
S2 -> D1: 1
S2 -> D2: 2
S2 -> D3: 3

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 17 May 2013 16:12:51 -0400

On Fri, May 17, 2013 at 3:54 PM, Wendy Roome <[email-masked]>wrote:

> By "MAY", all I meant was that "We won't insist that the client compare
> the values against each other." After all, a client might just print them,
> as I think the bake-off clients did.
>
> s/MAY/may/   :-)
>

Sounds good. Will take the input if no objections from others.

Thanks.
Richard