Transport Working Group R. Penno
Internet Draft Juniper Networks
Intended status: Informational J. Iyengar
Expires: April 2009 Franklin & Marshall College
October 27, 2008
TANA Practices and Recommendations
draft-penno-tana-app-practices-recommendation-00.txt
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 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Applications routinely open multiple TCP connections. For example,
P2P applications maintain connections to a number of different peers
while web browsers perform concurrent download from the same web
server. Application designers pursue different goals when doing so:
<Lastname> Expires April 27, 2009 [Page 1]
Internet-Draft TANA Practices and Recommendations October 2008
P2P apps need to maintain a well-connected mesh in the swarm while
web browsers mainly use multiple connections to parallelize requests
that involve application latency on the web server side. But this
practice also has impacts to the host and the network as a whole. For
example, an application can obtain a larger fraction of the
bottleneck than if it had used fewer connections. Although capacity
is the most commonly considered bottleneck resource, middlebox state
table entries are also an important resource for an end system
communication.
This documents clarifies the current practices of application design
and reasons behind them, and discusses the tradeoffs surrounding the
use of many concurrent TCP connections to one destination and/or to
different destinations. Other resource types may exist, and the
guidelines are expected to comprehensively discuss them.
Conventions used in this document
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 Error!
Reference source not found..
Table of Contents
1. Introduction 2
2. Multiple TCP Connections Advantages 3
3. Multiple TCP connections Resources 4
4. Memory Space 4
5. Link Bandwidth 4
6. Middleboxes 5
7. Security Considerations 5
8. IANA Considerations 5
9. Conclusions 5
10. Acknowledgments 6
11. References 7
11.1. Normative References 7
11.2. Informative References 7
Author's Addresses 7
Intellectual Property Statement 7
Disclaimer of Validity 8
1. Introduction
The use of P2P protocols by end users is widespread. These protocols
are meant to exchange, replicate, stream or download files with
Penno Expires April 27, 2009 [Page 2]
Internet-Draft TANA Practices and Recommendations October 2008
little human intervention, trying at the same time to minimize the
download time of the files requested by any single peer. This is done
by opening several connections to multiple peers and downloading one
or more chunks of the file from each one, selecting faster peers,
amongst others.
Now end users that utilize P2P clients in general not only consume
more bandwidth but consume bandwidth throughout the whole day, and
more specifically consume more upstream bandwidth since they share
files, and more downstream bandwidth since P2P clients try to
minimize download time.
The advantages of P2P applications come from the fact that they open
multiple TCP connection to different peers. On the other hand, this
is also their major drawback.
But the use of multiple TCP connections by an application is not new.
Web Browsers have being it for a decade. But these are usually short-
lived connections to a single host as opposed to long-lived P2P
connections.
With the popularity of P2P applications, which maintain hundreds of
long-lived TCP connections to multiple hosts, the issue applications
making use of multiple TCP connections has been gaining attention.
This documents clarifies the current practices of application design
and reasons behind them, and discusses the tradeoffs surrounding the
use of many concurrent TCP connections to one destination and/or to
different destinations. Other resource types may exist, and the
guidelines are expected to comprehensively discuss them.
2. Multiple TCP Connections Advantages
There are good reasons for an application to use multiple TCP
connections. P2P apps need to maintain a well-connected mesh in the
swarm while web browsers mainly use multiple connections to
parallelize requests that involve application latency on the web
server side
But from a P2P standpoint multiple TCP connections are at the heart
of its functionality. Multiple connections allow for multiple
simultaneous downloads, which improve reliability and speed. Multiple
connections also allow more effective discovery of new peers, and
effective peer-to-peer communication, which allows exchange of
information such as which pieces of a file a client has and is
available.
Penno Expires April 27, 2009 [Page 3]
Internet-Draft TANA Practices and Recommendations October 2008
3. Multiple TCP connections Resources
Every connected application on the Internet competes for resources.
This is not specific to applications that open multiple TCP
connections. The use of multiple TCP connections just amplifies the
issue. In the following sections we discuss these resources and how
they are amplified by an application opening multiple connections.
4. Memory Space
Each TCP connection needs a TCP control block (TCB) or equivalent to
keep state about its connection. In operating systems where the TCP
stack is part of the kernel, this would come from the kernel memory
space, otherwise from userland memory.
But irrespective from where the memory comes from a TCP control block
requires a significant amount of memory. This is significant issue
for devices that terminate TCP connections from multiple end hosts to
provide functions such as Load-Balancing, Gateway and Tunneling.
Some proposals have been put forward to reduce the amount of memory
occupied by each TCP control block [RFC2140], but the issue remains
significant and is amplified by applications that use multiple TCP
connections.
5. Link Bandwidth
The bottlenecks for these n connections could be shared or separate.
If separate, there's no specific bottleneck where the connections are
hogging bandwidth. But from a network resource point of view, the
application download still gets multiple shares.
If some/all bottlenecks are shared, then two possibilities exist for
shared bottleneck
- bottleneck is a last-hop link (user traffic dominates link), OR
- bottleneck is in-network wide-area link (background traffic
dominates link)
If bottleneck is last-hop, then n transport connections compete with
each other and share link bandwidth.
Although these connections might impact delay-sensitive traffic and
increase delay, in the last hop it only affects end end-user, which
is in control of which applications run on its host. In this case the
user has the option of manually choosing when to run such
Penno Expires April 27, 2009 [Page 4]
Internet-Draft TANA Practices and Recommendations October 2008
application, configuring the end host, amongst others. Alternatively,
or in conjunction with the above, the application can be enhanced to
use Diffserv and new delay sensitive congestion mechanisms.
If shared bottleneck is in-network, then application gets unfair
share of bottleneck bandwidth. This impacts flows belonging to other
users in general, and most importantly delay-sensitive traffic.
6. Middleboxes
Middleboxes re defined as any intermediary box performing functions
apart from normal, standard functions of an IP router on the data
path between a source host and destination host [RFC3234].
Middleboxes can be stand-alone or integrated in another device such
as a router or modem.
The functions that are relevant to this discussion are those that
require the middlebox to keep per session state, sometimes referred
as transformation services. Some of these functions are, for example,
NAT, Intrusion Detection and Load-Balancing.
It is easy to see that the more sessions a host initiates, the more
state the middlebox will have to keep. The relationship is at least
1:1 but due asymmetric traffic, routing changes and others, this can
be 1:N.
Although application traffic from most broadband subscribers today go
through at least one middlebox (integrated into the broadband modem),
it can traverse other middleboxes that reside within the ISP's
network or close the destination. These middleboxes aggregate traffic
from multiple subscribers and state tables within these devices can
become a premium.
7. Security Considerations
None at this time
8. IANA Considerations
None at this time
9. Conclusions
TBD
Penno Expires April 27, 2009 [Page 5]
Internet-Draft TANA Practices and Recommendations October 2008
10. Acknowledgments
Penno Expires April 27, 2009 [Page 6]
Internet-Draft TANA Practices and Recommendations October 2008
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC2140] J. Touch, TCP Control Block Interdependence, RFC 2140
(1997)
Author's Addresses
Reinaldo Penno
Juniper Networks
1194 N Mathilda Aveue
Sunnyvale, CA
Email: rpenno@juniper.net
Jana Iyengar
Franklin & Marshall College
Email: jiyengar@fandm.edu
Intellectual Property Statement
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.
Penno Expires April 27, 2009 [Page 7]
Internet-Draft TANA Practices and Recommendations October 2008
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Penno Expires April 27, 2009 [Page 8]