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

[Marshall Eubanks <tme at multicasttech.com>]

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 at {alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf