Subject: [P2PSIP] discussing P2PI-related standardization in Dublin

From: Lars Eggert <[email-masked]>
Date: Fri, 6 Jun 2008 15:58:11 +0200

Hi,

the recent workshop on P2P infrastructure (P2PI) has
resulted in several suggestions for future IETF work. Two of
the suggested work items are related to core TSV topics, and
a third has at least strong ties to TSV (but also to other
areas).

We'd be interested to hear from the community if we should
schedule a BOF in Dublin to discuss whether the IETF should
take on some or all of these, and if so, whether TSV would
be the right place for this work.

I'll be CC'ing this email to several lists. Please direct
your replies to the TSV area list ([email-masked]), so
that the discussion happens in one place.

The working title for the BOF is "Techniques for Advanced
Networking Applications" or TANA. The high-level idea is
that the IETF would develop guidelines, recommendations and
mechanisms for advanced applications that make intensive use
of Internet communication in a way that goes beyond the
capabilities offered by the IETF's current standard
end-to-end transport protocols. Such network-centric
applications include those that transmit delay-sensitive
traffic and those that transmit delay-insensitive traffic,
both using either peer-to-peer approaches or more
traditionally structured communication patterns. The work
would focus on broadly applicable techniques that address
the needs of large subsets of these class of network-centric
applications in a fashion that is independent of any
particular application.

The following three work items were identified as potential
new work for the IETF at the P2PI workshop. The first two
would be pretty clearly in scope for the TSV area, whereas
the third has some significant inter-area relations:

(1) A congestion control algorithm for
     less-than-best-effort "background" transmissions, i.e.,
     an algorithm that attempts to scavenge otherwise idle
     bandwidth for its transmissions in a way that minimizes
     interference with regular best-effort traffic. Among the
     desired features of such an algorithm are the ability to
     maintain short standing queues, the capability to quickly
     yield to regular best-effort traffic that uses standard
     congestion control, the ability to utilize explicit
     congestion notification (ECN), active queue management
     (AQM), and/or end-to-end differentiated services
     (DiffServ) where available, as well as effective
     operation in situations where some or all of these
     mechanisms are not available. In addition to specifying a
     congestion control algorithm, the work may also include
     specifications of how the algorithm is used in specific
     UDP-based protocols. (Application of the algorithm to
     other transport protocols is expected to occur in the
     working groups that maintain those protocols.) This work
     item has relations to IETF WGs that deal with congestion
     control, such as TCPM, DCCP and TSVWG, as well as the
     IRTF's congestion control research group (ICCRG).

(2) A guidelines document that discusses the tradeoffs
     surrounding the use of many concurrent transport
     connections to one peer and/or to different peers.
     Standard Internet congestion control results in a state
     where different transport connections end up sharing
     bottleneck capacity, and when an application uses several
     transport connections to transfer through a bottleneck,
     it tends to end up with a larger fraction of the
     bottleneck's loaded resource than if it would be using
     fewer connections. Note that although capacity is the
     most commonly considered bottleneck resource, middlebox
     state table entries are a second important resource for
     end system communication. Other resource types may exist,
     and the guidelines are expected to comprehensively
     discuss them.

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

Please send your thoughts on these three topics.

These three work items aren't necessarily the only ones that
the IETF could think about taking on; they merely appeared
to be the most concrete ones coming out of the P2PI
workshop. We could think about discussing additional work
items in Dublin - please write up a short description
(similar to the ones above), so we can discuss them.

Lars

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 6 Jun 2008 16:40:36 +0200

Hi,

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.

Lars

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 06 Jun 2008 11:36:17 -0500

>      an algorithm that attempts to scavenge otherwise idle
[...]

I ran across the following references today that I thought
may be pertinent to congestion control in DHT algorithms.
I do not think they operate on the scavenger principle,
nor do I remember them as references in the P2Pi workshop
set of papers.

Fabius Klemm, Jean-Yves Le Boudec, Karl Aberer: Congestion
Control for Distributed Hash Tables. The 5th IEEE International
Symposium on Network Computing and Applications (IEEE NCA06),
Cambridge, MA, USA, July 24 - 26, 2006 (available online at
http://lsirpeople.epfl.ch/klemm/Congestion%20Control%20for%20Distributed%20Hash%20Tables.pdf)

Fabius Klemm, Jean-Yves Le Boudec, Dejan Kostic, Karl Aberer:
Improving the Throughput of Distributed Hash Tables Using
Congestion-Aware Routing. International Workshop on Peer-to-Peer
Systems (IPTPS'07), Bellevue, WA, USA, February 26.-27, 2007
(available online at
http://lsirpeople.epfl.ch/klemm/Improving%20the%20Throughput%20of%20Distributed%20Hash%20Tables%20Using%20Congestion-Aware%20Routing.pdf)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 9 Jun 2008 16:40:07 -0400

The proposal for the ALTO BoF (which roughly covers (3)) is now in the
BoF tracker. You can read about it at its home page:

http://alto.tilab.com/

ALTO proposes to explore a slightly broader space than merely P2P
file-sharing applications, since discovery of nearby peers has equal
applicability to many real-time communications protocols (for example,
the discovery of a TURN server to assist the establishment of a VoIP
session). Although RAI proposes to sponsor a BoF on this subject, we're
not yet persuaded that RAI would be the optimal home for any ongoing
work efforts related to this space - we hope that discussions
surrounding the BoF could elucidate the proper division of labor and
approach to this problem.

I do believe this work effort is sufficiently distinct from the
transport issues discussed in (1) and (2) of Lars' original mail to
merit a separate effort. I do, however, whole-heartedly support TSV
taking on (1) and (2) in a forum like TANA. 

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars Eggert
Sent: Friday, June 06, 2008 7:41 AM
To: TSV Area
Cc: [email-masked]; [email-masked] IAB; [email-masked]; IESG ((E-mail));
P2PSIP Mailing List
Subject: Re: discussing P2PI-related standardization in Dublin

Hi,

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 13 Jun 2008 19:39:35 +0300

Hi,

> 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-masked] mailing list, in order to discuss the  
transport implications of the various ALTO ideas.

Lars