Reinaldo, On Sun, Jul 17, 2011 at 07:17:17PM -0400, Reinaldo Penno wrote: > I have a question on how the requirement below would be operationalized. > > " For example, an > ALTO client could be integrated into the tracker of a tracker- > based P2P application, in order to request ALTO guidance on behalf > of the peers contacting the tracker. > " > > I'm assuming the flow of information is the following: A P2P client contacts > a Tracker. The Tracker (as an ALTO Client) turns around and contacts an ALTO > Server in order to get guidance.
... and then returns a peer list to the requesting P2P client, which is ALTO-biased (e.g., sorted) See page 5 of http://www.ietf.org/proceedings/80/slides/alto-5.pdf for that message flow. > Later in the section is says > > " REQ. ARv11-20: An ALTO client protocol MUST support the mode of > operation in which the ALTO client is embedded in a third party, > which performs queries on behalf of resource consumers." > It is not clear to me that the ALTO Client is performing the query 'on > behalf' of the P2P client. The text says that a third party (i.e., the tracker) performs an ALTO query on behalf of the resource consumer (i.e., the peer). And for doing so, it needs an ALTO client. > If the requirement is written as intended, the > P2P Client needs to pass information to the tracker that needs to be > converted into parameters by the ALTO Client when issuing a query: bandwidth > caps, encryption preference, queue limit, ISP Policies, wireline vs. > wireless preference, etc. One option ... > > Otherwise the third party ALTO Client can at most perform a 'plain' query > and return a cost and network map. See http://tools.ietf.org/html/rfc5632 > where tracker protocol remains the same and all intelligence lives in the > 'ALTO Server' or iTracker. ... the other option. The intelligence could also be in the P2P tracker doing peer pre-selection based on ALTO and other information sources. > Therefore , is it assumed that Tracker protocols will be enhanced to pass > this information? I see reasonable use cases both with and without modifying the peer-tracker protocol. But the peer-tracker protocol is out of the scope of this document, and I think this question has no impact on the ALTO client protocol. The most important implication of this requirement is IMO that there must be a field "resource consumer address" in the ALTO protocol (or maybe in an underlying layer but not the IP source address). > Or the requirement wording should change a bit? How? Thanks, Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
