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 PROTECTED]), 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 protected]
https://www.ietf.org/mailman/listinfo/p2psip
