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, [RFC3260] D. Grossman, "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002, 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