Internet DRAFT - draft-qin-appsawg-uatn-ut
draft-qin-appsawg-uatn-ut
APPSAWG X. Qin
Internet-Draft N. Kong
Intended status: Experimental X. Lee
Expires: February 6, 2016 CNNIC
August 5, 2015
Upload Acceleration Transport Network for Upstream Traffics
draft-qin-appsawg-uatn-ut-00
Abstract
Moving data center closer to end users can provide numerous benefits
for pre-uploaded content: lower latency, increased robustness of
delivery, and improved quality of user experience. For these
reasons, many Online Storage Service Providers(OSSPs),Photos Sharing
Service Providers (PSSPs), and Videos Sharing Service
Providers(VSSPs), etc., are scaling up their infrastructure, and many
above Upload Service Providers(USPs)are also deploying their own
cloud platforms to improve data upload rate. It is generally
desirable that a given content item generated by end users can be
quickly and robustly delivered to the destination regardless of that
end user's location or attachment network. This is the motivation
for deploying Upload Acceleration Transport Network(UATN) so it can
propose an open content delivery infrastructure for the end-to-end
delivery of content from end users to the destination(data center or
another end user, etc.). However, no standards or open
specifications currently exist to facilitate such an upload
acceleration mechanism.
The goal of this document is to explain the proposed UATN in detail
for providing public upload acceleration service and interconnect
existing upload acceleration systems as an open content delivery
infrastructur.
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
Qin, et al. Expires February 6, 2016 [Page 1]
Internet-Draft upload acceleration transport network August 2015
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 February 6, 2016.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2. Use Cases and Scenarios . . . . . . . . . . . . . . . . . . . 6
2.1. End User to Data Center Use Case . . . . . . . . . . . . 6
2.2. End User to End User Use Case . . . . . . . . . . . . . . 7
2.3. Footprint Extension Use Cases . . . . . . . . . . . . . . 8
2.4. Offload Use Case . . . . . . . . . . . . . . . . . . . . 9
2.5. Public Colient Use Case . . . . . . . . . . . . . . . . . 10
3. Upload Acceleration Transport Network Approach . . . . . . . 11
4. New Protocol Considerations . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Qin, et al. Expires February 6, 2016 [Page 2]
Internet-Draft upload acceleration transport network August 2015
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Traditional Internet data services are frequently that end users
download content from data centers or Content Service Providers
(CSPs) distribute their content to the customers, so upstream traffic
volume generated by end users accounts for very small proportion of
total Internet traffics. However, as smart mobile devices and cloud
services are proliferating, the direction of the Internet traffic
volume is changing. First, more and more mobile users like directly
uploading and sharing their photos, videos, documents and other data
by data centers. Second, many OSSPs enter the market and provide
free and larger storage space,in the meantime the emerging mobile
devices are fully cloud-dependent that are not equipped with much
storage but rely on large storage in data centers. Third, some
Service Providers (SPs) allow content delivery among their end users,
one user can deliver content to another via Internet. So upstream
traffic grows drastically these days and expected to continue doing
so in the future.
Unfortunately, inherent limitations in the Internet's architecture
make it difficult to achieve desired levels of performance natively
on the Internet. Designed as a best-effort network, the Internet
provides no guarantees on end-to-end reliability or performance. On
the contrary, wide-area Internet communications are subject to a
number of bottlenecks that adversely impact performance, including
latency, packet loss, network outages, inefficient protocols, and
inter-network friction. In addition, existing acceleration
technologies, such as CDNI[RFC6707], DECADE[RFC6390], that focus on
content distribution do not necessarily apply to upstream traffic,
upload service usually incurs poor user experience. According to the
report in [1], throughput measurements from over 3.1 million mobile
devices have shown that compared with an average downstream
throughput of over 3580 Kbps, the average upstream throughput is only
about 630 Kbps.
To improve user experience and overcome this challenge of massive
upstream traffic, USPs are scaling up their infrastructure, and many
USPs are also deploying their own cloud platforms to improve data
upload rate. It is generally desirable that a given content item
generated by end users can be quickly and robustly uploaded to the
destination regardless of that end user's location or attachment
network. However, a given USP's infrastructure may not have a
footprint that expands close enough to the end user's current
Qin, et al. Expires February 6, 2016 [Page 3]
Internet-Draft upload acceleration transport network August 2015
location or attachment network,or may not be better at that type
content processing, to realize the user experience and cost benefit
that a more efficient upload acceleration transport system would
allow. This is the motivation for deploying UATN so that it can
provide public upload acceleration service, and can also interconnect
existing standalone upload infrastructures so that their collective
acceleration footprint can be leveraged for the end-to-end delivery
of content from end users to the destination. As an example, a VSSP
could contract with a UATN Provider for the uploading of content, and
that UATN Provider should assign one or more appropriate edge servers
receiving the content on behalf of the VSSP. And at last, the
optimal route may be chosen to deliver the content to the VSSP's data
center.
A typical end-to-end content upload acceleration scenario may involve
the following business arrangements:
o A business arrangement between the end user and the USP,
authorizing upload content by the end users to the USP' data
center.
o A business arrangement between the USP and an UATN Provider where
the USP mandates that the UATN Provider perform the content
receiving on behalf of the USP.
o A business arrangement between the UATN Provider and another (or
other) UATN Provider(s) so that so they can interoperate as an
open content delivery infrastructure for the end-to-end delivery
of content.
The formation and details of any business relationships between a USP
and a UATN Provider as well as between one UATN Provider and another
UATN Provider are out of scope of this document. However, this
document concerns itself with the fact that no standards or open
specifications currently exist to facilitate such UATN for upstream
traffic from a technical perspective.
One possible flow for performing an end-to-end content upload through
UATN is described below:
o The initial content upload request from an end user is redirected
to UATN.
o The UATN may assign the best edge server(s) (e.g., an edge server
that is "closer" to the end user) receiving the end user's
content.
Qin, et al. Expires February 6, 2016 [Page 4]
Internet-Draft upload acceleration transport network August 2015
o The content may be preprocessed by edgs server(s) according the
policy of the destination data center.
o The UATN may choose the optimal route to deliver the content to
the destination data center.
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
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,
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 OSSP: Online Storage Service Providers
o PSSP: Photos Sharing Service Providers
o VSSP: Videos Sharing Service Providers
o USP: Upload Service Provider
o EU: End User
o QoE: Quality of Experience
o QoS: Quality of Service
Qin, et al. Expires February 6, 2016 [Page 5]
Internet-Draft upload acceleration transport network August 2015
o TSP: Telecommunication 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
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
Qin, et al. Expires February 6, 2016 [Page 6]
Internet-Draft upload acceleration transport network August 2015
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.
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.
Qin, et al. Expires February 6, 2016 [Page 7]
Internet-Draft upload acceleration transport network August 2015
+------+
+------------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:
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.
Qin, et al. Expires February 6, 2016 [Page 8]
Internet-Draft upload acceleration transport network August 2015
+-----------+ +-----------+
| 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.
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
Qin, et al. Expires February 6, 2016 [Page 9]
Internet-Draft upload acceleration transport network August 2015
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
2.5. Public Colient Use Case
One user tends to use multiple cloud services because each USP may
provide different better functionality: e.g. one USP may be better at
file processing, and another USP may be better at video processing.
So one user needs to use multiple similar clients for high data
upload rate(Because some USPs may use their own proprietary
transmission protocols for maximizing throughput). In this use case,
UATN can provide public acceleration service for end user to avoid
install multiple similar clients on their end devices. UATN could
preprocess the pre-uploaded content according the policy of the
destination data center, such as transmission protocol, chunking
strategy, etc.
As an example, suppose USP1 provides videos sharing service, using
HTTP as the carrier protocol. USP2 provides photos sharing service,
using HTTPs as the carrier protocol, as in the scenario depicted in
Figure 5. End user can upload both videos and photos quickly via
internet explorer based on HTTP protocol. First, the content will be
uploaded to the UATN based HTTP. Second, the UATN could send these
content to the destinations respectively and adapts the carrier
protocol accordingly.
Qin, et al. Expires February 6, 2016 [Page 10]
Internet-Draft upload acceleration transport network August 2015
+-------------------+ +-------------------+
| USP1's Data Server| | USP2's Data Server|
+-------------------+ +-------------------+
^ ^
| |
| +----------------+
* * * * * * * *|* *|* * * * * * * * * * * * * * *
* | | UATN *
* ,--,--,--. ,--,--,--. *
* -' `-. ,-' `-. *
* ( Cache-1 )====( Cache-2 ) *
* `-. ,-' `-. ,-' *
* `--'--'--' `--'--'--' *
* ^ ^ *
* * * * * * | * | * * * * * * * * * * * * * * * * *
+-------+
| E U |
+-------+
Figure 5
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
level, UATN shares a similar architecture, which is shown in
Figure 6, 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). Edge server may also preprocess
the content according the policy of the destination.
Qin, et al. Expires February 6, 2016 [Page 11]
Internet-Draft upload acceleration transport network August 2015
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 February 6, 2016 [Page 12]
Internet-Draft upload acceleration transport network August 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 6
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.
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. History
This draft had been submitted to the TSVWG (Transport Area Working
Group) once in May 28, 2015. Because, as a CDN-related draft, UATN
should belong in the TSV Area. This is the link,
https://datatracker.ietf.org/doc/draft-qin-tsvwg-uatnut/.
Qin, et al. Expires February 6, 2016 [Page 13]
Internet-Draft upload acceleration transport network August 2015
Unfortunately, in June, 2015, the IETF Area into which the CDNI WG
was moved, and the CDNI WG was moved into "Applications and Real-
Time" Area. Although, this time I have updated this draft, the
version number is still named to "00".
7. Acknowledgments
The authors wish to thank David Black, Linlin Zhou, and Guangqing
Deng for their invaluable comments.
8. References
8.1. Normative References
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, DOI
10.17487/RFC6390, October 2011,
<http://www.rfc-editor.org/info/rfc6390>.
[RFC6392] Alimi, R., Ed., Rahman, A., Ed., and Y. Yang, Ed., "A
Survey of In-Network Storage Systems", RFC 6392, DOI
10.17487/RFC6392, October 2011,
<http://www.rfc-editor.org/info/rfc6392>.
[RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement", RFC
6646, DOI 10.17487/RFC6646, July 2012,
<http://www.rfc-editor.org/info/rfc6646>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>.
8.2. Informative References
[PPSP-Charter]
Y, Yan., "simulated-annealing algorithm", December 2009,
<http://datatracker.ietf.org/wg/ppsp/charter/>.
Qin, et al. Expires February 6, 2016 [Page 14]
Internet-Draft upload acceleration transport network August 2015
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
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 February 6, 2016 [Page 15]
