Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Narayanan, Vidya wrote:
> I am surprised to see that ALTO is being proposed for a WG after the
> last BoF concluded with no consensus whatsoever.  I think a second 
> BoF is more appropriate than a WG on the topic at this time.  That 
> said, I do see the need for this work, although I have some comments
> on the current direction.

Vidya: Thank you for the feedback.  After analyzing your points,
it seems that the charter as written is already conducive to
the important points raised in your review of it (i.e., we may
already be in agreement.)

More inline.

> Overall, I think we should work with the notion of an ALTO "service"
>  rather than specifically an ALTO "server".

Great.  I believe that is exactly what the charter does;  the
charter talks in terms of an "ALTO service" at many places
(pedantically speaking, the term "ALTO service" occurs eight
times and the term "ALTO server" occurs six.)  The ALTO "server"
mentioned in the charter refers to the *host* the client
finally queries (calling it a "peer" is ambiguous; if you have
a specific term to use here instead of "server", please do let
us know.)

> The ALTO service may be provided by a server, a cluster of 
> distributed servers or as a service in an overlay.  Although some of 
> the charter wording talks about a "service" rather than a "server", 
> there is enough mention of a "server" entity to imply a strict 
> client-server protocol.

The charter is not meant to imply a centralized architecture, nor to
rule out peer-to-peer implementations of it.  The charter simply
mentions a "request/reply" protocol is needed.  Whether or not
there is a cluster of ALTO servers or one needs to be decided by
the requirement analysis and subsequent discussions in the WG.

> As part of that, I think there are a couple of key things that need 
> to be addressed here:
> 
> - A protocol that allows peers (or ALTO clients) to publish 
> information about themselves as part of the ALTO service.  An example
> of such information may be the uplink/downlink bandwidth of the 
> peer.

We have had discussions on the mailing list about this already.
Some people felt that providing uplink bandwidth would not be
a good idea for various reasons running from privacy concerns
to peers skewing traffic in favor of a high uplink bandwidth.
Others felt that even if a peers uplink bandwidth was not
provided, it could calculated nonetheless by other peers.  That
is, there are degrees of disagreement here and consequently,
including a contentious point in the charter would be counter-
productive.

> - The ability to register information types with IANA and extend 
> these.

Having a IANA registry for the information type carried in the
protocol is certainly a possibility the charter does not rule
out, no?

> The request/response protocol should be a generic enough container
> for any information that peers can provide and look for, plus what
> may be available from service providers, etc.  There may be some
> guidelines on how such information types can be registered and we may
> start with default ones.

Exactly; this is what the charter is saying in the paragraph:

   - A document defining core request and response formats and
   semantics to communicate network preferences to applications.
   Since ALTO services may be run by entities with different level
   of knowledge about the underlying network, such  preferences
   may have different representations. Initially the WG will
   consider: IP ranges to prefer and to avoid, ranked lists of
   the peers requested by the client, information about
   topological proximity and approximate geographic locations.
   Other usages will be considered as extensions to the charter
   once the work for the initial services has been completed.

We *are* starting with the default information; as other information
is required, we can extend the charter, right?  Extending the
charter is cheap -- it is a bureaucratic process that will auto-
matically happen if there are enough interested parties willing to
do the work and the work is considered to be important enough.
I believe that the higher bar is ensuring that the initial charter
contains the right amount of work so that the WG can finish it
in an appropriate amount of time.

>> The Working Group will design and specify an Application-Layer 
>> Traffic Optimization (ALTO) service that will provide applications
>>  with information to perform better-than-random initial peer 
>> selection. ALTO services may take different approaches at balancing
>>  factors including maximum bandwidth, minimum cross-domain traffic,
>>  lowest cost to the user, etc.  The WG will consider the needs of 
>> BitTorrent, tracker-less P2P, and other applications, such as 
>> content delivery networks (CDN) and mirror selection.
> 
> What does the above sentence mean? If we are putting such a list 
> together, we must also take into account needs from structured P2P 
> overlays such as those being specified in P2PSIP.

In P2PSIP, the amount of information being stored in the overlay
is small (a R-URI, on the order of tens of bytes.)  ALTO will
not much help there.  OTOH, ALTO will help tremendously if in
a P2PSIP network, there is a need to find a peer that hosts the
recording of a 2-hour conference call.  Nothing in the ALTO
charter prevents this from happening as it is specified today.

> Is this meant to allow for entities such as proxies to be in the 
> path?

There's been quite a lot of discussion on this topic on the list.
Current consensus is to keep the architecture as simple as
possible and exclude at least initially support for non-transparent
intermediaries; if at some point we have evidence of the need
for it, the group will go through rechartering.

> Earlier, it is mentioned that the requirements document will 
> determine the types of information that are useful for P2P 
> applications.  Given that, it seems premature to conclude that the WG
>  should consider the above mentioned parameters.  Also, as I 
> mentioned earlier, I think it is essential to keep the protocol and 
> message formats extensible and allow for exchange of any registered 
> information type.

The limit on what data to consider initially was suggested to
avoid the group to wander for years discussing any kind of
possible information; however, extensibility will be the key
principle in designing a protocol (for good design practices
rather than because it is written in the charter).

> Another question I have is about the assumptions around expected peer
> addressing models.  Some of the above seems to hint at IP addresses 
> - is this an assumption already?

No, the text says "ranked lists of the peers requested by the
client" exactly because we still don't know how they could be
identified.

>> - In order to query the ALTO server, clients must first know one or
>> more ALTO servers that might provide useful information.  The WG 
>> will look at service discovery mechanisms that are in use, or 
>> defined elsewhere (e.g. based on DNS SRV records or DHCP options).
>> If such discovery mechanisms can be reused, the WG will produce a
>> document to specify how they may be adopted for locating such 
>> servers. However, a new, general-purpose service discovery 
>> mechanism is not in scope.
> 
> Alternately, the clients may look for ALTO services within an 
> overlay.  This can be modeled as service discovery within the overlay
> - I'm, however, not suggesting that we take on solutions for that.

OK, good; we do not want to bite more than we can chew.  If a
suitable overlay service discovery mechanism exists, we will
happily use it.

>> When the WG considers standardizing information that the ALTO 
>> server could provide, the following criteria are important to 
>> ensure real feasibility.
>> 
>> - Can the ALTO service technically provide that information?
>> - Is the ALTO service willing to obtain and divulge that
>> information?
>> - Is it information that a client will find useful?
> 
> I'm not sure how useful it is for us to answer this question.  The 
> protocol we develop simply needs to be a container for any 
> information that has a registered type and fits a certain format.

Sure, no disagreements here.  However, the list of questions
that appears in the charter was suggested as a set of minimum
vetting points to ensure that the WG spent some thought process
on making an adequate determination on the importance and use
of an ALTO service.  The list of questions does not inhibit
the protocol we develop in any way.

> If we can build an extensible protocol, we don't need to define all 
> possible kinds of information that get carried in it.

Please see above.

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi