Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map

From: Wendy Roome <[email-masked]>
Date: Thu, 25 Jul 2013 10:09:28 -0400

Don't both approaches mean that when given a GET request for the same URI,
the ALTO server will return different content depending on the client's IP
address?

Isn't that potentially dangerous and confusing? In particular, won't that
cause problems if the request goes through a caching proxy?

Also, I thought one of the tenants of RESTful design was that the content
of a resource depends on the URI,  and not on hidden background
information.

	- Wendy Roome

>Date: Wed, 24 Jul 2013 20:48:59 +0200
>From: Sebastian Kiesel <[email-masked]>
>Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map
>
>Hi Richard,
>
>On Wed, Jul 24, 2013 at 01:57:31PM -0400, Y. Richard Yang wrote:
>>Hi Sebastian,
>>On Wed, Jul 24, 2013 at 11:33 AM, Sebastian Kiesel
>><[email-masked]>wrote:
>>> I don't think we need an extension to the discovery procedure for that.
>>> As I said, I think it would just shift the problem, not solve it.
>>>
>>> In a deployment scenario where a network operator actually can clearly
>>> decide that some group of hosts "A" should use map_A as default
>>> (unless they know better and want to override it) and group "B" should
>>> use map_B, they can configure two IRDs, e.g.
>>> altoserver.isp.example/A/ird  and altoserver.isp.example/B/ird
>>> and let the discovery procedure return the right URI for the each
>>> group member.
>>>
>>> Then, the altoserver.isp.example/A/ird  must express that map_A is
>>> the default map for all clients that have discovered this IRD.
>>> The ALTO protocol must provide the possibility to express that.
>>>
>>>
>>I see two ways to express this in the ALTO protocol (not through another
>>configuration channel):
>>(1) prune: delete map_B from the IRD given to hosts "A", and delete map_A
>>from the IRD given to hosts "B". This assumes that each hosts group needs
>>only one map, e.g., a fish-eye map for each of the two coasts.
>>(2) mark one as the default, which I believe that we will add as a
>>consensus on the mailing list. In other words, the IRD page is still
>>dynamic, depending on the receiver.
>>Which approach to take will then be a deployment's decision.
>
>I support adding the neccessary protocol elements needed to
>support (2).
>
>Speaking of dynamically generated IRDs: how would the ALTO server
>identify the client in order to generate an IRD specifically for it?
>
>This could be done based on the source IP address of the HTTP
>connection, or based on an X-Forwarded-For header in HTTP.  But how
>would we do that in the third-party use case, e.g., if a P2P tracker
>issues ALTO queries on behalf of (topologically distant) resource
>consumers? Is there a way to explicitly tell the resource consumer's
>ID/IPaddress when requesting an IRD?
>
>Sebastian

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 25 Jul 2013 16:58:28 +0100

Wendy,

> cause problems if the request goes through a caching proxy?

No more than existing dynamic web pages etc.

If the server is returning a different set of HTTP headers/body based on some characteristic of the client that the server needs to ensure it does that in a clean/consistent way. That's not really different to the deployment of an HTTP website or API.

Possible options for the server could include making ALTO responses not cacheable or using a Vary header.

> of a resource depends on the URI,  and not on hidden background

I don't think that's right. Individual resources are identified by a URI but a server is free to return different representations of the same resource. Ultimately how the server chooses to decide which representation to return is up to the server (see RFC2616 Sec 12.1 - Server-driven Negotiation).

When folks talk about representations they often have a picture in mind of different "formats"/media-types, e.g. an underlying resource may be returned to a User Agent in an XML representation or a JSON representation, but no such constraint exists in the HTTP protocol. Different representations could also be the same underlying photographic image at different resolutions or an ALTO map at different levels of granularity for example.

What I think you may be getting confused with is that in a RESTful system the *client* shouldn't need to guess anything (using hidden information) to parse or manipulate resources on the server and the server should not store client session state. If an ALTO server can serve up different ALTO maps to different clients consistently without having to store session state for the client on the server then serving different representation to different clients doesn't break the principles of REST IMO.

Ben

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