Subject: RE: WG Review: Application-Layer Traffic Optimization (alto)

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Oct 2008 17:23:22 -0700

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.

Overall, I think we should work with the notion of an ALTO "service" rather than specifically an ALTO "server".  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.

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.

- The ability to register information types with IANA and extend these.  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.

Some further comments/questions inline.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of IESG Secretary
> Sent: Monday, October 06, 2008 1:36 PM
> To: IETF Announcement list
> Cc: [email-masked]
> Subject: WG Review: Application-Layer Traffic Optimization (alto)
>
> A new IETF working group has been proposed in the
> Applications Area.  The IESG has not made any determination
> as yet.  The following draft charter was submitted, and is
> provided for informational purposes only.  Please send your
> comments to the IESG mailing list ([email-masked]) by Monday,
> October 13, 2008.
>
> Application-Layer Traffic Optimization (alto)
> =============================================
> Last Modified: 2008-09-29
>
> Current Status: Proposed Working Group
>
> Chair(s): TBD
>
> Applications Area Director(s):
>
> Lisa Dusseault (lisa at osafoundation.org) Chris Newman
> (Chris.Newman at sun.com)
>
> Applications Area Advisor:
>
> Lisa Dusseault (lisa at osafoundation.org)
>
> Mailing List:
>
> General Discussion: p2pi at ietf.org
> To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi
> Archive: http://www.ietf.org/pipermail/p2pi/
>
> Description of Working Group:
>
> A significant part of the Internet traffic today is generated
> by peer-to-peer (P2P) applications used for file sharing,
> real-time communications, and live media streaming.  P2P
> applications exchange large amounts of data, often uploading
> as much as downloading.  In contrast to client/server
> architectures, P2P applications often have a selection of
> peers and must choose.
>
> One of the advantages of P2P systems comes from redundancy in
> resource availability.  This requires choosing among download
> locations, yet applications have at best incomplete
> information about the topology of the network.  Applications
> can sometimes make empirical measurements of link
> performance, but even when this is an option it takes time.
> The application cannot always start out with an optimal
> arrangement of peers, thus causing at least temporary reduced
> performance and excessive cross-domain traffic.  Providing
> more information for use in peer selection can improve P2P
> performance and lower ISP costs.
>
> 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.

> The WG will focus on the following items:
>
> - A "problem statement" document providing a description of the
>   problem and a common terminology.
>
> - A requirements document.  This document will list
> requirements for  the ALTO service, identifying, for example,
> what kind of information  P2P applications will need for
> optimizing their choices.
>
> - 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
> server and the peer querying it.  If the requirements
> analysis identifies the need to allow clients to delegate
> third-parties to query the ALTO service on their behalf, the
> WG will ensure that the protocol provides a mechanism to
> assert the consent of the delegating client.
>

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

> - 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.
>

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.

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?

> - 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.

> 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.

> - Can a client get that information without excessive privacy concerns
>   (e.g. by sending large lists of peers)?
> - Is it information that a client cannot find easily some other way?
>
> After these criteria are met, the generality of the data will
> be considered for prioritizing standardization work, for
> example the number of operators and clients that are likely
> to be able to provide or use that particular data.

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

>In any
> case, this WG will not propose standards on how congestion is
> signaled, remediated, or avoided, and will not deal with
> information representing instantaneous network state.
> Such issues belong to other IETF areas and will be treated
> accordingly by the specific area.
>
> This WG will focus solely on the communication protocol
> between applications and ALTO servers.  Note that ALTO
> services may be useful in client-server environments as well
> as P2P environments, although P2P environments are the first
> focus.  If, in the future, the IETF considers changes to
> other protocols for actually implementing ALTO servers (e.g.
> application-layer protocols for Internet coordinate systems,
> routing protocol extensions for ISP-based solutions), such
> work will be done in strict coordination with the appropriate WGs.
>

I hope we can also look at the above from a generalized service perspective rather than just a client-server perspective.

Thanks,
Vidya

> Issues related to the content exchanged in P2P systems are
> also excluded from the WG's scope, as is the issue dealing
> with enforcing the legality of the content.
>
> Goals and Milestones (very tentative dates):
>
> Apr 2009: Working Group Last Call for problem statement Jun
> 2009: Submit problem statement to IESG as Informational Aug
> 2009: Working Group Last Call for requirements document Oct
> 2009: Submit requirements document to IESG as Informational
> Jan 2010: Working Group Last Call for request/response
> protocol Jan 2010: Working Group Last Call for usage document
> for communicating network preferences Mar 2010: Submit
> request/response protocol to IESG as Proposed Standard Mar
> 2010: Submit usage document to IESG as Proposed Standard May
> 2010: Working Group Last Call of discovery mechanism Jul
> 2010: Submit discovery mechanism to IESG as Proposed Standard
> Aug 2010: Dissolve or re-charter
>
> Initial Drafts for Consideration
> - draft-marocco-alto-problem-statement-02 --
> Application-Layer Traffic Optimization (ALTO) Problem Statement
> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization
> (ALTO) Requirements
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Oct 2008 20:41:05 -0400

I tend to agree with Vidyan's comments.  I think that addressing her
comments regarding a service model instead of a server model is
critical.  While I too am surprised to see a WG review rather than a
second bof, I would not personally object to the work if a reasonable
process is followed in confirming we have sufficient consensus.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Oct 2008 23:07:21 -0700

Contrary to what some people seem to have interpreted my email to mean, I did actually say that the work is needed.  I was noting the lack of consensus from the last BoF and I definitely feel a second BoF is more appropriate at this time to iron out the disagreements.  However, I am still not trying to block the work - I am saying that there are some critical things to alter in the charter proposal.

As Lakshminath notes, the notion of "service" vs. "server" is more than a terminology issue.  It is important that we consider the possibility of ALTO being provided as a distributed service, potentially in an overlay context.  I also see the charter being restrictive in terms of assuming a subset of information types to be provided by the ALTO server.  We need to shoot for a much more generic and extensible mechanism.  Another important missing piece is the ability for peers to publish information about themselves - without that, the request/response protocol alone carries much less value.

Regards,
Vidya

> From: Lakshminath Dondeti [mailto:[email-masked]]
> Sent: Thursday, October 09, 2008 10:17 PM
> To: Richard Barnes
> Cc: Narayanan, Vidya; [email-masked]; [email-masked]'
> Subject: Re: [p2pi] WG Review: Application-Layer Traffic
> Optimization (alto)
>
> On 10/9/2008 6:36 PM, Richard Barnes wrote:
> > On the contrary, I perceived pretty strong agreement at the
> BoF that
> > the ALTO problem, as expressed in the documents and
> presentations, as
> > an important one to solve.  There was some disagreement about
> > solutions, but there seemed to be agreement about the general idea
> > that it would be useful to create an ALTO service that could help
> > peers optimize their peer selection.
>
> Richard,
>
> The minutes
> (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say
> this:
>
> +++++++++++++++
> Many people agreed that this is important work for the IETF, also some
> (less) people hummed against.  Hum was inconclusive - some of the "no"
> hums were (in Jon's words) vehement.
> +++++++++++++++
>
> Given that there was no consensus, it would have been nice if
> the sponsoring AD(s) or the IESG explained what's going on,
> but then transparency, it appears, is not really a goal in
> this case.  If the idea was to just go forward anyway, we
> really wasted 3, may be 6 months.
>   The half measures are a waste of everyone's time.
>
> >
> > The question of "service" versus "server" in the text is a complete
> > non-issue, purely a matter of wording.
>
> No it is not; please see below.
>
> > In all of the "ALTO service"
> > scenarios Vidya describes, there is ultimately a single host that
> > provides ALTO information, which you might as well call an
> "ALTO server".
> >
>
> A distributed service is not necessarily provided by a single host.
>
> > Since it addresses an important problem, and a problem that many
> > people agree is important, I support moving forward with this work.
>
> I for one think that there needs to be much more clarity on
> the goals and the terminology before just moving forward and
> producing useless RFCs.
>
> regards,
> Lakshminath
>
> >
> > --Richard
> >
> >
> >
> > 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.
> >>
> >> Overall, I think we should work with the notion of an ALTO
> "service"
> >> rather than specifically an ALTO "server".  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.
> >>
> >> 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.
> >>
> >> - The ability to register information types with IANA and extend
> >> these.  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.
> >>
> Applications Area.
> >>> The IESG has not made any determination as yet.  The
> following draft
> >>> charter was submitted, and is provided for informational purposes
> >>> only.  Please send your comments to the IESG mailing list
> >>> ([email-masked]) by Monday, October 13, 2008.
> >>>
> >>> General Discussion: p2pi at ietf.org To Subscribe:
> >>> https://www.ietf.org/mailman/listinfo/p2pi
> >>> A significant part of the Internet traffic today is generated by
> >>> peer-to-peer (P2P) applications used for file sharing, real-time
> >>> communications, and live media streaming.  P2P
> applications exchange
> >>> large amounts of data, often uploading as much as
> downloading.  In
> >>> contrast to client/server architectures, P2P applications
> often have
> >>> a selection of peers and must choose.
> >>>
> >>> locations, yet applications have at best incomplete information
> >>> about the topology of the network.  Applications can
> sometimes make
> >>> empirical measurements of link performance, but even when
> this is an
> >>> option it takes time.
> arrangement
> >>> of peers, thus causing at least temporary reduced performance and
> >>> excessive cross-domain traffic.  Providing more
> information for use
> >>> in peer selection can improve P2P performance and lower ISP costs.
> >>>
> >>> 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.
> >>
> requirements for
> >>> the ALTO service, identifying, for example, what kind of
> information
> >>> P2P applications will need for optimizing their choices.
> >>>
> >>> - A request/response protocol for querying the ALTO service to
> >>> obtain information useful for peer selection, and a format for
> >>> requests and
> >>> server and the peer querying it.  If the requirements analysis
> >>> identifies the need to allow clients to delegate third-parties to
> >>> query the ALTO service on their behalf, the WG will
> ensure that the
> >>> protocol provides a mechanism to assert the consent of the
> >>> delegating client.
> >>>
> >>
> >>>  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.
> >>>
> >>
> >> 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.
> >>
> >> 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?
> >>
> >>> - 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.
> >>> 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.
> >>
> >>> When the WG considers standardizing information that the
> ALTO server
> >>> could provide, the following criteria are important to
> ensure real
> >>> feasibility.
> >>>
> >> 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.
> >>
> >>> After these criteria are met, the generality of the data will be
> >>> considered for prioritizing standardization work, for example the
> >>> number of operators and clients that are likely to be able to
> >>> provide or use that particular data.
> >>
> >> If we can build an extensible protocol, we don't need to
> define all
> >> possible kinds of information that get carried in it.
> >>
> >>> In any
> information
> >>> representing instantaneous network state.
> >>> This WG will focus solely on the communication protocol between
> >>> applications and ALTO servers.  Note that ALTO services may be
> >>> useful in client-server environments as well as P2P environments,
> >>> although P2P environments are the first focus.  If, in
> the future,
> >>> the IETF considers changes to other protocols for actually
> >>> implementing ALTO servers (e.g.
> >>> application-layer protocols for Internet coordinate
> systems, routing
> >>> protocol extensions for ISP-based solutions), such work
> will be done
> >>> in strict coordination with the appropriate WGs.
> >>>
> >>
> >> I hope we can also look at the above from a generalized service
> >> perspective rather than just a client-server perspective.
> >>
> >> Thanks,
> >> Vidya
> >>
> >>> Issues related to the content exchanged in P2P systems are also
> >>> excluded from the WG's scope, as is the issue dealing
> with enforcing
> >>> 2009: Submit requirements document to IESG as Informational Jan
> >>> 2010: Working Group Last Call for request/response protocol Jan
> >>> 2010: Working Group Last Call for usage document for
> communicating
> >>> network preferences Mar 2010: Submit request/response protocol to
> >>> IESG as Proposed Standard Mar
> >>> 2010: Submit discovery mechanism to IESG as Proposed Standard Aug
> >>> 2010: Dissolve or re-charter
> >>>
> >>> - draft-marocco-alto-problem-statement-02 -- Application-Layer
> >>> Traffic Optimization (ALTO) Problem Statement
> > p2pi mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/p2pi
> >
>

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 10 Oct 2008 08:00:56 -0400

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.

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." I do not see consensus at this moment as to a  
central service solution versus a distributed
solution.

Regards
Marshall

On Oct 6, 2008, at 4:35 PM, IESG Secretary wrote:

> A new IETF working group has been proposed in the Applications  
> Area.  The
> IESG has not made any determination as yet.  The following draft  
> charter
> was submitted, and is provided for informational purposes only.   
> Please
> send your comments to the IESG mailing list ([email-masked]) by Monday,
> October 13, 2008.
>
> Chris Newman (Chris.Newman at sun.com)
>
> communications, and live media streaming.  P2P applications exchange
> large amounts of data, often uploading as much as downloading.  In
> contrast to client/server architectures, P2P applications often have

s/choose/choose the best peer or peers to exchange data with/

>
>
> One of the advantages of P2P systems comes from redundancy in resource
> availability.  This requires choosing among download locations, yet
> applications have at best incomplete information about the topology of
> the network.  Applications can sometimes make empirical measurements
> of link performance, but even when this is an option it takes time.
> The application cannot always start out with an optimal arrangement of
> peers, thus causing at least temporary reduced performance and
> excessive cross-domain traffic.  Providing more information for use in
> peer selection can improve P2P performance and lower ISP costs.
>
> 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.
> 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.
>
> - A requirements document.  This document will list requirements for
> the ALTO service, identifying, for example, what kind of information
> - A request/response protocol for querying the ALTO service to obtain
> information useful for peer selection, and a format for requests and

This is strange wording, as WG themselves are not protocols.

More fundamentally, is this a requirement ? If so, it seems premature  
before a requirements draft is adopted.
Saying "The ALTO server" here also seems limiting - is there a  
solution draft describing a server ?
Others have already commented on central servers versus a distributed  
system, and to
me the charter is not the place to make such decisions.

I would remove this sentence entirely.

> identifies
> the need to allow clients to delegate third-parties to query the ALTO
> service on their behalf, the WG will ensure that the protocol  
> provides a
> mechanism to assert the consent of the delegating client.
>
> 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.
>
> - In order to query the ALTO server, clients must first know one or  
> more

s/server/service/

s/know/find/

>
> ALTO servers that might provide useful information.  The WG will  
> look at
> service discovery mechanisms that are in use, or defined elsewhere  
> (e.g.
> 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.
>
> When the WG considers standardizing information that the ALTO server

s/server/service/

>
> could provide, the following criteria are important to ensure real
> feasibility.
>

I think that what is meant here is "Can the ALTO service realistically  
discover that information?"

> - Is the ALTO service willing to obtain and divulge that information?

Do computers have free will ?

More seriously, it seems very odd to assume that a P2P service will  
not do something that the owners of
the peers want it to do. In my opinion that drives P2P adoption
much more than the efficiencies of bandwidth sharing.

> After these criteria are met, the generality of the data will be

What is meant by "the generality of the data" ?

> 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 ?

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 ?

> This WG will focus solely on the communication protocol between

Not according to the previous paragraphs. Service discovery is not  
part of
this communication protocol, Load balancing is not part of this, etc.

I would suggest changing "solely" to "primarily"

>
> applications and ALTO servers.  Note that ALTO services may be useful
> in client-server environments as well as P2P environments, although
> P2P environments are the first focus.  If, in the future, the IETF
> considers changes to other protocols for actually implementing ALTO
> servers (e.g. application-layer protocols for Internet coordinate  
> systems,

What is an Internet coordinate system ?

>
> routing protocol extensions for ISP-based solutions), such work will
> be done in strict coordination with the appropriate WGs.
>

s/also//

>
> excluded from the WG's scope, as is the issue dealing with enforcing

s/is the issue/are issues/

>
> the legality of the content.

s/the legality of the content/copyrights/

> Apr 2009: Working Group Last Call for problem statement
> Jun 2009: Submit problem statement to IESG as Informational
> Aug 2009: Working Group Last Call for requirements document
> Oct 2009: Submit requirements document to IESG as Informational
> Jan 2010: Working Group Last Call for request/response protocol
> Jan 2010: Working Group Last Call for usage document for
> communicating network preferences
> Mar 2010: Submit request/response protocol to IESG as Proposed
> Standard
> Mar 2010: Submit usage document to IESG as Proposed Standard
> May 2010: Working Group Last Call of discovery mechanism
> Jul 2010: Submit discovery mechanism to IESG as Proposed Standard
> - draft-marocco-alto-problem-statement-02 -- Application-Layer Traffic
> Optimization (ALTO) Problem Statement

Regards
Marshall

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 10 Oct 2008 14:15:58 +0200

Lakshminath Dondeti wrote:
> The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say
> this:
> 
> +++++++++++++++
> Given that there was no consensus, it would have been nice if the
> sponsoring AD(s) or the IESG explained what's going on, but then
> transparency, it appears, is not really a goal in this case.  If the
> idea was to just go forward anyway, we really wasted 3, may be 6 months.

Lakshminath, the objections raised during the BoF in Dublin were on very
specific issues, namely the "general service discovery problem"
supposedly addressed by the charter, a too broad scope in terms of
information exchanged between ALTO clients and ALTO servers, and the
connection between traffic localization and optimization someone seemed
to see implied in the problem statement. During the weeks following the
meeting, people who had expressed concerns at the mic and on the list
constructively contributed to the discussion and the group converged on
a charter the current version is a slight variant of. For this reason,
and for the amount of interest shown in Dublin  -- we called
inconclusive the hum on the charter, but interest in the problem was
made pretty clear by what we heard at the mic, by the number of
contributors, and by the number of people in the room -- we managed to
convince our sponsoring AD (and transitively the IESG) to send it out
for IETF-wide review. If the community identifies new serious issues or
considers the old ones not completely addressed, probably a new BoF will
be the best way to sort them out.

Of course I'm only speaking for myself, not certainly on behalf of Lisa
nor the IESG.

-- 
Ciao,
Enrico

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 10 Oct 2008 08:10:36 -0700

Hi Enrico, Vijay,

Thank you for the summary of what transpired after the Dublin meeting. 
I appreciate you taking the time.

My reading at the BoF was that there were some concerns about this work 
being done in haste without clearly understanding what it is that we 
want to do and what it is that we need to do to address this particular 
problem space (there were even suggestions to move some of the work to 
the IRTF).  My perception and my understanding of some of the dissenting 
opinions was that some of those need to be worked out before creating a 
working group.  We have been in situations where working groups have 
been created in haste to address important and urgent problems, but then 
people disagree so much in working groups that some such working groups 
never made any real progress or had to be shut down (folks, please don't 
try to guess which WG(s) and try to explain the individual situations; 
thanks).  Surely, we don't want that to happen here.

Some of the disagreements here in this thread now, and the intent of 
some of the folks to whitewash the issues raised do seem troublesome.

It would be great if we could rather focus on trying to understand all 
aspects of the problem, have the charter reflect the correct level of 
scope (too wide or too narrow are problematic as we know), and move forward.

thanks,
Lakshminath

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 10 Oct 2008 12:21:02 -0700

Lakshminath and Vidya,

Vijay, Enrico and Stefano have said what I was going to say (e.g. below) --
as sponsoring AD for this charter I've been following the WG discussion,
working with the rest of the IESG, and talking to people to confirm that
there's better consensus on the list, even if there was confusion at the
BOF.  This IETF Last Call is also part of confirming whether there's now
consensus.

It's difficult to write a charter without actually designing the solution.
What would help with the charter, even now, is for people to write up
proposals for the solution -- ideally in the form of Internet-Drafts.  I
haven't yet selected chairs for the WG, so as you can imagine editors and
authors aren't yet selected.  It would be most excellent to see some
individual proposals before a committee gets their hands on them :)

Lisa

On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani
<[email-masked]>wrote:

 ...

>
> And since the BoF, much has changed to narrow the scope of the
> charter down to more manageable pieces as well as establish a
> channel with IRTF to move certain aspects of the work there
> (as the timeline in my previous email indicated.)
>
>  My perception and my understanding of some of the dissenting opinions
>> was that some of those need to be worked out before creating a working
>> group.
>>
>
> But I believe that we have done exactly that: the list has been
> busy since Dublin on attempts to move the work forward in a manner
> that is conducive to all participants.
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 10 Oct 2008 16:08:59 -0400

I agree with the sentiment that this work is too important to not move  
forward. While feelings at the BoF were mixed, the work done since the  
BoF has been substantial, particularly in the area of narrowing the  
charter's scope. The ALTO work as it has been put forth in the current  
charter has potential value not only for diverse applications (as the  
IPTV example below suggests), but also for a diversity of network  
operators facing difficult technical and policy trade-offs arising  
from ever-changing network usage. All sides will benefit from moving  
forward.

Alissa Cooper
Center for Democracy & Technology

On Oct 10, 2008, at 12:29 AM, Daniel Park wrote:

> I also agree to move it forward. One example: ALTO issue is quickly  
> coming up in the IPTV business. P2P for IPTV service already takes  
> place in some of standard bodies (e.g., DVB, EBU, etc...).  So, it's  
> a good timing not to missing over the important business changes...
>
> -- 
> Daniel Park [at] Samsung Electronics
> Standard Architect, blog.naver.com/natpt
>
>
>
> On Fri, Oct 10, 2008 at 10:36 AM, Richard Barnes <[email-masked]>  
> wrote:
> On the contrary, I perceived pretty strong agreement at the BoF that  
> the ALTO problem, as expressed in the documents and presentations,  
> as an important one to solve.  There was some disagreement about  
> non-issue, purely a matter of wording.  In all of the "ALTO service"  
> provides ALTO information, which you might as well call an "ALTO  
> server".
>
> I am surprised to see that ALTO is being proposed for a WG after the  
> said, I do see the need for this work, although I have some comments  
> Overall, I think we should work with the notion of an ALTO "service"  
> rather than specifically an ALTO "server".  The ALTO service may be  
> about a "service" rather than a "server", there is enough mention of  
> information about themselves as part of the ALTO service.  An  
> example of such information may be the uplink/downlink bandwidth of  
> the peer.
>
> 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.
>
> 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.
>
> 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?
>
> overlay.  This can be modeled as service discovery within the  
> overlay - I'm, however, not suggesting that we take on solutions for  
> that.
>
> If we can build an extensible protocol, we don't need to define all

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 10 Oct 2008 13:22:53 -0700

Marshall makes some excellent points.  Some additional thoughts on a few of his observations.

<snip>

>
> 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." I do not
> see consensus at this moment as to a central service solution
> versus a distributed solution.
>

I fully agree.  And, I see some discussions almost collapsing the two saying that eventually, there is a "server" that an ALTO client is talking to.  That is incorrect in a distributed system and pre-supposing that will get us on the wrong solution path with a narrow view.

<snip>

> More seriously, it seems very odd to assume that a P2P
> service will not do something that the owners of the peers
> want it to do. In my opinion that drives P2P adoption much
> more than the efficiencies of bandwidth sharing.
>

Absolutely!  This also goes back to some of the responses on sharing uplink/downlink bandwidth information having privacy issues.  If a peer is willing to share a piece of information, that makes that information viable to be shared.  Building distributed systems within the confines of what may administratively be the best types of information to share doesn't automatically produce the best systems.

<snip>

> If the closest peer to me was totally congested and had no
> available bandwidth, isn't that something that I would want to know ?
>

I do think this type of information is needed, but, I suspect ALTO is not the place for this.  Peers may do measurement-based selection that eventually decides the best ranking of peers and the input from the ALTO service may just be one data point.

Regards,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 10 Oct 2008 13:34:01 -0700

Lisa, Enrico, Vijay,
Thanks for the clarifications.  I went through the P2PI mailing list and found some interesting discussions.  There are some topics where I don't yet see consensus and some of the discussions still seem open.  As Marshall, Sam, Lakshminath and I have pointed out, I don't yet see a consensus on whether the ALTO service is a centralized or distributed one.  I also noted some unresolved discussions on the list on the types of information that can be shared as part of this service.

As I've already noted, I do support the work and believe it needs to be done.  But, I don't believe we have sorted out all the charter issues yet and focusing on that discussion would help move this forward.  Instead, I see a lot of emails reinstating the importance of the work and that it needs to move forward.  Well, that's clearly not the point of debate at all here, since I haven't seen anyone say the work is not important.

A couple of notes inline.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lisa Dusseault
> Sent: Friday, October 10, 2008 12:21 PM
> To: Dondeti, Lakshminath
> Cc: [email-masked]; IESG IESG; [email-masked]
> Vijay, Enrico and Stefano have said what I was going to say
> (e.g. below) -- as sponsoring AD for this charter I've been
> following the WG discussion, working with the rest of the
> IESG, and talking to people to confirm that there's better
> consensus on the list, even if there was confusion at the
> BOF.  This IETF Last Call is also part of confirming whether
> there's now consensus.
>
> It's difficult to write a charter without actually designing
> the solution. What would help with the charter, even now, is
> for people to write up proposals for the solution -- ideally
> in the form of Internet-Drafts.  I haven't yet selected
> chairs for the WG, so as you can imagine editors and authors
> aren't yet selected.  It would be most excellent to see some

The above made me wonder if we are still operating at the IETF :)  We repeatedly chastize people for writing charters with a solution in mind.  I think it is extremely premature to talk about specific solutions, editors and authors - we have more fundamental discussions to be had on scoping the problem and agreeing to what is going to be solved.  I hope we can do that first.

Regards,
Vidya

> <[email-masked]> wrote:
>
>
>  ...
>
>
>               was that some of those need to be worked out
> before creating a working group.
>
>
>

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 10 Oct 2008 17:51:43 -0400

Dear Vijay;

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

> Marshall Eubanks wrote:
>> that there was serious support for this and certainly a critical mass
>> to move forward.
>
> Marshall: Thank you for your review.  More inline.
>
>> 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.)

> 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

There is a missing object. How about

must choose one or more peers from this selection.

?
>>> requests and responses.   The WG does not require intermediaries
>>> between the ALTO
>> 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/

>> I think that what is meant here is "Can the ALTO service
>> realistically discover that information?"
>
> OK.
>
>> 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 ?

> 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

>>> provide or use that particular data.  In any case, this WG will not
>>> propose standards on how congestion is signaled, remediated, or
>>> avoided, and
> It is, but not in ALTO.  That will be part of TANA.
>

ACK

>> bandwidth, isn't that something that I would want to know ?
>> 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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 10 Oct 2008 15:10:04 -0700

On 10/10/2008 12:21 PM, Lisa Dusseault wrote:
> Lakshminath and Vidya,
> 
> Vijay, Enrico and Stefano have said what I was going to say (e.g. below) 
> -- as sponsoring AD for this charter I've been following the WG 
> discussion, working with the rest of the IESG, and talking to people to 
> confirm that there's better consensus on the list, even if there was 
> confusion at the BOF.  This IETF Last Call is also part of confirming 
> whether there's now consensus.

Hi Lisa,

My concern can be put in really simple terms.  We have some really very 
confusing processes and we seem to add to the confusion and not make 
things simpler.

I left Dublin thinking, out of the p2pi efforts, TANA will be a WG 
(there was strong consensus and agreement on the problem space and what 
needs to be done) and ALTO may have another BoF.  As of today, there is 
a WG proposal on the table for ALTO and in a different area from where 
we started; TANA is on the BoF wiki.

Next, my experiences in the past on BoFs that did not have consensus 
have been dramatically different from what is happening on ALTO.  The 
IESG has really even refused to allow another BoF much less directly 
started creating a working group.  So, it makes me wonder whether the 
rules have recently been changed or whether they are selectively applied.

I am also confused by your use of the word consensus; you say that 
you've "talked to people" to confirm that there's "better consensus on 
the list," but also say that the charter review is also part of the 
consensus process.  Shouldn't there be a call for consensus?

> It's difficult to write a charter without actually designing the 

This is an interesting opinion.  May I translate that to mean that there 
is already a solution in the minds of the people who wrote the charter?

Why then would we bother with the proposed requirements effort, writing 
down a problem statement and all the rest?  Why not put an RFC number on 
the solution?

It also makes me wonder what your opinion on the following from 2418.

" - Is the proposed work plan an open IETF effort or is it an attempt
       to "bless" non-IETF technology where the effect of input from IETF
       participants may be limited?"

> What would help with the charter, even now, is for people to 
> write up proposals for the solution -- ideally in the form of 
> Internet-Drafts.  

This seems to be starkly different from the process I know of.  Are you 
really suggesting that people come up with solutions to help with the 
charter?  What problem are we solving?  What are the requirements? 
Based on the proposal that was sent out, we won't have consensus on all 
of those until Oct 2009 or later.

> I haven't yet selected chairs for the WG, so as you 
> can imagine editors and authors aren't yet selected. 

> It would be most 
> excellent to see some individual proposals before a committee gets their 
> hands on them :)

I am sorry Lisa, but I am really confused by your request for proposals 
before we even agree on the problem.  I am hoping for a clarification.

thanks,
Lakshminath

> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  ...
> 
> 
>         was that some of those need to be worked out before creating a
>         working group.
> 
>

---

From: Enrico Marocco <[email-masked]>
Date: Sat, 11 Oct 2008 03:27:25 +0200

> is already a solution in the minds of the people who wrote the charter?

Nope. Who has been following the p2pi list for the last five months
probably knows that there are three different approaches (solutions?)
floating around: the "sorting oracle" (described in a SIGCOMM paper
authored by folks from TU-Berlin, a variant of which is IDIPS), P4P
(soon to be published as I-D and, IIRC, described in another SIGCOMM
paper), and Stanislav's proposal (discussed in Dublin and on the list:
http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html). Who
wrote the charter had all those approaches clear in mind and took
special care that none of them got ruled out.

>        participants may be limited?"

I don't know Lisa's opinion, but am sure that this is not the case here.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 10 Oct 2008 21:58:41 -0700

Thanks for the clarification Enrico :).

best,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 12 Oct 2008 15:59:43 -0700

Hi Vijay,
Thank you for your response.  Please see comments inline below.

> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Friday, October 10, 2008 11:41 AM
> To: Narayanan, Vidya
> Cc: IESG IESG; [email-masked]; [email-masked]
> > 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.
>
> >  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.)
>

When we consider ALTO as a distributed service, there may not necessarily be "a" host that specifically resolves the ALTO queries.  For instance, consider the case where ALTO is a service offered in an overlay.  There may be peers publishing information about themselves on the overlay and other peers looking up such information.  These are not necessarily client-server style communications.  In fact, all that is important in this context is that the overlay acts as a rendezvous for sharing such information.  Now, of course, that is one possible model.  But, in order to allow for that and other models, I do want the charter to keep the focus on the service and not on a server.

> > 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.
>
> that need to
> > be addressed here:
> > 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.
>

I'm afraid that would be a mistake.  It actually doesn't matter if we don't agree today on the exact types of information that can be shared.  It is important that we have a protocol that allows peers to publish ALTO related information.  Having this protocol be extensible would allow for any type of information to be carried in it.  So, I strongly believe we don't need a recharter to consider any information types - in fact, I'd be okay if this effort only took on the protocol and if all information types were to be registered through other means.  That said, I'm not against taking on some subset of those types - I don't believe that should be the core focus of this work though.

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

Well, it is a bit hard to say what the charter does not rule out - typically we try and do what the charter says we should do.  However, before we get to the registry, we need to agree on the protocol components.  In my view, there are two such components - the publish protocol mentioned above and the request/response protocol (actually, more generically, a lookup protocol) mentioned below.

> > 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:
>
>    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
> We *are* starting with the default information; as other
> information is required, we can extend the charter, right?

Actually, I am saying that is exactly what is not needed.  I don't see the information types as something this effort will necessarily nail down.  We need to define interoperable semantics for the protocol - what gets carried in it may actually be registered as a type in the registry outside of this effort.  The registry comes into picture for enabling this part.

> 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.
>
> >> selection. ALTO services may take different approaches at
> balancing
> 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.
> >
> 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.
>

I would like us to think beyond applications we see today.  Had TCP not been designed that way, we probably would have needed a redesign of it for HTTP :)  I can envision video applications using the P2PSIP framework, for instance.  In any event, I still don't have a good understanding of what it means to consider the needs of these various things - what does it mean to say that we'll consider the needs of BitTorrent/CDN, etc.?  Could you maybe give me an example of what it means?

> 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.
>

Okay.

> > 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).
>

Again, as I wrote above, I think the information types are less important than the container for any such type in the protocol.

> > 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.
>

Hmmm... Okay.  Perhaps it would be good to say that some analysis is needed to determine how to identify the peers?  Maybe this is something that needs to happen in the requirements phase.

<snip>

> > 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.
>

What I am saying is that it is not for us to determine the usefulness of a particular piece of information.  As long as the peers or service providers are willing to share a piece of information, that can be consumed by other peers as they deem fit.  So, I don't think we should consider ourselves the gatekeeper for the types of information shared.

Best regards,
Vidya

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Oct 2008 15:23:19 +0300 (EEST)

...

I believe this work could be useful and would provide an improvement 
over existing p2p usage and traffic management.

I'd be more comfortable with this effort if a recharter (this is a 
rather lightweight process) was needed after finishing the problem 
statement and the requirements.  It would also encourage that people 
actually put some serious work on those before diving into solutions 
:-)

There are significant design issues that will come up in the protocols 
and I'd expect that it would be helpful if those had already been 
dealt with in the requirements phase.

For example, the current req document has:

    REQ. 4: ALTO Clients MUST be able to find out where to send ALTO
    queries.

.. and the charter lists DHCP option or SRV record as examples.  Both 
of these have issues in certain contexts.  For example, must this 
discovery mechanism work across unmodified NAT boxes?  DHCP option 
doesn't; SRV record in many contexts doesn't either (or otherwise 
you'll end up with the same "how to you discover the domain name under 
which you should look?" problem).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 10 Oct 2008 13:36:46 -0500

Lakshminath Dondeti wrote:
> Hi Enrico, Vijay,
> 
> Thank you for the summary of what transpired after the Dublin
> meeting. I appreciate you taking the time.

Lakshminath: No problem.  Thank you for your time and effort on
this.

> My reading at the BoF was that there were some concerns about this
> work being done in haste without clearly understanding what it is
> that we want to do and what it is that we need to do to address this
> particular problem space (there were even suggestions to move some of
> the work to the IRTF).

> some of the folks to whitewash the issues raised do seem

I sincerely do not believe that we are trying to whitewash any
issues here.  It would seem an awful waste of time of the ADs,
IRTF chair and list participants to engage in detailed discussions
since the Dublin BoF if that were indeed the case.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 10 Oct 2008 13:40:55 -0500

> 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.

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.)

> 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.

> 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 

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.

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.

>> Traffic Optimization (ALTO) service that will provide applications
>> selection. ALTO services may take different approaches at balancing
>>  factors including maximum bandwidth, minimum cross-domain traffic,

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.

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.

> applications.  Given that, it seems premature to conclude that the WG
>  should consider the above mentioned parameters.  Also, as I 

> Another question I have is about the assumptions around expected peer

>> 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.
> 
> overlay.  This can be modeled as service discovery within the overlay

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.

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.

> possible kinds of information that get carried in it.

Please see above.

Thank you.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 10 Oct 2008 16:31:28 -0500

Agreed.

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).

OK.

Thanks, Marshall.

- vijay

---

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 13 Oct 2008 17:02:41 +0200

Hi Vidja, all,

I believe that the charter is narrow and broad enough to cover the
topic of ALTO, i.e., the charter is not limiting the solution space. 

However, when reading your comments, it sounds that you have a very
specific solution in mind which is probably not covered by the
current charter. 

[...]

> When we consider ALTO as a distributed service, there may not
> necessarily be "a" host that specifically resolves the ALTO queries.
> For instance, consider the case where ALTO is a service offered in an
> overlay.  There may be peers publishing information about themselves on
> the overlay and other peers looking up such information.  These are not
> necessarily client-server style communications.  In fact, all that is
> important in this context is that the overlay acts as a rendezvous for
> sharing such information.  Now, of course, that is one possible model.

You probably have a publish/subscribe system in mind for p2p overlays.
I assume this is not in scope of ALTO. 

> But, in order to allow for that and other models, I do want the charter
> to keep the focus on the service and not on a server.

Is the IETF anyhow standardizing services? I don't see this.  

[...]

> I'm afraid that would be a mistake.  It actually doesn't matter if we

I'm afraid that carrying up/downlink capacity of the peer's local link
is a complete waste of resource, as this is not indicating something. For
instance, a peer may have a relatively huge uplink but on a shared medium,
i.e., a medium which might be shared by hundreds of other hosts/traffic.
So what does this information express? 

> don't agree today on the exact types of information that can be shared.
> It is important that we have a protocol that allows peers to publish
> ALTO related information.  Having this protocol be extensible would
> allow for any type of information to be carried in it.  So, I strongly

The question is, whether the roots of ALTO are actually intended to carry
any type of information? The main idea is to carry information to optimize
traffic, e.g., decreasing cross ISP traffic. 

> believe we don't need a recharter to consider any information types -
> in fact, I'd be okay if this effort only took on the protocol and if
> all information types were to be registered through other means.  That
> said, I'm not against taking on some subset of those types - I don't
> believe that should be the core focus of this work though.
> 
> Well, it is a bit hard to say what the charter does not rule out -
> typically we try and do what the charter says we should do.  However,
> before we get to the registry, we need to agree on the protocol
> components.  In my view, there are two such components - the publish
> protocol mentioned above and the request/response protocol (actually,
> more generically, a lookup protocol) mentioned below.

It is good to see your ideas but doesn't this go beyond a charter discussion,
as your are discussing a solution?

This comes back to my initial comment about discussing a specific solution,
and we haven't yet reached the times to discuss a solution - at least not
here.

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Jan Seedorf" <[email-masked]>
Date: Mon, 13 Oct 2008 17:07:23 +0200

Dear Lakshminath,

> I left Dublin thinking, out of the p2pi efforts, TANA will be 
> a WG (there was strong consensus and agreement on the problem 
> space and what needs to be done) and ALTO may have another 
> BoF.  As of today, there is a WG proposal on the table for 
> ALTO and in a different area from where we started; TANA is 
> on the BoF wiki.
> 
> Next, my experiences in the past on BoFs that did not have 
> consensus have been dramatically different from what is 
> happening on ALTO.  The IESG has really even refused to allow 
> another BoF much less directly started creating a working 
> group.  So, it makes me wonder whether the rules have 
> recently been changed or whether they are selectively applied.

I am not an IETF veteran, but from my experience it is perfectly ok for post-BoF discussions to happen on the mailing list and for these discussions to resolve some of the controversial issues at the BoF. I think this is was happened with ALTO. I also think that the IESG has been following the discussions on the mailing list and the WG Review is in fact a reaction to the agreement which has been found on the mailing list regarding the disagreements from the BoF.

Just my two cents ...

 - Jan  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Lakshminath Dondeti
> Sent: Saturday, October 11, 2008 12:10 AM
> To: Lisa Dusseault
> > discussion, working with the rest of the IESG, and talking 
> to people 
> > to confirm that there's better consensus on the list, even if there 
> > was confusion at the BOF.  This IETF Last Call is also part of 
> > confirming whether there's now consensus.
> 
> Hi Lisa,
> 
> My concern can be put in really simple terms.  We have some 
> really very confusing processes and we seem to add to the 
> confusion and not make things simpler.
> 
> I left Dublin thinking, out of the p2pi efforts, TANA will be 
> a WG (there was strong consensus and agreement on the problem 
> space and what needs to be done) and ALTO may have another 
> BoF.  As of today, there is a WG proposal on the table for 
> ALTO and in a different area from where we started; TANA is 
> on the BoF wiki.
> 
> Next, my experiences in the past on BoFs that did not have 
> consensus have been dramatically different from what is 
> happening on ALTO.  The IESG has really even refused to allow 
> another BoF much less directly started creating a working 
> group.  So, it makes me wonder whether the rules have 
> recently been changed or whether they are selectively applied.
> 
> I am also confused by your use of the word consensus; you say 
> that you've "talked to people" to confirm that there's 
> "better consensus on the list," but also say that the charter 
> review is also part of the consensus process.  Shouldn't 
> there be a call for consensus?
> 
> >

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Oct 2008 10:49:41 -0500

Vidya: Thank you for your response and your time in helping
define the work.  More inline.

Narayanan, Vidya wrote:
>  For instance, consider the case where ALTO is a service offered in
> an overlay.  There may be peers publishing information about
> themselves on the overlay and other peers looking up such
> information.  These are not necessarily client-server style
> communications.  In fact, all that is important in this context is
> that the overlay acts as a rendezvous for sharing such information.

I think the disconnect we may be having is that you view
ALTO as a peer description protocol; it is not.  Other
protocols like BitTorrent, for example, are more suited to
this, and they do exactly what you want.  In a BitTorrent
overlay (swarm), the overlay knows exactly which peer is
contributing which content, which peer has which chunks,
the download/upload ratio, the time the peer joined the swarm,
whether the peer is choked or unchoked, whether the peer has
a public port, etc.  ALTO is not out to replace BitTorrent.  What
ALTO is providing are better strategies for peer selection.

For instance, it is not ALTO that gets to decide which peer is
hosting which content and what the contributions of that peer
to the overlay are.  However, it is ALTO's job to provide
information to a querying peer allowing it to determine wisely
where it will download the content from.

> don't agree today on the exact types of information that can be 
> shared.  It is important that we have a protocol that allows peers to
> publish ALTO related information.  Having this protocol be 
> extensible would allow for any type of information to be carried in 
> it.

So far, no one on the list has proposed that ALTO be a peer
description and publication protocol.  So based on the discussion
we have had since (essentially the workshop in) May 2008 on the
p2pi list, I would hesitate to add in the charter something that
participants have not expressed any preference for (i.e., a
deliverable on peers publishing their information.)

> Actually, I am saying that is exactly what is not needed.  I don't 
> see the information types as something this effort will necessarily 
> nail down.

I am confused; I thought earlier you were trying to make the case
that ALTO should provide even more specific information that
needs to be published?

In the end, we do agree on that any protocol be extensible.  Whether
that is extensible through a registry-like mechanism or other
means remains to be discussed in the WG, right?

> I would like us to think beyond applications we see today. Had TCP 
> not been designed that way, we probably would have needed a redesign
> of it for HTTP :)

Protocols evolve, networks evolve.  I am sure we were prescient
when we designed TCP such that HTTP could simply use it.  However,
other realities of evolution did force us to design SCTP, for
instance.  But regardless, the point is that we should be general,
and we are; but we have to do this while drawing a fine line
between research and engineering.  Some applications that are
appearing on the horizon are streaming media and P2PTV; for
these we have opened up channels with IRTF.  So I don't see
where we are constraining ourselves in ALTO.

> I can envision video applications using the P2PSIP framework, for
> instance.

Yes, and as I wrote earlier, they can use ALTO to discover the
the peer they find optimal within their constraints and use it.

> In any event, I still don't have a good understanding of what it 
> means to consider the needs of these various things - what does it 
> mean to say that we'll consider the needs of BitTorrent/CDN, etc.? 
> Could you maybe give me an example of what it means?

Look at the Ono work, which is a plug-in to BitTorrent.  It
uses Akamai redirections to find the closest peer to download
content from.  In a sense, ALTO is replacing that ad-hoc
lookup and providing a much more deterministic answer.  That
is what we mean by the needs of "BitTorrent/CDN etc."

> What I am saying is that it is not for us to determine the usefulness
> of a particular piece of information.  As long as the peers or 
> service providers are willing to share a piece of information, that 
> can be consumed by other peers as they deem fit.  So, I don't think 
> we should consider ourselves the gatekeeper for the types of 
> information shared.

But we are not.  As I made the point earlier, ALTO is not out to
replace BitTorrent.  So replicating in ALTO the details about
peers that BitTorrent already has is counter-productive.  Instead,
ALTO can focus on providing the pieces that BitTorrent does not:
topology, policy, etc.  That is where we will make a difference.

Thanks,

- vijay

---

From: Lars Eggert <[email-masked]>
Date: Tue, 14 Oct 2008 17:37:07 +0300

Hi,

> bandwidth, isn't that something that I would want to know ?

I think the intent here is actually fine. ALTO attempts to improve the  
initial peer selection over simply choosing peers randomly by making  
some information available before this selection happens.

The information provided through ALTO can't - in my opinion - include  
very detailed or timely load or congestion information, because I  
remain unconvinced that the ALTO system could actually obtain and  
maintain this information on the timescales it would need to.

But there's other information that could be useful, such as some  
coarse-grained "this peer is not totally on the other side of the  
planet"-like information. Assuming that throughput and distance are by  
and large inversely proportional, preferring closer peers should often  
be better than choosing totally randomly. Other kinds of useful  
information could be "talking to this peer doesn't count towards your  
bandwidth quota", etc.

Now, once you actually establish and use a transport connection with  
the ALTO-recommended peer, you may well find that throughput is low.  
So you ditch the peer and try another one, which P2P systems already  
do. The intent here isn't that ALTO would pick the globally optimal  
peers for you, the intent is that it'll help an application reach a  
good set of peers a bit more quickly.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 14 Oct 2008 17:40:45 +0300

> special care that none of them got ruled out.

FYI, there's at least one more proposal in this space: the Ono stuff  
from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html 
). There was a paper at SIGCOMM this year, and their system has the  
interesting feature that it simply freeloads of Akamai's DNS entries  
in order to determine who's close to whom. No "ALTO boxes" needed.

Lars

---

From: Song Haibin <[email-masked]>
Date: Tue, 14 Oct 2008 16:29:30 +0800

Hi Vijay,

>where it will download the content from.

Totally agree.

>deliverable on peers publishing their information.)

IMHO, not every type of information can be carried in the ALTO protocol, but
only network policy and topology related (e.g. peer preference) information
is allowed. I don't think we are designing BitTorrent here.

Regards!
Song Haibin

---

From: Laird Popkin <[email-masked]>
Date: Tue, 14 Oct 2008 10:48:01 -0400 (EDT)

I'd like to second this, and also make sure that the relationship between ALTO and the application is clear.

>From the application perspective, ALTO is a source of useful guidance (i.e. network topology and "cost" model) that can help the p2p network find good peers to connect. But once peers are exchanging data, the p2p network/protocol (and TCP) pretty much takes over, because those protocols address the actual throughput between peers, real-time congestion, etc., that are not addressed by ALTO.

I should also make clear that ALTO does not (and cannot) control the p2p network. Generally ALTO guidance should provide better than average peer connections (which is certainly what we saw in the P4P field tests), so the p2p networks will be motivated to use ALTO guidance when they can because it's in their interests to do so. But there will always be cases that are exceptions. For example, if a p2p network is getting fantastic data delivery between two peers, it is highly likely to keep using that connection no matter what ALTO says. And, on the flip side, if the ALTO-recommended peer connections aren't providing the data needed, the p2p network will use other peers as data sources. And, of course, p2p networks must continue to operate where ALTO guidance is unavailable. :-)

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Song Haibin" <[email-masked]>
To: "Vijay K. Gurbani" <[email-masked]>, [email-masked]
Cc: [email-masked], "IESG IESG" <[email-masked]>, [email-masked]
Sent: Tuesday, October 14, 2008 4:29:30 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Hi Vijay,

Totally agree.

Regards!
Song Haibin

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 14 Oct 2008 07:55:57 -0700

> in order to determine who's close to whom. No "ALTO boxes" needed.

Basically, this is freeloading on the akamai DNS infrastructure to  
create a "topology oracle": which nodes are close in terms of network  
topology as a common proxy for bandwidth.

It doesn't need "ALTO boxes" only because someone else has colleced  
that information, and that there is a separation between the query  
replying infrastructure (through DNS) and the measurement  
infrastructure.

However, it does bring up a good point:  DNS games allow the ability  
to divorce the measurement infrastructure from the reporting  
infrastructure, and to create a reporting infrastructure that can  
always work both with and without ISP cooperation.

---

From: Karl Auerbach <[email-masked]>
Date: Tue, 14 Oct 2008 11:16:43 -0700

Lars Eggert wrote:

> from Northwestern 
> (http://www.aqualab.cs.northwestern.edu/projects/Ono.html). There was a 
> paper at SIGCOMM this year, and their system has the interesting feature 
> that it simply freeloads of Akamai's DNS entries in order to determine 
> who's close to whom. No "ALTO boxes" needed.

Since you mentioned DNS as a proximity tool, I thought I'd go slightly 
awry and point out a bit of work I did a while back that, while not at 
itself at the application level, did try to address some application 
layer optimizations concerns that we had when I was working on binding 
video clients to video services.

The main idea was that neither hop count, asn-path length, ICMP-Echo 
time, DNS answer time, nor TCP-connect-time are very good indicators of 
internet proximity for the purposes of applications that are going to 
make different kinds of demands and need different levels of service. 
And because such proximity questions are likely to be asked frequently, 
the cost of asking the question, and the delay incurred in asking that 
question, ought to be low.

So what I did was to try to blend the notions of potential bandwidth and 
packet size dynamics (from the old integrated services work) with some 
ideas from the old multicast mtrace protocol.  What I came up, and it 
was far, far from complete, was something that needed to live inside the 
router infrastructure, although not on any fast-path part of any router. 
  I called the thing the "Fast Path Characterization Protocol".

(The name may be misleading, the implementation was intended to find a 
path quickly, *not* that it would sit in any router fast-path switching 
logic.)

So, here it is, 8+ years old: 
http://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html

	--karl--

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 14 Oct 2008 17:09:49 -0700

Hi Martin,
Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't.  At the moment, I'm just saying that ALTO should be beyond *only* dealing with information from service providers.  Peer selection is absolutely beyond just catering to ISP interests; peers have a vested interest in it - that said, information that peers are willing to share towards this is very valuable.  We need to have interoperable ways of making that available and I do think this fits nicely with the ALTO objectives - going back to the root of the objectives, it is about peer selection and not just about ISP network utilization interests.

Just to be clear, I am not downplaying the importance of ISP network utilization aspects - it is one component of the puzzle and there are others we need to consider along with it for a more complete picture.

Thanks,
Vidya

> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: Monday, October 13, 2008 8:03 AM
> To: Narayanan, Vidya; Vijay K. Gurbani
> Subject: RE: [p2pi] WG Review: Application-Layer Traffic
> Optimization (alto)
>
> Hi Vidja, all,
>
> I believe that the charter is narrow and broad enough to
> cover the topic of ALTO, i.e., the charter is not limiting
> the solution space.
>
> However, when reading your comments, it sounds that you have
> a very specific solution in mind which is probably not
> covered by the current charter.
>
> [...]
>
> > >
> > > (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.)
> > >
> >
> > overlay.  There may be peers publishing information about
> themselves
> > on the overlay and other peers looking up such information.
>  These are
> > not necessarily client-server style communications.  In
> fact, all that
> > is important in this context is that the overlay acts as a
> rendezvous
> > for sharing such information.  Now, of course, that is one
> possible model.
>
> > But, in order to allow for that and other models, I do want the
> > charter to keep the focus on the service and not on a server.
>
> > > 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.
> provided,
> > > it could calculated nonetheless by other peers.
> > > That is, there are degrees of disagreement here and consequently,
> I'm afraid that carrying up/downlink capacity of the peer's
> local link is a complete waste of resource, as this is not
> indicating something. For instance, a peer may have a
> relatively huge uplink but on a shared medium, i.e., a medium
> which might be shared by hundreds of other hosts/traffic.
> The question is, whether the roots of ALTO are actually
> intended to carry any type of information? The main idea is
> to carry information to optimize traffic, e.g., decreasing
> cross ISP traffic.
>
> > > protocol is certainly a possibility the charter does not
> rule out,
> > > no?
> > >
> >
> It is good to see your ideas but doesn't this go beyond a
> charter discussion, as your are discussing a solution?
>
> This comes back to my initial comment about discussing a
> specific solution, and we haven't yet reached the times to
> discuss a solution - at least not here.
>
>   Martin
>
>
> [email-masked]
>
> NEC Laboratories Europe - Network Research Division NEC
> Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England 2832014
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 14 Oct 2008 22:47:10 -0700

Hi Vijay,
I am not at all talking about reinventing what BitTorrent can do or even remotely about any actual p2p application itself.  I am only talking about peer selection.  However, I think there is a critical difference between what I view as contributing to peer selection and what the current proposed charter does.

Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective.  That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own.  The current charter definition (and from what I can tell based on your response below) only seems to allow for a).  I would agree that c) is out of scope of ALTO and something that peers can additionally do.  I strongly believe that b) should be part of the ALTO work.  This functionality itself is application agnostic and requires an interoperable solution for it to be beneficial.  This has nothing to do with content itself; it is purely about sharing information that helps with peer selection.

Lastly, as long as this framework is made available, information can be shared among peers on an overlay in a distributed fashion and/or provided by a service provider host.

Best regards,
Vidya

> Sent: Monday, October 13, 2008 8:50 AM
> To: Narayanan, Vidya
> > for sharing such information.
>
> I think the disconnect we may be having is that you view ALTO
> as a peer description protocol; it is not.  Other protocols
> like BitTorrent, for example, are more suited to this, and
> they do exactly what you want.  In a BitTorrent overlay
> (swarm), the overlay knows exactly which peer is contributing
> which content, which peer has which chunks, the
> download/upload ratio, the time the peer joined the swarm,
> a public port, etc.  ALTO is not out to replace BitTorrent.
> What ALTO is providing are better strategies for peer selection.
>
> For instance, it is not ALTO that gets to decide which peer
> is hosting which content and what the contributions of that
> peer to the overlay are.  However, it is ALTO's job to
> provide information to a querying peer allowing it to
> determine wisely where it will download the content from.
>
> extensible
> > would allow for any type of information to be carried in it.
>
> description and publication protocol.  So based on the
> discussion we have had since (essentially the workshop in)
> May 2008 on the p2pi list, I would hesitate to add in the
> charter something that participants have not expressed any
> preference for (i.e., a deliverable on peers publishing their
> information.)
>
> > Actually, I am saying that is exactly what is not needed.
> I don't see
> > the information types as something this effort will
> necessarily nail
> > down.
>
> I am confused; I thought earlier you were trying to make the
> case that ALTO should provide even more specific information
> that needs to be published?
>
> In the end, we do agree on that any protocol be extensible.
> Whether that is extensible through a registry-like mechanism
> or other means remains to be discussed in the WG, right?
>
> > I would like us to think beyond applications we see today.
> Had TCP not
> > been designed that way, we probably would have needed a
> redesign of it
> > for HTTP :)
>
> Protocols evolve, networks evolve.  I am sure we were
> prescient when we designed TCP such that HTTP could simply
> use it.  However, other realities of evolution did force us
> to design SCTP, for instance.  But regardless, the point is
> that we should be general, and we are; but we have to do this
> while drawing a fine line between research and engineering.
> Some applications that are appearing on the horizon are
> streaming media and P2PTV; for these we have opened up
> channels with IRTF.  So I don't see where we are constraining
> ourselves in ALTO.
>
> Yes, and as I wrote earlier, they can use ALTO to discover
> the the peer they find optimal within their constraints and use it.
>
> > In any event, I still don't have a good understanding of
> what it means
> > to consider the needs of these various things - what does
> it mean to
> > say that we'll consider the needs of BitTorrent/CDN, etc.?
> > of a particular piece of information.  As long as the peers
> or service
> > providers are willing to share a piece of information, that can be
> > consumed by other peers as they deem fit.  So, I don't
> think we should
> > consider ourselves the gatekeeper for the types of
> information shared.
>
> But we are not.  As I made the point earlier, ALTO is not out
> to replace BitTorrent.  So replicating in ALTO the details
> about peers that BitTorrent already has is
> counter-productive.  Instead, ALTO can focus on providing the
> pieces that BitTorrent does not:
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: "Ye WANG" <[email-masked]>
Date: Tue, 14 Oct 2008 16:07:24 -0400

On Tue, Oct 14, 2008 at 10:55 AM, Nicholas Weaver <[email-masked]

>> FYI, there's at least one more proposal in this space: the Ono stuff from
>> Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html).
>> There was a paper at SIGCOMM this year, and their system has the interesting
>> feature that it simply freeloads of Akamai's DNS entries in order to
>> determine who's close to whom. No "ALTO boxes" needed.
>>
>
> Basically, this is freeloading on the akamai DNS infrastructure to create a
> "topology oracle": which nodes are close in terms of network topology as a
> common proxy for bandwidth.
>
> It doesn't need "ALTO boxes" only because someone else has colleced that
> information, and that there is a separation between the query replying
> infrastructure (through DNS) and the measurement infrastructure.
>
> However, it does bring up a good point:  DNS games allow the ability to
> divorce the measurement infrastructure from the reporting infrastructure,
> and to create a reporting infrastructure that can always work both with and
> without ISP cooperation.

This is a very good comment on the architecture on "ALTO box".   Just to
clarify on a risk of building an Internet infrastructure based on a hack of
using the Akamai DNS infrastructure to create a "topology oracle".
You may already know it, but some others may not. So I would like to
point it out.

Akamai DNS redirection considers not only topology, but also Akamai's own
server state, and Akamai's own redirection policy.  To illustrate this,
consider a simple example where Akamai temporarily (e.g., during
maintenance,
or misconfiguration, or under attack, or whatever reason) redirects users
from distant geographic locations to the same set of servers. This may
result
in these users being deemed "close together" when in fact they are not.

This is not limited to Akamai. DNS redirection typically considers not
only topology, but also the state and policy of whoever controls it.

---

From: Philip Levis <[email-masked]>
Date: Tue, 14 Oct 2008 15:05:58 -0700

On Oct 14, 2008, at 1:07 PM, Ye WANG wrote:

> create a "topology oracle": which nodes are close in terms of  
> network topology as a common proxy for bandwidth.
>
> from distant geographic locations to the same set of servers. This  
> may result

To be fair, I don't think anyone was recommending Ono, merely noting  
it was one that has been proposed and so should be included in the  
list. While a cute systems hack that might make something work better  
today, it's pretty clearly not a good interoperable and long-term  
solution.

Phil

---

From: Song Haibin <[email-masked]>
Date: Wed, 15 Oct 2008 09:07:37 +0800

>From: Laird Popkin [mailto:[email-masked]]
>Sent: Tuesday, October 14, 2008 10:48 PM
>To: Song Haibin
>I'd like to second this, and also make sure that the relationship between
ALTO
>and the application is clear.
>
>From the application perspective, ALTO is a source of useful guidance (i.e.
>network topology and "cost" model) that can help the p2p network find good
peers
>to connect. But once peers are exchanging data, the p2p network/protocol
(and
>TCP) pretty much takes over, because those protocols address the actual
>throughput between peers, real-time congestion, etc., that are not
addressed
>by ALTO.
>
>I should also make clear that ALTO does not (and cannot) control the p2p
network.
>Generally ALTO guidance should provide better than average peer connections
>(which is certainly what we saw in the P4P field tests), so the p2p
networks
>will be motivated to use ALTO guidance when they can because it's in their
>interests to do so. But there will always be cases that are exceptions. For
>example, if a p2p network is getting fantastic data delivery between two
peers,
>it is highly likely to keep using that connection no matter what ALTO says.
And,
>on the flip side, if the ALTO-recommended peer connections aren't providing
the
>data needed, the p2p network will use other peers as data sources. And, of
course,
>p2p networks must continue to operate where ALTO guidance is unavailable.
:-)

Yes, actually I have the same thought with you.

BR
Song Haibin

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 15 Oct 2008 10:20:47 -0500

Narayanan, Vidya wrote:
> Hi Vijay, I am not at all talking about reinventing what BitTorrent 
> can do or even remotely about any actual p2p application itself.  I 
> am only talking about peer selection.  However, I think there is a 
> critical difference between what I view as contributing to peer 
> selection and what the current proposed charter does.

Vidya: Thank you for your response. I think we are converging
to the crucial difference in this thread.  This is a good thing.
More inline.

> Peer selection is important to ISPs from a network utilization 
> perspective and to peers themselves from a performance perspective. 
> That automatically makes peer selection a function of multiple 
> aspects - a) information that some service providers may decide to 
> share with the peers, b) information that peers decide to make 
> available about themselves to other peers for this purpose, and, c) 
> any measurements peers may do on their own.  The current charter 
> definition (and from what I can tell based on your response below) 
> only seems to allow for a).  I would agree that c) is out of scope of
>  ALTO and something that peers can additionally do.  I strongly 
> believe that b) should be part of the ALTO work.

I believe that incorporating (b) expands the charter quite a bit,
whereas the consensus since the first BoF was for narrowing
it down.  I will also note that the feedback expressed on the
list does not appear to view ALTO as a peer description protocol.

To be sure, I am not unsympathetic to (b), it seems like a great
problem to solve, it's just that ALTO may not be the best place
to solve this problem.

In the end, maybe the ADs can decide a way forward.

> This functionality itself is application agnostic and requires an
> interoperable solution for it to be beneficial.  This has nothing to
> do with content itself; it is purely about sharing information that
> helps with peer selection.

Protocols like BitTorrent already contain elements such that
the peers know enough about other peers that the overlay is
functioning.  The information that BitTorrent (and other P2P
overlays) do not have is topology and policies.  This is where
ALTO is urged to fill a crucial gap, at least initially.

Since the IETF/MIT workshop, the problem outlined for what has
become ALTO has been how to choose the peers wisely.  We (i.e.,
the BoF/list participants) have been diligent to note that
ALTO is not completely dependent on service providers; third
parties can run ALTO servers as well; and these servers can use
ad-hoc techniques like Ono (which was discussed yesterday on
the list) or some form of Internet Coordinate Systems to derive
a topology.  We have also been diligent to note that ALTO is an
additional service provided to an overlay; the overlay will
continue to function without it (albeit in a bit of a sub-optimal
manner.)  We have also noted given a choice between a service
provider run ALTO server and a third party ALTO server, that
peers will naturally gravitate towards the ALTO server
that provides them the best information over a long period
of time.

In other words, we have covered substantial grounds since
the IETF/MIT workshop and the Dublin BoF based on the
premise of the problem as the group has understood it.

Thanks,

- vijay

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 15 Oct 2008 11:39:57 -0700

On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani <[email-masked]>wrote:

> Narayanan, Vidya wrote:
>
> Peer selection is important to ISPs from a network utilization perspective
>> and to peers themselves from a performance perspective. That automatically
>> makes peer selection a function of multiple aspects - a) information that
>> some service providers may decide to share with the peers, b) information
>> that peers decide to make available about themselves to other peers for this
>> purpose, and, c) any measurements peers may do on their own.  The current
>> charter definition (and from what I can tell based on your response below)
>>  ALTO and something that peers can additionally do.  I strongly believe
>> that b) should be part of the ALTO work.
>>
>

There's plenty of work to do in a).  My recommendation based on estimation
of appropriate scope as well as an estimation of the consensus here, would
be to do that first -- to have a charter that is scoped to (a).  Then the
possibilities for (b) include working in the P2P research group, individual
submissions, and /or a new BoF/WG.  Another option would be a future charter
update for ALTO if it's successful and there's consensus for it to be the
basis for (b).

Lisa

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 15 Oct 2008 16:47:45 -0700

Lisa,

>
>
> There's plenty of work to do in a).  My recommendation based
> on estimation of appropriate scope as well as an estimation
> of the consensus here, would be to do that first -- to have a
> charter that is scoped to (a).  Then the possibilities for
> (b) include working in the P2P research group, individual
> submissions, and /or a new BoF/WG.  Another option would be a
> future charter update for ALTO if it's successful and there's
> consensus for it to be the basis for (b).
>

This would be a big mistake on our part.  b) is not a research problem and it is very much related to the same problem being solved in ALTO.  Letting each p2p application come up with its own mechanism of doing b) only kills the interoperability and extensibility.  We keep talking about scope creep here, but, we seem to miss something critical.  By not keeping the related problems together in producing solutions, we are only increasing the number of different mechanisms that are going to be needed in future to provide this one service - I cannot understand why that is a good thing.

Without allowing for b), I think information that a) gives you can be more or less useless in some circumstances.  Let me provide some additional context here.  One of the pieces of information that is important to allow wireless devices to participate in p2p networks is the basic fact that a given node is wireless.  This may place some fundamentally different criteria on path selection decisions that cannot be deduced simply with topology information.

For any forward looking work we do at the IETF, we must stop designing just for wired (and stationary) devices.  These are the designs that tend to look horrible when adapted to the wireless (and mobile) world and I seriously hope that that is not where we are headed with this work.

Best regards,
Vidya

---

From: Laird Popkin <[email-masked]>
Date: Wed, 15 Oct 2008 15:35:19 -0400 (EDT)

I agree that (a) is where ALTO should focus. 

To elaborate a bit, (a) can only be provided by the ISP by definition (nobody else really knows the ISP's network and business policies), while (b) and (c) are, if I understand you correctly, both currently being done using internal communications within the p2p applications using their existing protocols. IMO, standardizing (a) is very important because it allows ISPs to provide information to applications that that they can't otherwise get (e.g. ISP policies) or can only derive in complex, inaccurate ways (e.g. using hop counts to approximate network locality). 

----- Original Message ----- 
From: "Lisa Dusseault" <[email-masked]> 
To: "Vijay K. Gurbani" <[email-masked]> 
Cc: [email-masked], [email-masked] 
Sent: Wednesday, October 15, 2008 2:39:57 PM (GMT-0500) America/New_York 
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) 

On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani < [email-masked] > wrote: 

Narayanan, Vidya wrote: 

Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own.  The current charter definition (and from what I can tell based on your response below) only seems to allow for a).  I would agree that c) is out of scope of 
 ALTO and something that peers can additionally do.  I strongly believe that b) should be part of the ALTO work. 

There's plenty of work to do in a).  My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a).  Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG.  Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b). 

Lisa  

_______________________________________________ p2pi mailing list [email-masked] https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 16 Oct 2008 15:34:06 -0400

Vidya,

>This would be a big mistake on our part.  b) is not a research problem
and it is very much related to the same problem being solved in ALTO.

Personally, I can see that there is value in "b): information that peers
decide to make available about themselves to other peers for this
purpose". Your example below was information about whether a client is
on a wireless network. In an earlier thread, I had suggested that
clients may want to reveal their "available access bandwidth" in a
similar fashion; see
<http://www.ietf.org/mail-archive/web/p2pi/current/msg00658.html>. So
even as an "ISP person", I can see where you are coming from.

But if I am interpreting RFC 2418 correctly
<http://tools.ietf.org/html/rfc2418>, it is not sufficient to decide if
"b)" is a worthy IETF activity, but that there are enough participants
working on "b)" for an IETF effort to be successful. Quoting from parts
of RFC 2418 section 2.1:

"Is there sufficient interest within the IETF in the working group's
topic with enough people willing to expend the effort to produce the
desired result (e.g., a protocol specification)?"

"Is there enough expertise within the IETF in the working group's topic,
and are those people interested in contributing in the working group?"

"Does a base of interested consumers (end-users) appear to exist for the
planned work?  Consumer interest can be measured by participation of
end-users within the IETF process, as well as by less direct means."

You said:

>Given that Lisa is looking for solutions, I almost wish I have a
solution thought out :) But, I don't.

Are you volunteering to work on requirements and/or solutions for "b)"?
Would others?

(I may be interested and supportive in the future, although right now I
am predictably focused on activities related to "a)".)

If there isn't a quorum to work on "b)" right now, this could be
revisited in the future with a re-charter of ALTO, when such a quorum
does exist.

If there is a quorum, it would be helpful to hear about it.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Narayanan, Vidya
Sent: Wednesday, October 15, 2008 7:48 PM
To: Lisa Dusseault; Vijay K. Gurbani
Cc: [email-masked]; [email-masked]
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
(alto)

Lisa,

> consensus for it to be the basis for (b).

This would be a big mistake on our part.  b) is not a research problem
and it is very much related to the same problem being solved in ALTO.
Letting each p2p application come up with its own mechanism of doing b)
only kills the interoperability and extensibility.  We keep talking
about scope creep here, but, we seem to miss something critical.  By not
keeping the related problems together in producing solutions, we are
only increasing the number of different mechanisms that are going to be
needed in future to provide this one service - I cannot understand why
that is a good thing.

Without allowing for b), I think information that a) gives you can be
more or less useless in some circumstances.  Let me provide some
additional context here.  One of the pieces of information that is
important to allow wireless devices to participate in p2p networks is
the basic fact that a given node is wireless.  This may place some
fundamentally different criteria on path selection decisions that cannot
be deduced simply with topology information.

For any forward looking work we do at the IETF, we must stop designing
just for wired (and stationary) devices.  These are the designs that
tend to look horrible when adapted to the wireless (and mobile) world
and I seriously hope that that is not where we are headed with this
work.

Best regards,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Oct 2008 13:57:44 -0700

To answer your question about participation, I can definitely volunteer to work on the requirements and solution for this effort.  We will try to produce a draft explaining the problem and need for peer participation in ALTO by the deadline for Minneapolis.

With respect to process, I think this one takes the cake among abominations.  Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process.  Here we have an effort that started with a closed/gated workshop outside the IETF, was brought into the IETF as a BoF in RAI that ended in an inconclusive manner and transitioned now into a WG proposal for APP with little to no explanation to the wider audience on the rationale.  So, it may be best if we didn't really get into the process discussion with this effort.

I'm just hoping that at this stage, the ADs are going to hear all opinions and also use technical judgment on the relative points that are being made.

Best regards,
Vidya

> From: Woundy, Richard [mailto:[email-masked]]
> Sent: Thursday, October 16, 2008 12:34 PM
> To: Narayanan, Vidya; Lisa Dusseault; Vijay K. Gurbani
> Personally, I can see that there is value in "b): information
> that peers decide to make available about themselves to other
> peers for this purpose". Your example below was information
> about whether a client is on a wireless network. In an
> earlier thread, I had suggested that clients may want to
> reveal their "available access bandwidth" in a similar
> fashion; see
> <http://www.ietf.org/mail-archive/web/p2pi/current/msg00658.ht
ml>. So even as an "ISP person", I can see where you are coming > from.
> <http://tools.ietf.org/html/rfc2418>, it is not sufficient to
> decide if "b)" is a worthy IETF activity, but that there are
> enough participants working on "b)" for an IETF effort to be
> successful. Quoting from parts of RFC 2418 section 2.1:
>
> "Is there sufficient interest within the IETF in the working
> group's topic with enough people willing to expend the effort
> to produce the desired result (e.g., a protocol specification)?"
>
> "Is there enough expertise within the IETF in the working
> group's topic, and are those people interested in
> contributing in the working group?"
>
> "Does a base of interested consumers (end-users) appear to
> exist for the planned work?  Consumer interest can be
> measured by participation of end-users within the IETF
> process, as well as by less direct means."
>
> You said:
>
> (I may be interested and supportive in the future, although
> right now I am predictably focused on activities related to "a)".)
>
> If there isn't a quorum to work on "b)" right now, this could
> be revisited in the future with a re-charter of ALTO, when
> such a quorum does exist.
>
> Behalf Of Narayanan, Vidya
> > There's plenty of work to do in a).  My recommendation based on
> > estimation of appropriate scope as well as an estimation of the
> > consensus here, would be to do that first -- to have a
> charter that is
> > scoped to (a).  Then the possibilities for
> submissions,
> > and /or a new BoF/WG.  Another option would be a future
> charter update
> > for ALTO if it's successful and there's consensus for it to be the
> > basis for (b).
> >
>
> This would be a big mistake on our part.  b) is not a
> research problem and it is very much related to the same
> problem being solved in ALTO.
> Letting each p2p application come up with its own mechanism
> of doing b) only kills the interoperability and
> extensibility.  We keep talking about scope creep here, but,
> we seem to miss something critical.  By not keeping the
> related problems together in producing solutions, we are only
> increasing the number of different mechanisms that are going
> to be needed in future to provide this one service - I cannot
> understand why that is a good thing.
>
> Without allowing for b), I think information that a) gives
> you can be more or less useless in some circumstances.  Let
> me provide some additional context here.  One of the pieces
> of information that is important to allow wireless devices to
> participate in p2p networks is the basic fact that a given
> node is wireless.  This may place some fundamentally
> different criteria on path selection decisions that cannot be
> deduced simply with topology information.
>
> For any forward looking work we do at the IETF, we must stop
> designing just for wired (and stationary) devices.  These are
> the designs that tend to look horrible when adapted to the
> wireless (and mobile) world and I seriously hope that that is
> not where we are headed with this work.
>
> Best regards,
> Vidya
>
> > Lisa
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Oct 2008 16:20:20 -0700

> Sent: Friday, October 17, 2008 2:32 PM
> To: Narayanan, Vidya
> > With respect to process, I think this one takes the cake among
> > abominations.  Having been at the IETF long enough and having
> > participated in several BoFs, I'm quite familiar with
> RFC2418 and the
> > process.  Here we have an effort that started with a closed/gated
> > workshop outside the IETF,
>
> Actually, this is not so.  The workshop *was* sponsored by
> IETF; the RAI area, to be more precise (please see
> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg
04758.html).

My point is that this was a closed effort - it was not a meeting that was open to all for attendence.  The fact that the RAI ADs decided to do this doesn't automatically make it "IETF sponsored".  Not to mention that the topics covered by this workshop or the scope of it was not really open to discussion at the IETF.  All of this makes it sqauarely an effort outside the IETF and let's not try to pretend it was somehow as open as other IETF efforts.

But, let's get past that itself and focus on how to make the best of the effort going forward.

Regards,
Vidya

> The initial notes from the workshop are also archived at
> http://www.ietf.org/mail-archive/web/p2pi/current/msg00025.html.
>
> Thanks,
>
> - vijay
> --

---

From: Enrico Marocco <[email-masked]>
Date: Sun, 19 Oct 2008 19:23:09 +0200

Narayanan, Vidya wrote:
>>> participated in several BoFs, I'm quite familiar with RFC2418 and
>>> the process.  Here we have an effort that started with a
>>> closed/gated workshop outside the IETF,
>> Actually, this is not so.  The workshop *was* sponsored by IETF;
>> the RAI area, to be more precise (please see 
> My point is that this was a closed effort - it was not a meeting that
> was open to all for attendence.  The fact that the RAI ADs decided to
> do this doesn't automatically make it "IETF sponsored".  Not to
> mention that the topics covered by this workshop or the scope of it
> was not really open to discussion at the IETF.  All of this makes it
> sqauarely an effort outside the IETF and let's not try to pretend it
> was somehow as open as other IETF efforts.

This is simply not true. The P2PI workshop was open to all (including
via jabber) and its main goal, as I read it, was to put together people
interested in addressing the issues P2P traffic poses for Internet
infrastructures. After that, two BOFs had been organized, in the very
same way BOFs are usually organized: some people get together, draft a
problem statement, set a mailing list up, add an entry in the BOF page,
involve the community, discuss, ask a meeting slot during an official
meeting, discuss, draft a charter, discuss, discuss... In a word, as
described in draft-narten-successful-bof.

Unfortunately it isn't possible to measure how much open an effort is,
but if you accept the number of contributions and contributors (as per
3978) as a somewhat meaningful indicator, for ALTO you can count 561
messages posted on the list by 67 different authors (from 6/9, when the
first BOF was announced, to 9/30, when LC began) and 6 I-Ds co-signed by
19 people (Authors and Contributors). Now, if you consider that no one
of such contributors have complained about feeling excluded and instead
all have agreed to move forward with the proposed charter (in fact they
have contributed to the proposed charter), I wouldn't say that it has
been a closed effort.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 17 Oct 2008 16:31:56 -0500

Narayanan, Vidya wrote:
> participated in several BoFs, I'm quite familiar with RFC2418 and the

Actually, this is not so.  The workshop *was* sponsored by IETF;
the RAI area, to be more precise (please see
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04758.html).

Thanks,

- vijay

---

From: <[email-masked]>
Date: Mon, 20 Oct 2008 15:23:53 +0100

Just catching up on some of the traffic in this list.

I think the openness of the ALTO effort is highlighted by the fact that
currently this is the busiest out of the 8 IETF lists I subscribe to...
In the IETF vigorous mailing activity is a better signal than any other
of the level of interest in a topic and thus the level of involvement in
the wider community.

Regarding the workshop, it was pretty open. It was widely advertised,
albeit at short notice. Seemingly the majority of submissions were
accepted (impressive given the short time available in the workshop).
Copies of all the documents and presentations are available and the
output was to convince several ADs of the need for new work at the IETF
(hence two BoFs and probably eventually 2 WGs).

As to including your point b). Lisa correctly pointed out that the main
reason the BoF in Dublin failed was a lack of focus in ALTO. What you
are proposing sounds like an interesting work item for a different WG or
more likely an IRTF RG given you admit you don't know of any proposals
out there currently. However adding it to ALTO would just scupper the
next BoF and thus kill the work completely.

I think Lars summed up the ideal aims of ALTO best: 

"The intent here isn't that ALTO would pick the globally optimal peers
for you, the intent is that it'll help an application reach a good set
of peers a bit more quickly." 

In other words ALTO will be great so long as it is lightweight and has
sensible ambitions!

Toby

____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Enrico Marocco
Sent: 19 October 2008 18:23
To: Narayanan, Vidya
Cc: [email-masked]; [email-masked]
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
(alto)

Narayanan, Vidya wrote:
>> Actually, this is not so.  The workshop *was* sponsored by IETF; the 
>> RAI area, to be more precise (please see

---

From: Laird Popkin <[email-masked]>
Date: Mon, 20 Oct 2008 10:27:03 -0400 (EDT)

I'd like to second this - the P2Pi workshop was open and well publicized. While I've not been involved in the IETF for a long time, I heard about it through several channels, submitted a paper, presented, etc.

Of course, I can't prove that someone else didn't feel excluded, but from my perspective the process has certainly appeared open. Does anyone else feel like this process hasn't been open to all interested parties? 

----- Original Message -----
From: "Enrico Marocco" <[email-masked]>
To: "Vidya Narayanan" <[email-masked]>
Cc: [email-masked], [email-masked]
Sent: Sunday, October 19, 2008 1:23:09 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

-- 
Ciao,
Enrico

---

From: Ted Hardie <[email-masked]>
Date: Mon, 20 Oct 2008 10:05:05 -0700

Howdy,
	There has been a lot of traffic in the past few days on
the question of whether the recent p2pi workshop was or was not
"open".  Having sent a paper in to that workshop and participated
in an apps-area workshop, I'd like to weigh in on the question with
a fairly blunt reply:  not fully.  Whenever participation is gated
by a committee, it is not fully open.  In the p2pi case, Jon and Cullen
acted as the gates; they swung wide (thanks, guys!), but you
had to either submit a position paper and have it approved by
them or get a waiver from them.  To quote from their mail of
May 2nd:

>We've had a number of inquiries from people interested in the workshop
>who are reluctant to submit a paper because they have no particular
>agenda to push in this space. We'd like to stress that position papers
>can shed light on any aspect of the problem or solution space, and we'd
>encourage anyone interested in making a technical contribution to
>ongoing work in this space at the IETF to submit a paper even if it
>serves only to further explain the problem, the requirements, or even
>the non-requirements associated with this work.
>
>That much said, if it is not appropriate for you to submit a position
>paper, please contact Cullen and Jon by May 9th to request a waiver. You
>can reach us at: [email-masked], [email-masked]

	That doesn't really matter, though.  What matters is that
workshops like this are inputs into an open process (in this case, the BoF, in
the APPs workshop a list of potential work items).  Anyone could
participate in the BoF or on the mailing list, and that is where we
have to make sure that the full openness remains.  The discussion
now of the scope of the work in this proposed working group is a
critical part of that openness, as it is *the* time early in the process
when the IETF community as a whole considers a proposed
work plan and commits to it.  ALTO is getting very good feedback,
and I hope that its Area Directors (and any potential chairs) are
listening to it; it's heartening to see the level of interest here when
so many WGs are chartered or re-chartered with no comments at all.

	I hope we can stop focusing on the openness of the workshop
as a primary topic in this conversation, and focus on keeping the
proposed working group open to input at this pivotal moment.  Having
hummed for the creation of the WG at the BoF, I obviously support the
creation of a WG now.  But I'm much, much happier getting the input
on charter details dealt with now, as a good discussion now can avoid
lots of later stress on the working group machinery.

				regards,
					Ted Hardie

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 21 Oct 2008 07:35:59 -0400

Ted,

I was at the workshop representing the IAB, and I fully agree. While
it was held in a good-sized auditorium, given the obvious interest in
the topic, if everyone who wanted to attend or get on the agenda
could, we would have needed a venue two or three times the size, more
administrative support, and probably have needed to extend the
workshop over at least two days. Given the size of the venue and the
time available, I thought the way the workshop was conducted was
extremely reasonable and fair.

Cheers,
Andy

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 21 Oct 2008 13:43:30 -0700

Hey, stupid thought...

Could you do proximity based on "who's your DNS resolver"?  Do a few  
name lookups: one to register YOU as using YOUR DNS resolver to the  
remote coordinator, and one to get "who are other peers using the same  
resolver"?

An ugly, UGLY hack, but it might be interesting to think about.

Has anyone done this already?

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 21 Oct 2008 15:27:51 -0700

> over existing p2p usage and traffic management.

I also believe that an ALTO WG should be formed and would like to  
contribute to a solutions draft.

The current requirements and problem statement are scoped rather  
narrowly around a solution in mind.  This is recognized by the BoF  
chairs and the authors, and I would be interested in contributing to  
these documents so that they more generally applicable.

A solutions draft should be a start to help think about the solutions  
space.  The starting point for the solutions idea is described at http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html

This is intended to answer Lisa's call for example candidate solutions  
to better understand the space.  The solution will emphasize  
simplicity, privacy, and, correspondingly, clear understanding of what  
information is given to whom.

The question at hand is not consensus on the requirements or even  
problem statement, but just the charter.

I believe the charter has by now been crafted with the intention of  
covering the known cases.

One small concern that I didn't previously raise because I just  
noticed it is that the charter still says
"A request/response protocol for querying the ALTO service to obtain
   information useful for peer selection, and a format for requests and
   responses."

This starts to specify an architecture.  While the known candidate  
solutions seem to fit, I would prefer clarifying that it's not request/ 
response protocol or data format that's the point, but the information.

One way of doing so would to to rephrase as follows:

"A complete mechanisms that enables clients to learn from the ALTO  
service information useful for peer selection."

Again, this should go forward.

Thanks,  -- Stas

--
Stanislav Shalunov

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 22 Oct 2008 17:50:51 -0700

All,
We have submitted a draft explaining the overall problem of peer selection - http://www.ietf.org/internet-drafts/draft-saumitra-alto-multi-ps-00.txt.  

Below are my suggested revisions to the charter based on arguments the draft puts forth (and based on emails exchanged over the last several days). 

Thanks,
Vidya

> Application-Layer Traffic Optimization (alto) 

Add: "Peer selection is also a problem that has many different applications in p2p systems - e.g., identifying the best peer to download content from, identifying the best super peer to contact in a system, using the best relay for NAT traversal, identifying the best next hop for a query based on several criteria (e.g., quality, reputation, semantic expertise, etc.), etc." 

> locations, 

s/download locations/a list of peers

> yet applications have at best incomplete 
> information about the topology of the network. 

s/incomplete information about the topology of the network/incomplete information to help the selection, e.g., topology of the network. 

> Applications 
> factors including

s/including/such as

> maximum bandwidth, minimum cross-domain 

I propose deleting "identifying, for example, what kind of information  P2P applications will need for optimizing their choices".  

> responses.   

I suggest replacing this with Stanislav's suggestion: 

"A complete mechanism that enables clients to learn from the ALTO service information useful for peer selection".

> The WG does not require intermediaries between the ALTO
> server and the peer querying it.  

s/the ALTO server and the peer querying it/the communicating ALTO endpoints. 

> If the requirements 

The above seems okay. 

> once the work for the initial services has been completed.

I think we should delete the sentence above.  

> server could provide, the following criteria are important to 

In the context of standardization, I don't think we should be trying to evaluate the importance of any information.  The idea for us should be to standardize mechanisms to exchange peer selection related information.  The value of the actual information exchanged is very contextual and not for general evaluation.  

> to be able to provide or use that particular data.  

The above again gets into our evaluation of what is important based on what we know today and is limiting. 

> between applications and ALTO servers.  

s/applications and ALTO servers/ALTO endpoints

>Note that ALTO 
> other protocols for actually implementing ALTO servers

s/servers/services

---

From: Yu-Shun Wang <[email-masked]>
Date: Thu, 23 Oct 2008 09:04:30 -0700

Hi Vidya,

Comments inline. (I've only preserved the points I have
comments on. Others are fine with me.)

Thanks,
yushun

> Sent: Wednesday, October 22, 2008 5:51 PM
>

<...>

> Add: "Peer selection is also a problem that has many different
> applications in p2p systems - e.g., identifying the best peer to
> download content from, identifying the best super peer to contact in a
> system, using the best relay for NAT traversal, identifying the best
> next hop for a query based on several criteria (e.g., quality,
> reputation, semantic expertise, etc.), etc."

I actually think the proposed addition is somewhat redundant,
and could easily lead into ratholes on what are the metrics for
"best" and whether it is even possible to get the best. The
current charter tries to avoid that by saying "better-than-
random" selection gating mostly on getting better performance
and lowering the costs (as two examples). Also, what's the
"best" depends heavily on whom you ask. ISP's notions of "best"
may not align with those of the end users.

I am fine with the examples (targets for selections), but let's
try to avoid the debates on "best" again.

<...>

> s/incomplete information about the topology of the network/incomplete
> information to help the selection, e.g., topology of the network.

I'm neutral to this. I think the intention is to narrow the
initial scope to avoid confusion w/ TANA. The charter does
leave the door open to future re-chartering/work.

<...>

> I think we should delete the sentence above.

While it may seem redundant, I don't see anything wrong with
that. It just means we may have a narrow scope now, but we
will think about new extensions once we are done.

<...>

> In the context of standardization, I don't think we should be trying to
> evaluate the importance of any information.  The idea for us should be
> to standardize mechanisms to exchange peer selection related
> information.  The value of the actual information exchanged is very
> contextual and not for general evaluation.

I read the list below somewhat differently. These are not for
relative importance of the information, but kind of a min
bar for what we want to do. While some may need re-wording,
the intent is fine, IMO.

> > - Can a client get that information without excessive privacy
> >   concerns(e.g. by sending large lists of peers)?

This point does need some clarification and rewording.

Thanks,
yushun

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 23 Oct 2008 18:47:43 -0700

Hi Yushun, 

<snip>

> and could easily lead into ratholes on what are the metrics 
> for "best" and whether it is even possible to get the best. 
> The current charter tries to avoid that by saying 
> "better-than- random" selection gating mostly on getting 
> better performance and lowering the costs (as two examples). 
> Also, what's the "best" depends heavily on whom you ask. 
> ISP's notions of "best"
> I am fine with the examples (targets for selections), but 
> let's try to avoid the debates on "best" again.
> 

I'm fine with that.  I agree that "best" is a relative word and causes confusion at best :) 

<snip>

> will think about new extensions once we are done.

I actually believe that if we designed the protocols right, we don't need a recharter to carry other types of information - we can allow registration of new information types for ALTO beyond the life of the WG.  

<snip>

> relative importance of the information, but kind of a min bar 
> for what we want to do. While some may need re-wording, the 
> intent is fine, IMO.
> 

I'm not so sure.  Basically, it is a question of what usage these are evaluated based on.  Let's take a couple of examples.  Whether the ALTO service can provide a piece of information is dependent on various factors - some things are dependent on whether such information is available from other places today (e.g., topology or ASNs, etc.); I think this set of questions has been written with that mindset.  But, there are others (e.g., quality, reputation, semantic expertise, etc.) that are totally based on the type of the p2p overlay and whether clients can provide that information.  Similarly, whether some information is useful to a client is totally contextual to the application as well. 

> > The above again gets into our evaluation of what is 
> important based on 
> > what we know today and is limiting.
>

---

From: Yu-Shun Wang <[email-masked]>
Date: Fri, 24 Oct 2008 10:41:38 -0700

Hi Vidya,

> I actually believe that if we designed the protocols right, we don't
> need a recharter to carry other types of information - we can allow
> registration of new information types for ALTO beyond the life of the
> WG.

Agreed in principle, and I don't think anyone on the list would
disagree we should design an extensible protocol/solution. The
need for such wording is, imo, for the practical purpose of
scoping a working group. Any new type of info the wg considers
must be carefully evaluated for the impacts and such. The current
charter just says we will focus on the protocol and certain types
of info. Note that it doesn't say the protocol must NOT be
extensible. (If it does, then we should change that.)

<...>

> I'm not so sure.  Basically, it is a question of what usage these are
> evaluated based on.  Let's take a couple of examples.  Whether the ALTO
> service can provide a piece of information is dependent on various
> factors - some things are dependent on whether such information is
> available from other places today (e.g., topology or ASNs, etc.); I
> think this set of questions has been written with that mindset.  But,
> there are others (e.g., quality, reputation, semantic expertise, etc.)
> that are totally based on the type of the p2p overlay and whether
> clients can provide that information.  Similarly, whether some
> information is useful to a client is totally contextual to the
> application as well.

Once again, I don't think we are that far apart, and in a sense,
what is missing is really a note that the answers to these questions
largely depend on the type of info they apply to. Although I still
think these are fair questions to ask on the info under consideration.

I would totally agree that these need re-wording for clarity. Let's
wait for the next round of charter update. :-)

Thanks,
yushun