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

Dear Vijay;

On Oct 10, 2008, at 5:31 PM, Vijay K. Gurbani wrote:

> Marshall Eubanks wrote:
>> I support this moving forward. My reading of the room in Dublin was
>> that there was serious support for this and certainly a critical mass
>> to move forward.
>
> Marshall: Thank you for your review.  More inline.
>
>> Some comments in the charter below. This document clearly needs some
>> more work. As a overall comment, I think it is premature to discuss
>> ALTO "servers" and would keep the charter focused on describing the
>> ALTO "service."
>
> In an earlier reply to Vidya I note that the charter does indeed
> predominantly refer to "ALTO services" over "ALTO server".
> Having said that, if I did not convince you through that
> argument, then we can leave the "s/ALTO server/ALTO service"
> discussion on the table.
>
>> I do not see consensus at this moment as to a central
>> service solution versus a distributed solution.
>
> Agreed.

To me, this agreement answers the previous point. (Servers presupposes  
the answer, service does not IMO.)

>
>
>> s/choose/choose the best peer or peers to exchange data with/
>
> Unfortunately, in the Dublin BoF charter, we did state best peer
> (we had termed it "optimal" peer).  This was one reason for the
> negative hums in the BoF because people have differing notion of
> what an "optimal" (or best) peer is.  Thus, we reverted to the
> non-confrontational use of the phrase that you now see in the
> charter.

OK, but is doesn't read well :

  In
contrast to client/server architectures, P2P applications often have
a selection of peers and must choose.

There is a missing object. How about

must choose one or more peers from this selection.

?
>
>
>>> - A request/response protocol for querying the ALTO service to
>>> obtain information useful for peer selection, and a format for
>>> requests and responses.   The WG does not require intermediaries
>>> between the ALTO
>> This is strange wording, as WG themselves are not protocols.
>> More fundamentally, is this a requirement?
>
> No.  We had some list discussion on whether or not to include
> intermediaries, but the resolution of that discussion appeared
> to be no (please see the few emails around the following
> link: http://www.ietf.org/mail-archive/web/p2pi/current/ 
> msg00635.html).

How about

s/The WG does not/In scope solutions do not/

>
>
>>> - Can the ALTO service technically provide that information?
>> I think that what is meant here is "Can the ALTO service
>> realistically discover that information?"
>
> OK.
>
>>> - Is the ALTO service willing to obtain and divulge that
>>> information?
>> Do computers have free will?
>
> AI notwithstanding   But point taken; we can attempt a
> reword (if you have any suggestions, please throw them our way.)
>

Whose will ? This gets to a crucial difference between a central  
server and a distributed system.

If it is a central server, then the owner of that server gets a vote  
here, and maybe a veto.

It it is distributed service, then the owners of the peers will  
ultimately decide this.

How about

- Is the ALTO service technically able to obtain that information, and  
is the distribution of
that information allowed by the operators of that service ?

>>> After these criteria are met, the generality of the data will be
>> What is meant by "the generality of the data" ?
>>> considered for prioritizing standardization work, for example the
>
> Hmmm ... since we are talking about prioritizing, maybe what is
> meant is "importance" -- as in "importance of the service" --
> may be a better fit.  Comments?
>

WFM

>>> number of operators and clients that are likely to be able to
>>> provide or use that particular data.  In any case, this WG will not
>>> propose standards on how congestion is signaled, remediated, or
>>> avoided, and
>> Does this mean that congestion is not an issue to consider ?
>
> It is, but not in ALTO.  That will be part of TANA.
>

ACK

>> If the closest peer to me was totally congested and had no available
>> bandwidth, isn't that something that I would want to know ?
>>> will not deal with information representing instantaneous network
>>> state.
>> What is meant by "information representing instantaneous network
>> state" ? Isn't this a protocol to share information about the state
>> of the network ? Or is this an attempt to separate network topology
>> from network performance ? But should network performance also be an
>> issue ?
>
> By and large, it has been the case that that instantaneous
> network characteristics -- like current link usage, congestion,
> etc. --  are not be part of ALTO; they will be  part of TANA.
> Hence, congestion control was deemed out of scope.
>

OK. This WFM now.

>> What is an Internet coordinate system?
>
> Things like IDMaps, GNP, Vivaldi, etc.  Should we define this
> term in the charter?
>

I was not aware of this work. Thanks for alerting me to it.

Regards
Marshall

> Thanks, Marshall.
>
> - 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