| 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
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.
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 February 6, 2016.
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.
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 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:
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:
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.
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 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.
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
In this use case, the USPs want to extend the infrastructure to support active users rapid growth:
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.
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
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.
+-------------------+ +-------------------+
| USP1's Data Server| | USP2's Data Server|
+-------------------+ +-------------------+
^ ^
| |
| +----------------+
* * * * * * * *|* *|* * * * * * * * * * * * * * *
* | | UATN *
* ,--,--,--. ,--,--,--. *
* -' `-. ,-' `-. *
* ( Cache-1 )====( Cache-2 ) *
* `-. ,-' `-. ,-' *
* `--'--'--' `--'--'--' *
* ^ ^ *
* * * * * * | * | * * * * * * * * * * * * * * * * *
+-------+
| E U |
+-------+
Figure 5
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.
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.
**************************************
* 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
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.
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.
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/. 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".
The authors wish to thank David Black, Linlin Zhou, and Guangqing Deng for their invaluable comments.
| [RFC6390] | Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011. |
| [RFC6392] | Alimi, R., Rahman, A. and Y. Yang, "A Survey of In-Network Storage Systems", RFC 6392, DOI 10.17487/RFC6392, October 2011. |
| [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. |
| [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. |
| [RFC6770] | Bertrand, G., 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. |
| [PPSP-Charter] | Y, Yan., "simulated-annealing algorithm", December 2009. |