Internet DRAFT - draft-qin-tsvwg-uatnut
draft-qin-tsvwg-uatnut
TSVWG X. Qin
Internet-Draft N. Kong
Intended status: Experimental X. Lee
Expires: November 29, 2015 CNNIC
May 28, 2015
Upload Acceleration Transport Network for Upstream Traffics
draft-qin-tsvwg-uatnut-00
Abstract
Photos, videos and other upstream traffics generated by end users are
rapidly increasing these days and expected to continue doing so in
the future. A lot of factors, such as long round-trip-time (RTT),
low robustness of delivery, and transport bottlenecks, etc., lead to
low upload rate, which cause poor user experiences. This draft
discusses an Upload Acceleration Transport Network(UATN) for upstream
traffics that use distributed cache servers and separates the upload
transaction into two parts for greater network efficiency.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 29, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Qin, et al. Expires November 29, 2015 [Page 1]
Internet-Draft upload acceleration transport network May 2015
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Cases and Scenarios . . . . . . . . . . . . . . . . . . . 4
2.1. End User to Data Center Use Case . . . . . . . . . . . . 4
2.2. End User to End User Use Case . . . . . . . . . . . . . . 6
2.3. Footprint Extension Use Cases . . . . . . . . . . . . . . 6
2.4. Offload Use Case . . . . . . . . . . . . . . . . . . . . 8
3. Upload Acceleration Transport Network Approach . . . . . . . 8
4. New Protocol Considerations . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Traditional Internet data services are frequently that end users
download content from data centers or Content Service Providers
(CSPs) distribute content to their end users, so traffic volume
generated by end users account for very small proportion of all
Internet traffics. However, as mobile phones and other smart devices
are proliferating, above status is changing since more and more end
users like directly uploading and sharing their photos, videos or
other documents by data centers. Besides, mobile devices emerging
are fully cloud-dependent that are not equipped with much storage but
rely on large storage in data centers. For these reasons, a large
Qin, et al. Expires November 29, 2015 [Page 2]
Internet-Draft upload acceleration transport network May 2015
number of Online Storage Service Providers(OSSPs),Photos Sharing
Service Providers (PSSPs), and Videos Sharing Service Providers
(VSSPs) emerge at a historic moment so that make upstream traffics
rapidly increasing and expected to continue doing so in the future.
To overcome this challenge of massive upstream traffic, just
installing more data servers will not be enough[RFC6392]. Moving
data server closer to the end users results in greater network
efficiency: improved Quality of Service (QoS), increased robustness
of delivery,and lower latency. In these existing work, Content
Delivery Networks (CDNs) are a representative technique. However,
CDNs focus on downstream traffic and are used to deliver large-scale
content from data center to end users while do not necessarily apply
to upstream traffics[RFC6707]. Since lack of this edge technologies,
when end users request to upload content to data center, they may
have to face a long "data path", such as Telecommunication Service
Provider's Network(TSPN), Metropolitan Area Networks (MANs), Wide
Area Networks (WANs), etc., which may worsen the upload environment
and force end users to stay tethered to the network for long time.
Even over a relatively long distance, throughput may go from maximum
to nothing. According to the report in [1], throughput measurements
from over 1.5 million mobile devices have shown that compared with an
average downstream throughput of over 1860 Kbps, the average upstream
throughput is only about 430 Kbps. This is because of the adoption
of cache techniques such as CDNs to acelerate downloading large
content that moves the "content" closer to end users.
For improving the user experience of upload, it is worthwhile and in
fact extremely important to consider an acceleration approach for
upload service like their download counterparts. It is generally
desirable that a given content item generated by one user can be
quickly and robustly uploaded to data centers regardless of that end
user's location or attachment network. This is the motivation for
establishing UATN so it can provide open content delivery
infrastructure for the end-to-end delivery of content from end user
to data center. However, no standards or open specifications
currently exist to facilitate such acceleration transport network.
The goal of this document is to figure out how to build a UATN for
upstream traffics to provide improved quality of user experienceand
reduced delivery cost.
1.1. Terminology
This document uses the following terms:
Upload Service Provider (USP):The service provider who operates data
servers or cloud service that allows end users to directly upload or
Qin, et al. Expires November 29, 2015 [Page 3]
Internet-Draft upload acceleration transport network May 2015
share their content, such as photos, videos, or other documents
generated by them. The content may be stored temporarily, or
downloaded by other end users,or directly forwarded to another end
user. Note that a given entity may operate in more than one role.
For example, a company may simultaneously operate as a USP,a CSP, and
a CDN Provider, etc.
Upload Acceleration Transport Network (UATN): A transport network
between end users and data centers that enables cache servers to
provide content upload services on behalf of the USP. A UATN may be
wholly or partially realized through a set of cache servers and
transport system with control and communication components.
UATN Provider: The service provider who operates a UATN and offers a
service of content upload acceleration, typically used by USPs. Note
that a given entity may operate in more than one role. For example,a
company may simultaneously operate as a USP,a CDN Provider, and a
UATN Provider, etc.
1.2. Abbreviations
o UATN: Upload Acceleration Transport Network
o USP: Upload Service Provider
o CSP: Content Service Provider
o EU: End User
o ISP: Internet Service Provider
o NSP: Network Service Provider
o QoE: Quality of Experience
o QoS: Quality of Service
o TSP: Telecommunication Service Provider
o ASP: Acceleration Service Provider
2. Use Cases and Scenarios
2.1. End User to Data Center Use Case
An example is depicted in Figure 1, where USP has deployed its own
UATN or established an agreement with UATN Provider for the uploading
of this content. When a given end user requests uploading content to
Qin, et al. Expires November 29, 2015 [Page 4]
Internet-Draft upload acceleration transport network May 2015
USP's data center, the UATN may allow the end user to directly upload
the content to its cache server. UATN also selects the optimum cache
server to serve this uploading. For instance, UATN considers that
the Cache-1 is appropriate, because Cache-1 is an access cache and
the end user is directly attached to it[RFC6770]. Through the UATN
arrangements put in place between USP and end user(as a result of the
upload acceleration service agreement established between USP and
UNTA Provider),UATN can redirect the request to Cache-1 and the
content is actually delivered to the USP's data center by UATN.
+------------------+
+----->| USP's Data Center|
| +------------------+
| ^
| * * * * * *|* * * * * * * * * * * * * ** * * *
| * | UATN *
| * ,--,--,--. ,--,--,--. *
| * -' `-. ,-' `-. *
| * ( Cache )====( Cache-1 ) *
| * `-. ,-' `-. ,-' *
| * `--'--'--' `--'--'--' *
| * ^ *
| * * * * * * * * * * * * * * * * *| * * * * * *
| +-----+
+--------X------------------------| E U |
+-----+
========= UATN Data Flow
--------- Common Data Flow
Figure 1
End users benefit from this arrangement through a better
QoE[RFC6390], because the content is uploaded to a nearby surrogate
(e.g., lower latency, bottlenecks avoided)[RFC6707]. USPs benefit
because they do not need to deploy such an extensive data server,
they only need to make one business agreement and one technical
arrangement with UATN Provider, but their end users can get a high
service quality. TSPs benefit because they do not need to expand the
uplink bandwidth, and the upstream throughputs can be improved from
end use's perspective. To extend the example, other ASPs, such as
CDN Providers may also benefit from this arrangement. They can make
their existing CDNs to provide upload services so that the upstream
bandwidth can be fully used, and may receive some compensation for
the delivery.
Qin, et al. Expires November 29, 2015 [Page 5]
Internet-Draft upload acceleration transport network May 2015
2.2. End User to End User Use Case
In this scenario, USP wishes to allow content delivery among its end
users with high speed. Consider the following example,illustrated in
Figure 2: EU-1 wants to deliver content to EU-2, however, there may
have a long "data path" between EU-1 and EU-2, such as TSPN, MANs,
WANs, etc. This will cause large delay and inversely proportional
TCP throughput. One technique for improving the user seen throughput
is to introduce UATN between the sender and the receiver. UATN
resolves the problem by separating the current delivery communication
into two parts, front-end service from the EU-1(the sender) to UATN
and back-end service from the UATN to EU-2 (the receiver) to reduce
access network and/or inter-network hop delay.
As an example, suppose a French person wants to deliver content to
the end user located in Africa. The USP of this French user can ask
a UATN Provider to provide acceleration that content generated by the
French people will be first forwarded to the UATN Cache-1 and then is
delivered to UATN Cache-2 through UATN's high reliability and
performance transport system. At last, the content is actually
deliver to African user by UATN's Cache-2.
+------+
+------------X-----------------| E U-1|
| +------+
| * * * * * * * * * * * * * * * * | * * * * * *
| * V UATN *
| * ,--,--,--. ,--,--,--. *
| * -' `-. ,-' `-. *
| * ( Cache-2 )====( Cache-1 ) *
| * `-. ,-' `-. ,-' *
| * `--'--'--' `--'--'--' *
| * * * * * | * * * * * * * * * * * * * * * * *
| V
| +-----+
+-------->|E U-2|
+-----+
========= UATN Data Flow
--------- Common Data Flow
Figure 2
2.3. Footprint Extension Use Cases
In this use case, the USPs want to extend the infrastructure to
support active users rapid growth:
Qin, et al. Expires November 29, 2015 [Page 6]
Internet-Draft upload acceleration transport network May 2015
o without compromising the quality of upload.
o keeping additional transit and other network costs at a reasonable
level that receives content from geographically or topologically
remote end users.
o without incurring the cost of deploying and operating data centers
and the associated infrastructure that may not be justified in the
corresponding geographic region (e.g., because of relatively low
delivery volume, or conversely because of the high investments
that would be needed to satisfy the high volume).
In addition,if USPs have a geographically limited footprint (e.g.,
restricted to one country), or do not serve all end users in a
geographic area, they can also establish an agreement with a UATN
Provide to provide their services beyond their own footprint.
+-----------+ +-----------+
| French USP| |Italian USP|
+-----------+ +-----------+
^ ^
* * *\ * * * * * / * * * * * * * * * * * * *
* \ / UATN *
* ,--,--,--. ,--,--,--. *
* -' `-. ,-' `-. *
* ( Cache-1 )====( Cache-2 ) *
* `-. ,-' `-. ,-' *
* `--'--'--' `--'--'--' *
* ^ *
* * * * * * * * * * * ** * * * * | * * * * *
+------------+
|North Africa|
| E Us |
+------------+
========= UATN Data Flow
--------- Common Data Flow
Figure 3
As an example, suppose a French USP wants to provider upload service
to end users located in various countries in North Africa. It can
make an agreement with UATN Provider that covers North Africa instead
of deploying its own data center in North Africa. Overall, from the
end use's perspective, the French USP provides an upload service for
the whole North Africa with high data rate. If there are several
USPs that have make an agreement with the UATN Provider, cost will
keep at a reasonable level, as shown in Figure 3.
Qin, et al. Expires November 29, 2015 [Page 7]
Internet-Draft upload acceleration transport network May 2015
2.4. Offload Use Case
A USP's access server or servers is/are likely to be dimensioned to
support an expected maximum traffic load. However, unexpected spikes
in content popularity (flash crowd) may drive load beyond the
expected peak. The USP may use UATN so that some requests may be
redirected to UATN to increase its effective capacity during the peak
of traffic.
For example, a USP can offload traffic to UATN for the duration of a
specific maintenance operation or a special event, as in the scenario
depicted in Figure 4. For instance, during a major event, such as a
celebrity's wedding or a major sport competition, many people in a
confined space may deliver and upload photos, video related to this
event, the USP and TSP are likely to experience a flash crowd during
the event and will need to offload traffic. While UATN can support a
more typical traffic load and be able to handle the offloaded
traffic.
+------------------+
+--->| USP's Data Server|<----------------------+
| +------------------+ |
| ^ |
| * * * * * | * * * * * * * * * * * * * * * * |
| * | UATN * |
| * ,--,--,--. ,--,--,--. * |
| * -' `-. ,-' `-. * |
| * ( Cache-1 )====( Cache-2 ) * |
| * `-. ,-' `-. ,-' * |
| * `--'--'--' `--'--'--' * |
| * ^ ^ * |
| * * * * * *| * * * * * ** * * * *| * * * * * |
| +-----+ +-----+ |
+---X------|E U-1| |E U-2|-----X--+
+-----+ +-----+
========= UATN Data Flow
--------- Common Data Flow
Figure 4
3. Upload Acceleration Transport Network Approach
The UATN is a distributed system consisting of lots of widely
deployed servers to enable the delivery of highly scalable
distributed applications. UATN is comprised of multiple delivery
networks, each tailored to a different type of content. For example,
picture content, streaming media, or static web content. At a high
Qin, et al. Expires November 29, 2015 [Page 8]
Internet-Draft upload acceleration transport network May 2015
level, UATN shares a similar architecture, which is shown in
Figure 5, but the underlying technology and implementation of each
system component may differ in order to best suit the specific type
of content.
The main components of UATN are as follows:
When the user types a USP's domain name into his/her browser, the
domain name is translated by the mapping system into the IP address
of an edge server to serve the content (arrow I). The mapping system
should collect and analysis historical and current data regarding the
virtual network and server conditions. This data is used to choose
an edge server that is located close to the end user.
Each edge server is part of the edge server platform, a distributed
deployment of servers located in many sites. These servers are
responsible for processing requests from nearby EUs and receiving
content generated by them (arrow 2).
In order to respond to a request from a user, the UATN must deliver
the content stored by edg server/servers to the designated data
center. The transport system is used to deliver content between edge
server platform and designated data center in a reliable and
efficient manner. More generally, the transport system is
responsible for moving data and content over the long-haul Internet
with high reliability and performance.
The communications and control system is used for disseminating
status information, control messages, and configuration updates in a
fault-tolerant and timely fashion.
Finally, the user control portal serves two functions. First, it
provides a configuration management platform that allows a USP to
retain fine-grained control how the content is uploaded to their data
center by the end user. These configurations can be told timely to
the edge platform via the communications and control system. Note
that this configuration management applies to the third party UATN
providers, if a USP deploys its own UATN, the configuration
management platform can be omitted. In addition, the user control
portal provides a redirection approach of user request that redirects
the upload request to the UATN.
While all of UATN incorporates the component outlined above, the
specific design of each system is influenced by application
requirements. For instance, the transport system of a UATN will have
a different set of requirements and a different architecture.
Qin, et al. Expires November 29, 2015 [Page 9]
Internet-Draft upload acceleration transport network May 2015
**************************************
* Virtual Network *
+---- * +--------+ *
|E U|----->| Edge | *
+---+ * | Server |\ *
* +--------+ \ *
* \ , --,--,--. * +-----------+
+---+ * +--------+ ----'-------------`-.-->| |
|E U|----->| Edge |---( Transport System )-->|Data Center|
+---+ * | Server | -`-.-------------,'---->| |
* +--------+ / `--'--'--' * +-----^-----+
* / III * |
+---+ II * +--------+/ * |
|E U|----->| Edge | * |
+---+ * | Server | * +----v----+
* +- ^-----+ * | USP |
| *** / ******************************** +----^----+
| / |
| +--|-------------------------------------+ |
| | Communication and Control System | |
| I +--|-- ^-------------------------------^-+ |
| | | | |
\ +---v---v-----------+ +-----------v-----v---+
- -> | Mapping System | | User Control Portal |
+-------------------+ +---------------------+
Figure 5
4. New Protocol Considerations
This document does not call for changes or additions: any new
session, transport or network protocols; new protocols for delivering
content from a UATN to an End User/User agent; new protocols for
ingestion of content between a UATN and a USP.
5. Security Considerations
This document focuses on approach and the motivational use cases for
UATN, and does not analyze the associated threats. Those threats
will be discussed in future.
6. Acknowledgments
The authors wish to thank David Black, Linlin Zhou, and Guangqing
Deng for their invaluable comments.
Qin, et al. Expires November 29, 2015 [Page 10]
Internet-Draft upload acceleration transport network May 2015
7. References
7.1. Normative References
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
[RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
Network Storage Systems", RFC 6392, October 2011.
[RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement", RFC
6646, July 2012.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012.
7.2. Informative References
[PPSP-Charter]
Y, Yan., "simulated-annealing algorithm", December 2009,
<http://datatracker.ietf.org/wg/ppsp/charter/>.
Authors' Addresses
Xiaowei Qin
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3689
Email: qinxiaowei@cnnic.cn
Qin, et al. Expires November 29, 2015 [Page 11]
Internet-Draft upload acceleration transport network May 2015
Ning Kong
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3147
Email: nkong@cnnic.cn
Xiaodong Lee
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3020
Email: xl@cnnic.cn
Qin, et al. Expires November 29, 2015 [Page 12]
