Internet DRAFT - draft-zhang-icn-uscamulsertag
draft-zhang-icn-uscamulsertag
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
