Network Working Group S. Das
Internet-Draft V. Narayanan
Intended status: Standards Track L. Dondeti
Expires: April 26, 2009 Qualcomm, Inc.
October 23, 2008
ALTO: A Multi Dimensional Peer Selection Problem
draft-saumitra-alto-multi-ps-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2009.
Abstract
Bulk data applications are posing serious challenges to the Internet
infrastructure and more mass adoption of such applications would only
increase that challenge. P2P bulk data applications and other large
volume HTTP traffic such as video currently dominate the Internet
traffic. These applications do not generally benefit from the
traffic engineering techniques developed for the Internet. In the
HTTP traffic case, the traffic optimization issues are often
addressed using the CDN infrastructure. For P2P bulk data
applications, the problem is about picking the right peers to
communicate with and the criteria for doing this vary greatly based
on the application. Hence, intelligent peer selection is the
Das, et al. Expires April 26, 2009 [Page 1]
Internet-Draft multi October 2008
fundamental problem to address for these applications. This document
explains the multiple dimensions of the peer selection problem with
respect to obtaining information from the network as well from other
peers and argues for an integrated, common framework to share such
information.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Network-assisted ALTO . . . . . . . . . . . . . . . . . . 6
3.2. Peer-assisted ALTO . . . . . . . . . . . . . . . . . . . . 6
3.3. The need for multiple criterion . . . . . . . . . . . . . 6
3.3.1. Peer-assisted ALTO alone . . . . . . . . . . . . . . . 7
3.3.2. Network-assisted ALTO alone . . . . . . . . . . . . . 7
3.4. Applicability and Discussion . . . . . . . . . . . . . . . 8
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Das, et al. Expires April 26, 2009 [Page 2]
Internet-Draft multi October 2008
1. Introduction
A large portion of the Internet traffic today is from P2P (peer-to-
peer) applications. Such an architecture for data transfer is
attractive because it reduces the bandwidth costs of the content
provider since they simply need to seed the content to a few nodes in
the network which would then contribute upload bandwidth to assist
the content provider's servers in the data transfer. Thus, the
single point bottleneck at the content provider is eliminated and
both users and content providers benefit.
However such an approach is detrimental to another important entity
in the system: the ISPs. While p2p has led to increased popularity
of broadband connections and arguably increased subscribers for ISPs;
it has also increased traffic costs for the ISPs. This is because
P2P applications' peer selection does not consider underlying network
topology and link costs in that topology. Most p2p applications
typically are only interested in improving their data transfer
performance which is satisfied if the download link of the user is
saturated. As shown in [2], traffic generated by popular P2P
applications often cross network boundaries multiple times,
overloading links which are frequently subject to congestion [3].
This happens because most p2p applications simply use random peer
selection followed by monitoring and reevaluation. Even if p2p
applications perform some network measurements, these typically tend
to be round trip time estimation which may or may not lead to peer
selection conducive to ISP interests.
This led to ISPs efforts at shaping or blocking P2P traffic on
specific ports. In response, p2p applictions started using dynamic
ports to transfer data following whcih ISPs had to use deep packet
protocol specific information to shape p2p flows. In response, p2p
applications have started encrypting their connections. The use of
TCP RST messages to deter costly p2p application data transfer has
led to some conflicts as well. It is in the ISP's interests to avoid
the cat-and-mouse games of protocol-specific detection and mitigation
while still not having to increase costs significantly to accomodate
p2p traffic.
One way to reduce the impact on ISPs would be the deployment of
caching entities in the networks to reduce cross-ISP traffic and
network distance of data transfer. However such an approach has
several issues:
o It is not clear who would deploy these high-bandwidth large-
storage capable caches since it can be argued that caching pushes
the costs from the content provider to the ISPs
Das, et al. Expires April 26, 2009 [Page 3]
Internet-Draft multi October 2008
o The caches would need to be able to cache data from all p2p
applications and consequently become complicated to deploy and
maintain over time as p2p application evolve
o The use of caches opens up the issue of storage of copyrighted
content
Thus, a solution is needed that can allow for peer selection by the
p2p application themselves that is friendly to the ISP's network
costs while being friendly to the applications' objective of good
performance for the user.
Recent studies [4], [5], [6] have suggested that it may be possible
to reduce the impact that P2P applications have on ISPs traffic
costs. This is mainly achieved by informed peer selection in the P2P
applications guided by network level metrics instead of random
selection. However, p2p applications do not have a trust
relationship with network operators and what may be good for the ISP
is not necessarily good for the performance of the p2p applications.
These competing interests necessitate a solution for ALTO that
addresses the interests of both the entities in the system.
This document describes the problem of optimizing traffic generated
by P2P applications using information provided by third parties, i.e.
the other peers in the network or the network operator. The overall
goal of optimizing the P2P application is for them to become more
network-friendly, while at the same time allowing the networks to
remain application-friendly. The following are key arguments that we
put forth in this draft:
o The problem of peer selection needs to take into account the
interests of the ISPs, application providers and the peers. The
goal should be to reduce the impact on ISP without sacrificing the
performance of p2p applications. There are many situations we
elaborate upon in Section 3 where simply considering ISP interests
leads to poor performance for p2p applications. Information about
peer connectivity characteristics is an important component of the
ALTO problem of peer selection (in conjunction with ISP routing
information) and together with network topology information, can
enable peers to optimize their performance as well as take into
account ISP interests.
o An ALTO system with information about ISP routing alone does not
provide enough incentives for adoption in p2p applications, due to
the competing interests of the two parties and the lack of trust.
Combining both elements of peer selection creates an incentive for
p2p applications to actually use the ALTO service.
Das, et al. Expires April 26, 2009 [Page 4]
Internet-Draft multi October 2008
o Application-specific solutions for sharing peer connectivity
characteristics are inefficient and cause unnecessary overhead in
the network. A common information plane allows reuse of such
information across a wide range of applications ranging from DHT
next hop selection, multi-source file download, relay selection,
mirror selection, etc., since many of the connectivity
characteristics of peers such as upload/download bandwidth,
network coordinate, wireless link information are useful to a
multitude of p2p applications in peer selection.
The rest of this draft is structured as follows. Section 3
introduces the problem and argues for the multiple criterion that
need to be considered when developing solutions, while Section 4
describes the design goals of the system.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
3. Problem Statement
Bulk data applications are posing serious challenges to the Internet
infrastructure and more mass adoption of such applications would only
increase that challenge. P2P bulk data applications and other large
volume HTTP traffic such as video currently dominate the Internet
traffic. These applications do not generally benefit from the
traffic engineering techniques developed for the Internet. In the
HTTP traffic case, the traffic optimization issues are often
addressed using the CDN infrastructure. For P2P bulk data
applications, the problem is about picking the right peers to
communicate with and the criteria for doing this vary greatly based
on the application. Hence, intelligent peer selection is the
fundamental problem to address for these applications.
One necessary input for intelligent peer selection has been shown to
be network topology information. And, accurate network topology
information can only be obtained with the help of ISPs. However,
there is more to peer selection than just network topology
information.
Consider a Client Application at node A which wants to access a
service for peer selection such as ALTO. Overall peer selection in
ALTO can be performed using two sets of information: (1) One set of
information is that from the network, i.e. network-assisted ALTO
Das, et al. Expires April 26, 2009 [Page 5]
Internet-Draft multi October 2008
which promotes peer selection that is beneficial to the ISP by either
reducing the interdomain traffic or reducing congestion on bottleneck
links inside the ISP. (2) The other set of information is from the
set of potential Client Application Providers are targets for peer
connectivity, i.e. peer-assisted ALTO.
3.1. Network-assisted ALTO
Network-assisted application layer traffic optimization refers to the
use of network operators in guiding peer selection for p2p
applications. Network operators can use network topology and traffic
statistics to provide hints to the P2P applications on which hosts it
would prefer the application pick for data transfer. For example,
peers that involve inter-domain routing would be given lower priority
in the response to the querying P2P application. Another example
would be that peers whose connectivity is such that their choice
would increase the congestion on an already congested link inside the
ISP. Such peers would also be given lower priority. Some recent
work has proposed solutions in this space [5],[4].
3.2. Peer-assisted ALTO
Peer-assisted application layer traffic optimization refers to the
use of published information about peers and their connectivity to
the Internet in guiding peer selection for p2p applications. For
example, BitTorrent-like data transfer applications would query
metrics related to the peer of interest to decide on the peers to
select for initial data transfer. This information could be for
example the upload bandwidth of the peer. These choices could then
be refined or changed by monitoring data connections. Another
example would be for VoIP applications to query the ALTO service for
peers that it wants to use as relays to find one with low latency.
Altough latency information is pairwise the peer could publish its
network coordinate calculated by a system such as GNP (Global Network
Positioning) into the ALTO service which could then be retrieved and
used by a querying peer to estimate network latency. Publishing peer
connectivity could also involve edge-specific information such as
which cell id a peer is connected to in a cellular network so that
another peer in the same cell is discouraged from making a connection
within the same cell to minimize the congestion and avoid occuping 2
downlink and 2 uplink channels in the same cell. This type of
traffic optimization cannot be acheived via network-assisted ALTO.
3.3. The need for multiple criterion
This section justifies the need for multiple criterion in ALTO: i.e.
the need for both ISP related information and peer related
information. Note that the underlying assumption is that peers and
Das, et al. Expires April 26, 2009 [Page 6]
Internet-Draft multi October 2008
ISPs may not necessarily trust each other and thus any solution in
this space needs to consider the interests of both parties.
3.3.1. Peer-assisted ALTO alone
It is already well known that using peer related information alone is
not enough. Simply randomly selecting peers and trying them out and
reevaluating the choices based on observed performance is suboptimal
as it takes time to converge on a good set of peers as well as causes
unnecessary overhead in the network. Incorporating locality into
peer selection using either active measurements or some sort of
information plane (e.g. [7]) has been shown to improve the download
completion time performance of BitTorrent. For example, [7] showed a
35% reduction in download time for 60% of the peers in a swarm.
Other studies [5] showed this gain to be around 10-25%. However, [5]
also showed that such an approach increases the traffic on congestion
on bottleneck links by 69%. In summary, while peer related
information is powerful in improving performance, it affects ISP
performance and can lead to shaping and throttling.
3.3.2. Network-assisted ALTO alone
On the other hand there are several situations where relying on ISP
information by itself is not sufficient. If ISPs simply return a
rank ordered list of node identifiers in response to a list of node
identifiers sent in a query, the querying node may not be optimizing
its performance. It is possible that the peers in a swarm that are
within the ISP are all DSL hosts which can upload at 128Kbps while
some of the other peers that may involve interdomain routing are
actually high bandwidth fiber or cable connected hosts with high
upload bandwidth. In such cases, the p2p application user would
sustain high download times to meet the ISP's objective. Similarly,
peers that are nearby geographically (which is correlated with
latency typically) may be preferred for relays in VoIP but do not
meet the ISP's objective since they use a different access network.
The reasons for these problems are two-fold: (1) The ISPs' objectives
in general may not always match the users objective of improved
performance, and (2) The ISP can only provide an indication of its
preference for connectivity to certain peers outside its domain but
it does not have any notion of end-to-end performance provided by
these outside peers.
Thus neither network-asissted ALTO or peer-assisted ALTO alone help
in bringing together these competing interests together. Thus, in
this draft we argue for a combined solution that provides a true
information plane for peer selection, i.e. one that does not
sacrifice but, in fact improves the performance of p2p applications
Das, et al. Expires April 26, 2009 [Page 7]
Internet-Draft multi October 2008
while getting cooperation from p2p applications for the ISP. ISP
information is only one of the two pillars of the ALTO service - it
is an important one, given that the ISPs have knowledge of internal
congestion, interdomain peering policies and connectivity
information. Peer information is the other pillar of the ALTO
service; and by providing it as a service to all p2p applications we
reduce the overhead and inefficiency of each application performing
their own measurements which is inefficient for the network and
complicated for application developers.
3.4. Applicability and Discussion
The problem of peer selection has been studied at various dimensions
and has pretty broad applicability. At the very basic level,
intelligent peer selection can be applied, in file sharing networks,
to the problem of choosing the right source to download a file from.
However, there are a variety of other applications for such
intelligent peer selection. For example, locality aware structured
overlays are built with topology-assisted neighbor selection models
or topology-based identity generation shcemes. The more accurate the
topology information is, the more efficient such schemes will be.
Very fundamentally, intelligent neighbor selection schemes aim at
improving the query latency in such systems. Peer selection is also
applicable to other problems such as 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.
A lot of study has been done on the applicability of the peer
selection problem. Some examples include [8], [9], [10], [11], [12],
[13].
Two observations can be made from these applicability aspects of peer
selection. One is that the problem is applicable to a wide range of
scenarios with some possible generalization - in all cases, while the
criteria for peer selection and the context in which it is done may
be different, the basic model for peer selection revolves around
ranking a list of peers based on information collected about the
peers in accordance with the given criteria. A second observation is
that the same piece of information collected could be put to use in
very different ways in different scenarios - e.g., the use of
topology information in determining source peers to download content
from and neighbor peers to make connections with are very different
applications.
Peer selection is also equally important for application providers,
ISPs and the peers themselves for very different reasons. ISPs have
an incentive to keep their operational costs to a minimum, while
Das, et al. Expires April 26, 2009 [Page 8]
Internet-Draft multi October 2008
ensuring their customers a good experience. Application providers
are interested in keeping their own operational costs to a minimum,
which by nature, conflicts with the ISP's interests of keeping the
costs low. Application providers are also interested in ensuring
that the application performs well to keep the peers interested in
the application. For the peers themselves, the emphasis is on
performance as well as their own access costs.
The varied scenarios of applicability of peer selection information,
the diverse interests of various parties in peer selection and the
underlying common nature of these models suggest that the problem
should be tackled in a uniform manner, allowing for generality and
extensibility of information. The scenarios also broadly fall under
two buckets - one, where information may be obtained from specific
hosts (e.g., ISP hosts, reputation tracking servers, etc.) and
another, where information may be obtained from any number of peers.
The final peer selection algorithm may be a combination of various
pieces of such information in a manner that fits a given scenario and
criterion. Solving any one piece of this puzzle separately is likely
to lead to multiple different protocols and mechanisms for the same
problem. Further, any one such protocol is unlikely to result in a
dramatic improvement of the scenario (be it bandwidth utilization or
latency reduction, etc.). For instance, as argued earlier in this
draft, network-assistance and peer information are both important to
consider for peer selection. Hence, the adoption of any one of these
protocols will be less incentivized in such a fragmented model.
The ALTO service, given a set of host location identifiers for peers,
may annotate them with ISP information (such as the p-distance from
P4P) as well as peer connectivity information (which is variable and
could be related to bandwidth, network coordinates, wireless link
information etc ) and return the annotated set to the p2p
application. The p2p application can use this data to perform peer
selection based on its requirements. We argue that the peer
connectivity information be a generic container that can contain
different types of information. However the request response
protocol can be unified as an ALTO protocol for retrieving the
annotated information for each destination peer. Note that the data
pertaining peer-assisted ALTO and network-assisted ALTO may be stored
differently but the interface to p2p applications can be kept
consistent.
4. Design Goals
The fundamental goal of ALTO, extracting from what has been described
thus far, has to do with allowing the use of both network-assisted
and peer-assisted information exchanges for various categories of
Das, et al. Expires April 26, 2009 [Page 9]
Internet-Draft multi October 2008
applications that can use it. The main idea is to model ALTO as a
service that these applications may use to apply the peer selection
intelligence in the specific context of interest to the application.
The following are design goals for the ALTO service framework:
1. The ALTO service should accommodate specific hosts providing
network topology information.
Network topology information may be provided by hosts in an
ISP network with much greater accuracy than can be done via
other schemes. Hence, a model that allows for such
information exchange from specific hosts is useful. The
discovery of such hosts capable of providing this information
falls in this territory as well.
2. The ALTO service should allow peers to publish ALTO related
information in an application agnostic manner.
Peers may publish information of various kinds that helps in
peer selection. A primary example of such information is the
connectivity characteristics of a peer. This type of
information allows other criteria to be taken into account for
peer selection, such as the uplink/downlink bandwidth of
peers, the wireless nature of links, etc. This information,
coupled with topology or proximity information, will allow
exchange of bulk data in a manner that benefits the ISPs and
the peers.
3. The ALTO service should allow for both centralized and
distributed service models.
ISP hosts and any servers that are queried for ALTO related
information may be offering the ALTO service in a centralized
model. On the other hand, peer information related to ALTO
may be obtained in a distributed fashion, e.g., by querying an
overlay. It is important to cater to both models and also
allow for the two models to be linked. For instance, a query
on an overlay for ALTO related information may result in a
different node on the overlay querying the ISP's ALTO host.
4. The ALTO protocols should be agnostic to the actual peer
selection algorithm in use.
The peer selection algorithm itself is contextual and depends
on different factors for different scenarios. For instance,
source selection for bulk data downloads involves optimal
bandwidth usage and performance as criteria, neighbor
selection in structured overlays may be a function of hop
Das, et al. Expires April 26, 2009 [Page 10]
Internet-Draft multi October 2008
count and delay, relay selection for NAT traversal may be a
function of the relay capacity and connectivity
characteristics and so on. Hence, the ALTO protocols should
be agnostic to the specific peer selection algorithm for any
given instantiation.
5. The ALTO protocols should be generic to allow any type of
information useful for performing ALTO services to be exchanged.
The ALTO protocols should be extensible to allow carrying new
types of information that may be defined at a future point.
As in the case of the algorithm, the types of information
exchanged for peer selection are also contextual to various
scenarios. For instance, bandwidth or latency based peer
selection may involve topology information and connectivity
characteristics of peers, relevance based peer selection may
involve the semantic expertise of various peers, and so on.
Hence, the ALTO protocols should simply be a container to
transport information that assists in peer selection without
being dependent on the actual type of information exchanged.
5. Security Considerations
Information exchange, as facilitated by ALTO, may be sensitive and
may require secure communication. Hence, the ALTO protocols must
provide for channel security properties such as confidentiality and
integrity protection. Further, the exchange of some of this
information may need to be limited to certain entities. This calls
for authentication and authorization of entities prior to exchange of
ALTO information. Hence, the ALTO framework should provide for
entity authentication and authorization as part of the service. When
various types of information to be carried in the ALTO protocols are
standardized, a call must be made about whether it is subject to the
authorization model. Further, some types of information exchanges
could lead to privacy issues to various parties and the implications
of that need to be studied prior to standardization.
6. IANA Considerations
This document does not have any IANA considerations.
7. Acknowledgments
This draft has benefited from the insights presented in several IETF
drafts namely the ALTO problem statement, requirements and survey
Das, et al. Expires April 26, 2009 [Page 11]
Internet-Draft multi October 2008
drafts. The research work done on IPlane, P4P, Taming the torrent,
and ISP and P2P oracles as well as the various measurement studies on
P2P applications impact on ISPs performed by the research community
have helped inform us in creating this draft.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[2] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should
ISPs fear Peer-Assisted Content Distribution?", IMC Proceedings
of the Internet Measurement Conference, 2005.
[3] Akella, A., Seshan, S., and A. Shaikh, "An Empirical Evaluation
of WideArea Internet Bottlenecks", Proceedings of ACM SIGCOMM,
2003.
[4] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and
P2P systems co-operate for improved performance?", ACM SIGCOMM
Computer Communications Review (CCR), 37:3, pp. 29-40, 2006.
[5] Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang,
"P4P: Explicit Communications for Cooperative Control Between
P2P and Network Providers", Proceedings of ACM SIGCOMM, 2008.
[6] Choffnes, D. and F. Bustamante, "Taming the Torrent: A
practical approach to reducing cross-ISP traffic in P2P
systems", Proceedings of ACM SIGCOMM, 2008.
[7] Madhyastha, H., Isdal, T., Piatek, M., Dixon, C., Anderson, T.,
Krishnamurthy, A., and A. Venkataramani, "iPlane: an
information plane for distributed services", Proceedings of
USENIX OSDI, 2006.
[8] Lo, V., Liu, Y., GauthierDickey, C., and J. Li, "Scalable
Leader Selection in Peer-to-Peer Overlay Networks",
Proceedings of Second International Workshop on Hot Topics in
Peer-to-Peer Systems (Hot-P2P), 2005.
[9] Xhafa, F., Barolli, L., Fernandez, R., and T. Daradoumis, "An
Experimental Study on Peer Selection in a P2P Network over
PlanetLab", Proceedings of International Conference on
Das, et al. Expires April 26, 2009 [Page 12]
Internet-Draft multi October 2008
Parallel Processing Workshops, 2007.
[10] Yang, X. and G. Veciana, "Service Capacity of Peer to Peer
Networks", Proceedings of IEEE INFOCOM, 2004.
[11] Habib, A. and J. Chuang, "Service Differentiated Peer
Selection: An Incentive Mechanism for Peer-to-Peer Media
Streaming", Proceedings of IWQoS, 2004.
[12] Tang, S., Wang, H., and P. Meigham, "The Effect of Peer
Selection with Hopcount or Delay Constraint on Peer-to-Peer
Networking", Proceedings of IFIP NETWORKING, 2008.
[13] Haas, P. and R. Siebes, "Peer Selection in PeertoPeer Networks
with Semantic Topologies", Proceedings of WWW, 2004.
Authors' Addresses
Saumitra M. Das
Qualcomm, Inc.
3195 Kifer Road
Santa Clara, CA
USA
Phone: +1 408-533-9529
Email: saumitra@qualcomm.com
Vidya Narayanan
Qualcomm, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Lakshminath Dondeti
Qualcomm, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Das, et al. Expires April 26, 2009 [Page 13]
Internet-Draft multi October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Das, et al. Expires April 26, 2009 [Page 14]