Hi, On 2008-6-6, at 17:40, ext Lars Eggert wrote: > related to the work item below, I've just heard that some folks had > already been discussing the submission of a more targeted BOF > proposal. Depending on the details of that proposal (which I haven't > seen yet), work item (3) might be subsumed by it.
this BOF proposal has now materialized in form of ALTO (http://alto.tilab.com/ ), a BOF proposal targeted at APP and RAI. It's hence somewhat likely that we may have a TANA BOF in TSV that focuses on the work items (1) and (2) from my original email, and a second ALTO BOF hosted by APP and RAI. (Note: this email is *not* an IESG approval of either the TANA or ALTO BOF - those will come from the responsible ADs if and when they come.) ALTO is currently scoped a bit more broadly than the TANA work item (3) was, and some of the broader proposals in the ALTO space could lead to significant transport issues. A fraction of the ALTO proponents argues to exchange information related to end-to-end performance (bandwidth, RTT, congestion, transfer time estimates, etc.) through the oracle, for example. I'd like to ask transport folks to participate in the discussion on ALTO on the [EMAIL PROTECTED] mailing list, in order to discuss the transport implications of the various ALTO ideas. > On 2008-6-6, at 15:58, Lars Eggert wrote: >> (3) A mechanism that lets an application that can >> transfer data from or to several potential peers (i.e., >> servers, caches, end systems) select a subset of peers >> for efficient transmission in a way that is aligned with >> the dynamic interconnection structure of the network >> operators that provide connectivity to those peers. >> Application designers, network equipment vendors and >> network operators will need to collaborate on this work >> item to define what kinds of dynamic interconnection >> information is useful to applications, how to obtain it, >> and how to provide it to applications, resulting in a >> generic mechanism that is broadly applicable to many >> current and future applications. This work item has >> obvious interactions with the IETF's Application, Routing >> and Operations areas. In order to make this effort more >> manageable, it may make sense to work out the >> requirements for such a solution first, before discussing >> individual proposals or breaking up the work into pieces >> for specification in different areas or WGs. Lars _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
