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

From: Richard Alimi <[email-masked]>
Date: Wed, 15 May 2013 09:45:48 -0700

One question that Wendy brought up was: "if one resource directory can
refer to a different resource directory which may live at a different
server or administrative domain, when is it safe for an ALTO Client to
conclude that a cost metric means the same thing?" A particular example
here is the full cost map and filtered cost map.  If the client fetched the
full cost map with the 'routingcost' cost metric, and then later wanted to
use a more refined query, then presumably the client should be able to
assume that the values in the filtered cost map (also with the
'routingcost' cost metric) mean the same thing.

A similar thing holds for version tags.  If the client finds a cost map
with version tag '1234', under what conditions should it declare that it
matches the version tag for a particular network map?  Similar to the cost
map example above, both may come from a different server or administrative
domain.

To resolve this ambiguity, we are proposing to add the following to Section
8.3.1:

"The meanings of identifiers used in resources discovered via an entry
point to an ALTO Server (i.e., by the ALTO Discovery Protocol) SHOULD be
consistent with each other. In particular, a particular values for a
different cost maps of the same cost metric should be comparable, and the
version tag for a cost map should be comparable to the version tag for the
network map on which it was based, even if the two maps are provided by a
different server."

I hope the intent here is clear.  Admittedly, this is probably not a crisp
enough statement to put in the draft yet, but suggestions on improving it
would be appreciated.

Thanks,
Rich

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 May 2013 21:51:30 +0100

Can we mandate the vtag has the equivalent properties of a strong etag in HTTP? i.e. if an alto service is provided by multiple servers then those servers must ensure that vtags are consistent across servers/versions?

If not we could have the equivalent of weak and strong vtags and in the case of weak the client would expect the same server (IP & port) to return consistent vtags but if it connected to another server it would have to re-retrieve the entire cost map if it wanted to compare it to a filtered cost map from the same (2nd) server. 

(BTW I'm not sure you can compare a filtered costmap against a full cost map if the costs are ordinal)

Ben

On 15 May 2013, at 17:45, Richard Alimi <[email-masked]> wrote:

> One question that Wendy brought up was: "if one resource directory can refer to a different resource directory which may live at a different server or administrative domain, when is it safe for an ALTO Client to conclude that a cost metric means the same thing?" A particular example here is the full cost map and filtered cost map.  If the client fetched the full cost map with the 'routingcost' cost metric, and then later wanted to use a more refined query, then presumably the client should be able to assume that the values in the filtered cost map (also with the 'routingcost' cost metric) mean the same thing.
> 
> A similar thing holds for version tags.  If the client finds a cost map with version tag '1234', under what conditions should it declare that it matches the version tag for a particular network map?  Similar to the cost map example above, both may come from a different server or administrative domain.
> 
> To resolve this ambiguity, we are proposing to add the following to Section 8.3.1:
> 
> "The meanings of identifiers used in resources discovered via an entry point to an ALTO Server (i.e., by the ALTO Discovery Protocol) SHOULD be consistent with each other. In particular, a particular values for a different cost maps of the same cost metric should be comparable, and the version tag for a cost map should be comparable to the version tag for the network map on which it was based, even if the two maps are provided by a different server."
> 
> I hope the intent here is clear.  Admittedly, this is probably not a crisp enough statement to put in the draft yet, but suggestions on improving it would be appreciated.
> 
> Thanks,
> Rich
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

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

On Thu, May 16, 2013 at 4:51 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> Can we mandate the vtag has the equivalent properties of a strong etag in
> HTTP? i.e. if an alto service is provided by multiple servers then those
> servers must ensure that vtags are consistent across servers/versions?
>

A problem I see is how to indicate to an ALTO Client the set of servers
that are consistent: Because they are linked in one entry of one IRD, have
the same DNS prefix (security problem?), signed using the same certificate,
...?

Any thought?

Richard

> If not we could have the equivalent of weak and strong vtags and in the
> case of weak the client would expect the same server (IP & port) to return
> consistent vtags but if it connected to another server it would have to
> re-retrieve the entire cost map if it wanted to compare it to a filtered
> cost map from the same (2nd) server.
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 18 May 2013 10:29:19 +0100

I think that's a deployment decision. Hostname+Port would be a reasonable suggestion for a starting/default position IMO (i.e load balanced servers must be consistent and an implementation may want to offer the ability to relax that to domain prefix or something else). Ben

On 17 May 2013, at 20:47, "Y. Richard Yang" <[email-masked]> wrote:

> 
> On Thu, May 16, 2013 at 4:51 PM, Ben Niven-Jenkins <[email-masked]> wrote:
> A problem I see is how to indicate to an ALTO Client the set of servers that are consistent: Because they are linked in one entry of one IRD, have the same DNS prefix (security problem?), signed using the same certificate, ...? 
> 
> Any thought?
>  
> Richard
> 
>>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 18 May 2013 09:15:49 -0400

On Saturday, May 18, 2013, Ben Niven-Jenkins wrote:

> I think that's a deployment decision. Hostname+Port would be a reasonable
> suggestion for a starting/default position IMO (i.e load balanced servers
> must be consistent
>

Agreed. Load balanced servers with the same dns name + port should give
out consistent tag, as these servers are supposed to be indistinguishable.

> and an implementation may want to offer the ability to relax that to
> domain prefix or something else).
>

The current spec does not explicitly specify such a relaxation. When you
say deployment, you mean that a given set of clients and servers agree, out
of ALTO protocol such as using configuration files or hard coding, on the
relaxation. Right? There can be mechanisms that can be introduced to
ALTO to explicitly convey relaxation policies, e.g., announcement in
IRD meta (Wendy suggested adding a "consistent-with" attribute to indicate
such "relaxation"), but I feel that this should be left to future work.
Agree?

Thanks a lot!

Richard

> Ben
>
> On 17 May 2013, at 20:47, "Y. Richard Yang" <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
> wrote:
>
>
> On Thu, May 16, 2013 at 4:51 PM, Ben Niven-Jenkins <
> [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>> wrote:
>
>> On 15 May 2013, at 17:45, Richard Alimi <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
>> wrote:
>>
>> I hope the intent here is clear.  Admittedly, this is probably not a
>> crisp enough statement to put in the draft yet, but suggestions on
>> improving it would be appreciated.
>>
>> Thanks,
>> Rich
>>
>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>