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 (tsv-area@ietf.org), 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