Hi Ben, On Mon, Jun 27, 2011 at 1:59 PM, Ben Niven-Jenkins <[email protected]> wrote: > 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. >
Yes - the intent was to explicitly say so in the document (assuming no objections / discussion from others). Rich > Ben > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
