Re: [alto] Comments in 3.1.4. Re: I-D Action: draft-ietf-alto-reqs-11.txt

[Sebastian Kiesel <[e-mail]>]

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