Rich, On 27 Jun 2011, at 19:11, Richard Alimi wrote: > On Mon, Jun 27, 2011 at 7:00 AM, Bill Roome <[email protected]> > wrote: >> 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"). > > 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.
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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
