Hi Ben,
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Ben Niven-Jenkins > Sent: Wednesday, May 11, 2011 7:28 PM > To: Richard Alimi > Cc: [email protected] > Subject: Re: [alto] category of resource/consumer (was: Comments on > draft-ietf-alto-reqs-08) > > Rich, Martin, > > Please see inline. > > On 11 May 2011, at 16:44, Richard Alimi wrote: > > > Comment inline with most of the textual discussion omitted... > > > > On Wed, May 11, 2011 at 1:44 AM, Martin Stiemerling > > <[email protected]> wrote: > > > > ... > > > >>> > >>> I can see that an ALTO server may want to return different > responses > >>> depending on the category of resource (or possibly more precisely > the > >>> category of consumer) and we don't want to preclude that, e.g. > >>> returning a different response to a P2P client than it would to a > CDN. > >> > >> The assumption until now was really focused on the p2p use case and > not on the CDN use case. However, I can see that in the CDN use case, > an ALTO server may return a different response for CDN. For P2P on the > other hand, we definitely do not want to identify the resource > category. > >> > >> Adding the possibility to identify the category of resource to the > ALTO requirements would require a WG consensus IMHO. > >> > >> The requirements would read along these lines: > >> (a) that the ALTO protocol MUST NOT require the specific resource to > be accessed to be included in ALTO requests. > >> (b) that the ALTO protocol SHOULD allow to specify the resource to > be accessed to be included in ALTO requests. > >> > >> (a) rules out the requirement to have it in all requests, while (b) > allows the protocol to have such a capability. > > > > For the sake of completeness, I'll offer another one which was demoed > > (by Juniper) in the running code show. They allowed an ALTO Server to > > internally contain multiple "views" (read: set of maps), and it would > > serve maps based on the requesting client. The client could be > > determined by requesting IP address, supplied credentials, additional > > HTTP headers, etc. This avoids us defining any additional > > identifiers, or classifying applications into any particular types in > > the protocol specification. > > > > An early implementation of the P4P work used multiple views which > were > > advertised by the server. It was up to the client to determine > > whether they wished the default one, or wished to select a different > > one. > > Before we go to far down the line of resource identifiers I think > Martin may have misinterpreted what I meant slightly. > > I was never thinking about including resource identifiers in ALTO. I > was thinking of the multiple views scenario described above, e.g. an > ALTO server "knows" (somehow) the client is a P2P client and gives it > the P2P map which may expose different costs between the same endpoints > (or even different sets of end points) to the CDN map for example. > > I see know need to include categories of individual resources, but > returning different maps based on the category of client/consumer (e.g. > P2P client or CDN client, etc.) should not be precluded. Having said > that I don't think that the category of resource client needs including > in the protocol either. Ah, ok. This looks different :) There is nothing which precludes any operational detail of the ALTO server in the back end, i.e., the requirements and the protocol are only about the communication between the ALTO client and the ALTO server. We do not specify how the data (e.g., IP addresses, topology data, etc) is process on either end (client or server). > > I do think the original wording of the requirement could be improved > though. Any text suggestion? > > Apologies for sending you off on a tangent. Don't mind :) Martin [email protected] NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
