Subject: [alto] Questions about ordinals & properties

From: Bill Roome <[email-masked]>
Date: Mon, 27 Jun 2011 10:00:43 -0400

Draft 8 says this about ordinal costs:

5.1.2.2. Cost Mode: ordinal
  This Cost Mode is indicated by the string ¹ordinal¹. This mode
  indicates that the costs values to a set of Destination Network
  Locations from a particular Source Network Location are a ranking,
  with lower values indicating a higher preference.

But does that mean ordinals MUST be the integers 1, 2, 3, etc? Or can they
be any non-negative values, and lower means higher rank?

My concern is that a server might assume the latter. Then for simplicity,
if a client asks for "ordinal" costs, the server could just return the
numerical costs, with mode declared as "ordinal."

But a client might assume "ordinal" always means 1,2,3..., and might
search through the response to find the best cost -- which must be "1",
obviously.

So I think the protocol spec should say either

(a) Ordinals can be any non-negative values; they need not be the integers
1, 2, 3, ....

or else explicitly require

(b) Ordinals must be the integers 1, 2, 3, ....

I prefer (a) because it's simpler for the server, and because with (b),
we'd then have to define how to handle ties. Eg, is it "1,1,2", or
"1,1,3", or "1,2,3"?  (Last means "ties not allowed").

    -----

Draft 8 says this about the parameters for the endpoint property service:

    7.7.4.1.3. Input Parameters
        object {
            EndpointProperty properties<0..*>;
            TypedEndpointAddr endpoints<0..*>;
        } ReqEndpointProp;

I assume "properties<0..*>" means the property names are optional. In that
case should the server return all props for those endpoints? Or is that an
error?

I believe "endpoints<0..*>" is a typo, and should be "endpoints<1..*>".

	- Bill Roome

---

From: Richard Alimi <[email-masked]>
Date: Mon, 27 Jun 2011 11:11:39 -0700

Hi Bill,

Thanks again for the comments.

> (a) Ordinals can be any non-negative values; they need not be the integers

Agreed that we need to be more specific here, and I would agree that
(a) would be better.  In particular, it should be reasonable for the
clients to resolve ties. Then, if a server wishes to use a
load-balancing technique, it can assign equivalent ranks to multiple
destinations from a single source, and then that response can still be
cached via normal mechanisms; the server doesn't need to regenerate
responses to load-balance within the requirement of unique ordinal
values.

Any objections to this?

> I believe "endpoints<0..*>" is a typo, and should be "endpoints<1..*>".

Yes - this is something that is going to be in the next revision of
the document. We intend to get the updated version together at some
point today.

Thanks,
Rich

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 27 Jun 2011 13:16:04 -0500

As individual ...

> responses to load-balance within the requirement of unique ordinal

No, sounds reasonable.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 27 Jun 2011 21:59:10 +0100

Rich,

> responses to load-balance within the requirement of unique ordinal

At the same time I think it is worth being explicit that the ranking provided by ordinal costs does in fact allow results to include multiple equal ranks. I had (incorrectly until I was speaking with some folks the other day) assumed otherwise.

Ben

---

From: Richard Alimi <[email-masked]>
Date: Mon, 27 Jun 2011 14:04:22 -0700

Hi Ben,

> At the same time I think it is worth being explicit that the ranking provided by ordinal costs does in fact allow results to include multiple equal ranks. I had (incorrectly until I was speaking wi…

Yes - the intent was to explicitly say so in the document (assuming no
objections / discussion from others).

Rich