the Consideration for the Application of Multi-Service Tag
draft-xia-icn-multiservtag-02

ICN Working Group                                               Xia Yong
INTERNET-DRAFT                                               China SARFT
Intended Status: Informational                                   S. Duan
Expires: Sept 13, 2017                                       China CAICT
                                                                 Shu Liu
                                                             China CAICT
                                                                 R.Huang
                                                                  Huawei
                                                            Mar 13, 2017

       the Consideration for the Application of Multi-Service Tag
                     draft-xia-icn-multiservtag-02

Abstract

   This document discusses the consideration for the design of multi-
   service tag in the current complex network so as to optimize traffic
   model and improve the transmission efficiency.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2013 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
 

<Xia Yong>               Expires Sept 13, 2017                  [Page 1]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

   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.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Brief background  . . . . . . . . . . . . . . . . . . . . . . .  3
   3  The analysis of the limitation of current technologies  . . . .  3
     3.1 Identifying the content  . . . . . . . . . . . . . . . . . .  4
     3.2 Identifying the source . . . . . . . . . . . . . . . . . . .  4
   4 Consideration for the typical design of multi-service tag in
     CDN  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1 the design rules of multi-service tag  . . . . . . . . . . .  5
     4.2 the preliminary design of multi-service tag  . . . . . . . .  5
     4.3 the preliminary design of the multi-service tag system . . .  7
     4.4 the workflow of multi-service tag in CDN . . . . . . . . . .  8
   5  Analysis of application case  . . . . . . . . . . . . . . . . .  8
     5.1  service perception by network . . . . . . . . . . . . . . .  8
     5.2  intelligent cache . . . . . . . . . . . . . . . . . . . . .  8
     5.3  content exchange between little ISPs  . . . . . . . . . . .  9
   6 Simple Demo  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7 Security Considerations  . . . . . . . . . . . . . . . . . . . . 10
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
   9  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 10
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1  Normative References  . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

 

<Xia Yong>               Expires Sept 13, 2017                  [Page 2]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

1  Introduction

   The document discusses the feasibility of multi-service tag in the
   current Internet , analyzes the limitation of the related
   technologies, gives the requirements of the multi-service tag. We
   give the typical design of multi-service tag in CDN and introduce a
   demo.

2  Brief background

   Now the network traffic presents a rapid increase trend, the
   popularization of network video and the diversified viewing model
   modes support watch video in anytime and anywhere,which also results
   in the increase of network traffic. The network video Apps must
   provide terrific Quality of experience(QoE). These trends represent a
   developing direction of future networks. Recognition and handling of
   the application traffic is a key factor for network operation. Each
   network application uses different protocol and is deployed by
   different ISP, which incompletely  depends on the network operaters.
   The method of the recognition of traffic and applications uses the
   fuzzy heuristic modes which are based on the port scope and key
   information of the traffic and are similar with the DPI technology,
   but this series of technologies have some limitations. The heuristic
   methods can't effectively solve the problem of traffic recognition
   because they can't keep up with the synchronization update of
   application characteristics. The traffic recognition schemes based on
   the port scope detection face the great challenge because of enormous
   amount of ports which are discontinuous, especially for http traffic,
   the http traffic usually use 80 or 8080 port, so the content in http
   traffic is difficult to be identified accurately. Due to the
   encryption transmission of more and more traffic, these lead to the
   great increase of DFI/DPI calculated amount and make these two
   technologies be faced with invalidation. IP tunneling technology
   makes the operator's network more complex. So we need a new
   technology which can rapidly and uniquely recognize the traffic based
   on its characteristics without resolve the whole package.

3  The analysis of the limitation of current technologies

   The traffic recognition ways based on IP address pool face
   difficulties. Because IP address is of large amount, dynamic,
   proprietary or private. According to the CDN protocol (RFC 6770), the
   content can be transferred to different CDN and this makes it
   impossible to track the content among different CDN in terms of its
   IP address. Though the traffic recognition based on IP address is
   possible in some scenes, it's impossible to exactly identify every
   flow. Because the same port is maybe repetitively used by different
 

<Xia Yong>               Expires Sept 13, 2017                  [Page 3]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

   application, the traffic recognition based on port may lead the wrong
   results. DFI/DPI may lose efficacy or become very complicated with
   the more and more encrypted traffic in order to analyze the content
   contained by the traffic. A traffic flow of an application will end
   at user terminal through different network routes and this will
   affect the analysis of the traffic flow. There are no unified
   standards for traffic recognition and analysis and it will lead to
   different analysis results for the same traffic flow due to the
   analysis ability and implementation ways. The traffic analysis will
   parse the payload of the packages, thus it will affect the package
   processing efficiency which need extra process, and the ever-
   increasing new protocols also affect the DFI/DPI devices efficiency.
   The flow tag is defined in RFC6437 and it only applies in IPv6
   protocols. The flow tag changes along with the specific traffic flow
   and just like port. The flow tag can't identify the traffic flow
   independently and it must be used with source/destination IP
   addresses together. Because the flow tag is fixed in IPv6 header, it
   can identified easily, but it lacks of protect mechanism and there is
   no mechanism verifying its integrity.

   In general, the current traffic recognition ways is limited in the
   analysis of traffic flows, they can't provide effective feedback
   data, so they can't support the self-adaptive network processing
   capability established by the operators.

3.1 Identifying the content

   In order to improve the hit ratio and actively push the hot resources
   to the local subscribers, the cache system need a succinct way to
   learn the buffered contents and can judge the hot content according
   to the actual content information. 

3.2 Identifying the source

   To enable flexible reverse charging, we need a third party
   recognizable tag of the traffic for the charging GW located between
   the client and server, which helps in recognition of its source and
   billing model, and other features to enable other cultivated
   transport services, e.g. QoS for selected content types for a given
   ICP.

4 Consideration for the typical design of multi-service tag in CDN

   Now the accelerating system is widely used in the Internet, such CDN,
   the ISP's intelligent cache and P2SP etc. These accelerating systems
   usually use simple URLs to speed up the access rate without regard to
   the specific content,bandwidth requirements, global attention etc. So
   there's blindness to accelerate everything using one way and there's
 

<Xia Yong>               Expires Sept 13, 2017                  [Page 4]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

   no optimal acceleration aiming at the service requirements.

   For convenience, we use the CDN conditions to describe the
   application of the multi-service tag here.

4.1 the design rules of multi-service tag

   we need to design to a new rule to express the service properties and
   transmission requirements of the content. Every CDN operators can use
   the same algorithm to apply different accelerating strategies for the
   different contents so as to provide more professional and accurate
   accelerating service for every CP.

   We design a multi-service tag which can help the network better know
   the traffics which it carries. The multi-service tag design abandons
   the traditional fuzzy heuristic design idea and directly include the
   information about the transferred contents and the requirements for
   the transmission network. 

   This kind of tag is embedded into the content URL according to some
   rules, it can transparently transferred in different networks and has
   no impact on existing services, and we call it multi-service tag. It
   has the following features:

      a) no relationship with IP address or port number;

      b) one-to-one correspondence to the transferred content;

      c) stable in a traffic flow lifecycle;

      d) easily obtained and handled by the network operator;

      e) the tag can be recognized by the network, the network can draw
   up a strategy and adaptively transfer the content according to the
   tag information;

      f) confidence mechanism against tamper-proofing;

      g) decrease the complexity of network management.

4.2 the preliminary design of multi-service tag

   Here we give a simple and preliminary design of multi-service tag,
   the scheme is not mature and may be changed along with the
   development of the new technologies.

   The format of multi-service tag is as following:

 

<Xia Yong>               Expires Sept 13, 2017                  [Page 5]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

   xlables = base64( CID + content summary + type + file size + [code
   rate] + priority + timestamp + random number + signature )

   xlables: fixed string which identifies tags and encrypts the
   following information using base64.

   CID: the identity of CP which is distributed by the tag service
   system in a unified way.

   content summary: the summary is extracted according to the file
   content and corresponding to the file and actually is file hash. This
   field can be used to identify the same cached content.

   type: the kinds of the transferred file, such as video, picture,
   document.

   file size: the size of the transferred file.

   code rate: it's specific for the video file.

   priority: the transferred priority level, such as normal, vip.

   timestamp: the time which the file is issued.

   random number: it provides the signature identity

   signature: it's produced according to the CID+content
   summary+type+file size+[code rate]+timestamp+random number and used
   to verify the validity of the tag.

   The tag can be embedded into the URL and the CDN can extract the tag
   from the URL. Through the tag service, the CDN can get the
   corresponding service information.

   Here is the example:

   the original URL:   
   http://wx.cvideo.com.cn/labels/video/xvideo4k.mp4

   the embedded tag URL:   
   http://wx.cvideo.com.cn/labels/video/xvideo4k.mp4?xlabels=Y2lkPTVCRUZ
   CRTIxNEY3OEJBMjhERjRGRjdFNkY0RkMwRjU5Jmhhc2g9RTFFOEI3MzVFMzM3QkEyQkRCQUM1
   MjQyRUUxMDc5RkImdHlwZT12aWRlbyZzaXplPTYuMzVHJmR1cmF0aW9uPTE4NjBzJnRpbWVzd
   GFtcD0xNDg2NjM2MDA3JnJhbmQ9ODkyMjMyMSZzaWduYXR1cmU9UTgwWjZMRFYyQkpWUVBHNl
   JIMFpXSU5TOU0tUEtKNUo=

   In fact, the length of URL is limited in CDN, so we put key
   information into the tag. We also design the tag related information
 

<Xia Yong>               Expires Sept 13, 2017                  [Page 6]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

   corresponding to each tag which mainly includes tag service
   information and tag transmission information. The tag service
   information includes content description,drama series, VIP
   accelerating and copyright etc. The tag transmission information
   include image resolution, play software requirements, cache nodes
   distribution and access interests etc. The CDN extracts the tag, get
   the corresponding tag related information and then provides
   corresponding service.

4.3 the preliminary design of the multi-service tag system

   We design a multilevel tree structure multi-service tag system which
   includes tag service center and tag servers.

   The tag service center is the core of the system which provides
   storage, renewal and inquiry service for the whole network tags and
   the related tag information.

   The tag server is deployed at the networks of CP or accelerating
   operators which can provide distributed tag information extraction,
   resolution and inquiry services.

                       |--------------------------------|
                       |     tag service center         |
                       |--------------------------------|
                                |                |
                                |                |               
                        |-------|                |
                        |                        |
   |----|      |-------------|                |-------------| 
   | CP |----->| tag server  |-----|          | tag server  |--|
   |----|      |-------------|     |          |-------------|  |
                     |             |                           |
                     |   |-------------|                       |
                     |   | tag server  |             |--------------|
                     |   |-------------|             | P2SP network |---|
                     |           |                   |--------------|   |
          |-----------------|    |                     |                |
          | CDN edge node   |    |                     |                |
          |-----------------|    |                     |    |---------------------|
                                 |            |-----------| | P2SP Speedup server |
                       |------------------|   | End User  | |---------------------|
                       | operator's cache |   |-----------|
                       |------------------|

                   Figure 1 the multi-service tag system
 

<Xia Yong>               Expires Sept 13, 2017                  [Page 7]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

   The related tag information and tag URL are usually stored at the tag server 
   and tag service center, the normal End Users only know the normal URL, so this system 
   has no influence on network devices and End Users. It needs the CDN/cache to do some 
   changes.

4.4 the workflow of multi-service tag in CDN

   The multi-service tag system provide public tag services including tag issuing and tag 
   recognition. The tag service can be distributed deployed so as to provide serving for 
   the whole network accelerating services similar to DNS service.

   The tag issuing workflow:

   1)The CP generates the tag through the tag service and embeds it to the corresponding URL;

   2)The CP publishes the URL to its websites and the tag system;

   3)The tag system records the tag information and updates the tag service center;

   4)The tag system provides tag information inquiry service to the CDN operators through 
   the distributed tag inquiry system.

   The tag recognition workflow:

   1)The CDN identifies the tag field in the URL;

   2)The CDN gets the basic information of the content transmission from the tag;

   3)The CDN gets the tag related information through the tag service interface;

   4)The CDN stores the tag's basic information and related information.

5  Analysis of application case

5.1  service perception by network

   The Internet video traffic becomes the major service traffic and the video traffic has 
   high demands for the transmission network and is sensitive to the network. The 4k programs 
   transmission needs more than 30Mbps bandwidth, it can't guarantee the QoS even though CDN 
   is used for the transmission. The core problem is that the network isn't able to know the 
   carried service and thus allocate resources dynamically. We can use multi-service tag to 
   resolve the problem. Because the tag can contain the information of the carried service, 
   the network operator can use tag to quickly identify and handle 4k program flow and 
   demands to network to allocate resource dynamically for the 4k flow.

5.2  intelligent cache

 

<Xia Yong>               Expires Sept 13, 2017                  [Page 8]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

   The cache technology is always one of the main technological means for decreasing 
   inter-network settlement charge and enhancing QoE. The maximal challenge which the 
   traditional cache technology faces is that the repetitive contents waste the cache resource.
    The core technology of the traditional cache is to obtain URL contents and store them 
   locally by monitoring the hot program's URLs through DPI. But the URL is not stable and 
   the same contents may have different URLs. Though we can use DPI to decode the content 
   and acquire partial content characteristics to compare, it has major limitations at 
   decreasing the repetitive contents and greatly increases the computation complexity, 
   what is more, the begin of the content is often advertisement or station caption and 
   this makes content comparison different to work well. The multi-service tag contains 
   the attribute information of carried content which is one-to-one correspondence to the 
   content, then the cache system can use the tag as the base of comparison so as to quickly 
   discover the repetitive contents and raise cache efficiency.

5.3  content exchange between little ISPs

   In order to reduce operating costs, little ISPs are apt to interconnect each other to 
   realize the user scale increase and resource sharing. Each little ISP has establish its 
   own cache system or CDN node in order to decrease the inter-network settlement expense 
   with the large ISP. The different little ISP must indicate the location of content storage
    and content itself, then issue the content URL. The multi-service tag not only include
    the information of the content and also bound together with the URL to transfer, thus 
   resolve the problem of program content sharing after ISP interconnection.

6 Simple Demo

   We establish a simple demo to validate the availability of multi-service tag, irrespective
    of security, network complexity and other factors.

   In our demo, we make some simplification for the real network components and the network 
   structure is shown in Figure 2.

                      Test Terminal --------- content server

                          Figure 2 Demo network structure

   The content server simulates the CDN edge node, its function includes:extract the tag 
   from URL, get the tag related information, serve the user according to the related 
   information.

   We store two almost same h.264 video of 4K 60P at the content server, one has normal URL 
   and other has tag URL with VIP priority. We watch these two video files and statistics 
   the output bandwidth. In order to watch the video normally, it needs about 30M bandwidth. 
   For the normal URL, we see about 6M output bandwidth. For the tag URL, we see about 30M 
   output bandwidth. Through this demo, the tag URL can work well.

 

<Xia Yong>               Expires Sept 13, 2017                  [Page 9]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

7 Security Considerations

   TBD.

8  IANA Considerations

   There is no IANA action in this document.

9  Acknowledgements

   TBD.

 

<Xia Yong>               Expires Sept 13, 2017                 [Page 10]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

8  References

8.1  Normative References

 

<Xia Yong>               Expires Sept 13, 2017                 [Page 11]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Mar 13, 2017

Authors' Addresses

   Yong Xia
   China SARFT
   Email: xiayong@abs.ac.cn

   Shihui Duan
   China Academy of Telecommunication Research of MIIT
   Email: duanshihui@catr.cn

   Shu Liu
   China Academy of Telecommunication Research of MIIT
   Email: liushu@catr.cn

   Rachel Huang
   Huawei
   Email: rachel.huang@huawei.com

<Xia Yong>               Expires Sept 13, 2017                 [Page 12]