[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

N Working Group
Internet Draft                                                Zhang Wei
Document: draft-zhang-icn-uscamulsertag-00.txt                  He Jing
Expires: September 11, 2019                               China SAPPRFT
                                                             March 2019


           the Use Cases for the Application of Multi-Service Tag
                      draft-zhang-icn-uscamulsertag-00


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 https://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 Nov 11, 2019.



Abstract

   Based on the important concepts and research challenges described in
   RFC 7927, we consider multi-service tagging technology to be an
   effective name mechanism for audio and video content in ICN. Since
   audio and video traffic is the primary traffic transmitted over the
   Internet, it will greatly advance the current Internet architecture
   to the ICN architecture, the name mechanism for creating audio and
   video content. This article discusses typical cases of improvements
   using name mechanisms, including content resource exchange between
   different ISPs, resource caching of content naming information, and
   data distribution for different transmission quality requirements in
   low latency environments.


Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.


Zhang                  Expires - September 2019               [Page 1]


                   draft-zhang-icn-uscamulsertag-00         March 2019


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [i].

Copyright Notice

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

Table of Contents

   1. Introduction...................................................2
   2. Terminology and Acronyms.......................................3
   3. Use cases......................................................3
      3.1 content resource sharing across ISP network................3
      3.2 cache according to the content naming information..........4
      3.3 Media transmission for different latency levels............4
   Security Considerations...........................................5
   IANA Considerations...............................................5
   References........................................................5
   Author's Addresses................................................5


1. Introduction
   Now the network traffic presents a rapid increase trend, the
   popularization of network audio and video and the diversified viewing
   model modes support watch audio and video in anytime and
   anywhere,which also results in the increase of network traffic. The
   network audio and 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


Zhang                  Expires - September 2019               [Page 2]


                   draft-zhang-icn-uscamulsertag-00         March 2019


   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.

2. Terminology and Acronyms


   This document makes use of the same terminology and definitions as
   RFC 7927 [RFC7927].  In addition it uses the terms defined
   below:

      Multi-Service Tag: uses the tag field in each packet header to
   mark packets according to their service class so that the network can
   easily recognize packets that need to be treated preferentially.

3. Use cases
3.1 content resource sharing across ISP network

   The Internet audio and video transmission usually uses the CDN
   technology and cache technology to provide service for users and the
   CP will deploy the CDN or cache nodes according to the user
   distribution in the operator network. In order to guarantee QoE, the
   CP will deploy CDN nodes with full resource in the network center and
   CDN nodes with hot resource at the network edge which usually locate
   in the operator's premises network. Each premises network operator
   has its own IP address field and the user's IP address is allocated
   by the premises network operator. In the current IP network, the CP
   can find the nearest resource only according to the IP address in the
   inquiry and then schedule the corresponding CDN node to serve the
   user, if the edge CDN node has no the resource asked by the user, the
   CP will haul the user inquiry back to the center CDN nodes with full
   resource and schedule the corresponding resource to serve the user,
   and this can easily form the network congestion of ISP haul-back
   route and increase the network delay. Though the different ISP
   premises networks have routing reachability, the content resource
   can't be sharing among different IPS.


   Under the audio and video scheduling mechanism based on the IP
   address, IP address will fragment the network resource and the same
   content will have many IP address or URL, thus CP or ISP have to use
   large storage resource to deploy the same hot content. IP address and


Zhang                  Expires - September 2019               [Page 3]


                   draft-zhang-icn-uscamulsertag-00         March 2019


   URL are all the network address information independent of the
   content and the operator can't share the content through the address
   information.


   In ICN, we can use the multi-service tag naming scheme to realize the
   content resource sharing among ISPs and form larger content resource
   sharing pool, thus all user can acquire the content in the pool and
   it breaks the IP-ISP resource closed mechanism. The multi-service tag
   assembly modular can acquire all ISP network resource information and
   the user can use this information to find the relevant content.


3.2 cache according to the content naming information

   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.


3.3 Media transmission for different latency levels
   In some organizations, such as audio station or television station,
   there are both unscheduled non-real-time traffic and different levels
   of time-sensitive media traffic, which have different transmission
   priorities. With the DiffServ method [RFC3260], the device uses the
   appropriate DSCP value to flag the outgoing traffic, but note that
   DiffServ is a coarse-grained QoS architecture that handles traffic
   traffic by category rather than individual traffic. As in an audio
   and video stream, the priority of audio and video streams should be
   consistent, different media streams, audio and video media streams
   (such as multicast) with low transmission delay requirements, and
   media streams required for normal transmission delays (such as media
   streams migration in different unit). The QoS level of the migration
   needs to be distinguished by the name service to avoid the low
   transmission delay audio and video media stream cannot meet the


Zhang                  Expires - September 2019               [Page 4]


                   draft-zhang-icn-uscamulsertag-00         March 2019


   transmission delay requirement due to the same service priority media
   profile.


   Multi-service tag identify traffic levels through content tag. The
   tag value is assigned by the server that generates the traffic
   according to certain rules. The transmission interaction device can
   adopt multiple content transmission selection algorithms according to
   the label value, and a more general one is a strict priority
   algorithm. According to this algorithm, the oldest data packet is
   selected for transmission from a non-empty queue with a higher
   priority. Therefore, high-priority audio and video traffic will have
   the lowest latency, while lower-priority audio and video traffic may
   result in longer transmission delays and even timeouts. This hunger
   state can be achieved through more complex selection algorithms, but
   with high priority traffic latency will become higher.

4. Security Considerations

   This document has no security considerations.

5. IANA Considerations

   There is no IANA action in this document.

6. References
6.1 Normative References
   TBD

6.2 Informative References
    [RFC7927] D. Kutscher, S., "Information-Centric Networking (ICN)
             Research Challenges", RFC 7927, July 2016,
             <https://www.rfc-editor.org/rfc/rfc7927.txt>

    [RFC3260] D. Grossman, "New Terminology and Clarifications for
             Diffserv", RFC 3260, April 2002, <https://www.rfc-
             editor.org/rfc/rfc3260.txt>





Author's Addresses

   Zhang Wei
   China SAPPRFT
   Email: zhangwei@abs.ac.cn

   He Jing


Zhang                  Expires - September 2019               [Page 5]

                   draft-zhang-icn-uscamulsertag-00         March 2019


   China SAPPRFT
   Email: hejing@abs.ac.cn


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/