One document matched: draft-deng-ippm-wireless-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY RFC4656 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4656.xml">
<!ENTITY RFC5357 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5357.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-deng-ippm-wireless-01.txt" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>Problem Statement for IP measurement in mobile networks
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Lingli Deng" initials='L.L.'
surname="Deng">
<organization>China Mobile</organization>
<address>
<email>denglingli@chinamobile.com</email>
</address>
</author>
<author fullname="Zhen Cao" initials='Z.'
surname="Cao">
<organization>China Mobile</organization>
<address>
<email>caozhen@chinamobile.com</email>
</address>
</author>
<date day="12" month="February" year="2014" />
<!-- Meta-data Declarations -->
<area></area>
<workgroup>IPPM</workgroup>
<keyword></keyword>
<abstract>
<t>This document analyzes the potential problems of applying existing IP-based performance measurement methods to wireless
accessing environments. It suggests that a more flexible passive measuring framework and performance metrics, such as congestion
ratio are needed.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>It is well-accepted that mobile Internet usage is going to increase fast in the coming years and replace the traditional
voice service to be the dominant revenue source for mobile operators. In the meantime, fast evolving network and terminal
technologies and changing service trend (e.g. social networking, video on demand, online reading, etc.) results in higher
user service requirement. Therefore, as the basic infrastructure service provider, operators are deemed responsible for mobile
Internet end-to-end performance, for subscribers want to get what they want, which gives rise to a basic yet important question:
how does network service provider manage end-to-end service quality? In particular, there are two goals for operator's quality
management initiative:
<list style="symbols">
<t>to make sure and validate the QoS metrics of specific IP flows against the values pre-defined by the service SLA(Service Level
Agreement) from the user/service provider's point of view; and</t>
<t>to make sure and validate the sanity of network devices/links.</t>
</list>
</t>
<t> In this draft, we present three usecases and the potential problems of applying existing IP-based performance measurement methods
to wireless accessing environments, where resource pooling and dynamic load balancing techniques are employed to accommodate
explosively increasing data traffic, and suggest requirements for more robust passive measuring methods and
performance metrics for such environment.</t>
</section>
<section title="Motivation">
<section title="Dynamic Load Balancing">
<t>Pooling technology has been introduced to the user plane in the packet switched domain of operator's core network for cellular
subscribers since 3GPP Release 5 (3GPP TS23.236). With pooling, the traffic path from user equipments to the Internet
via core network is not static, but rather dynamically assigned to a proper instance of an device pool, according to load balancing
policies. The assignment is dynamically made at the time of user equipment's attachment establishment with the cellular core network,
and would remain unchanged unless the mobile terminal detaches from the network or moves outside the base-stations' coverage subordinating
to the specific core network's device pool.</t>
<t>As shown by <xref target="ps_load_balance"/>, potential device pools along the path all the way from the user terminal via the packet
switching domain of the mobile network core to a third party service provider over the Internet. Examples of network devices that can
be poolized include SGSN(Serving GPRS Support Node) and GGSN(Gateway GPRS Supporting Node). Moreover, the service provider could also
implement load balancing on the server's side either via server-pooling within a data center or via (third party) CDN nodes.</t>
<figure align="center" anchor="ps_load_balance" title="Active Measuring Traffic versus Actual Traffic in case of Device Pooling">
<artwork align="left">
<![CDATA[
Radio |Packet |Internet
Access |Switching |
Network |Core Network |
| +--------+ +----+---+ +--------+
| |+------+| |+------+| |+------+|
| +-->|SGSN_1|+------->|GGSN_1|+--+ ||SERV_1||
| | |+------+| |+------+| | |+------+|
+--+ +--+--+ +-----+ | | | | | | | |
| |---->| +--->| +--+ |+------+| |+------+| | |+------+|
|UE| |NodeB| | RNC | ||SGSN_2|| ||GGSN_2|| +---->|SERV_2||
| |....>| |...>| |... |+------+| |+------+| |+------+|
+--+ +--+--+ +-----+ . | | | | | |
| . | ... | | ... | | ... |
| . |+------+| |+------+| |+------+|
+--------------------+ ...>|SGSN_N|........>|GGSN_M|........>|SERV_K||
| Injected Traffic | |+------+| |+------+| |+------+|
| ---------------> | +--------+ +----+---+ +--------+
| Actual Traffic | |
| ...............> | |
+--------------------+
]]>
</artwork>
<postamble></postamble>
</figure>
<t>Hence, under such environments, if active performance measurement methods<xref target="RFC4656"/><xref target="RFC5357"/> are
employed, the injected bogus data traffic may traverse along a different path to the one used by the targeted traffic or even interfere
with them due to the subtle nature of wireless-involved links (as explained in the next subsection).</t>
</section>
<section title="Radio Congestion Detection">
<t>Mobile Internet usage is going to increase fast in the coming years due to the following facts: on one hand, as a result
of pervasively deployed and fast maturing 3G/4G cellular technologies combined with smartphone's dominance in mobile handset's
market, Internet data traffic via mobile operator's packet switched core network manifests to be an increasingly important
contributor to the operator's revenue. On the other hand, wireless technologies (such as Wi-Fi through APs or cellular networks
through small cells) are more and more accepted by the end users, either at home, in the office or in a public place, to be
carrying the "last mile" to various portable personal computing devices.</t>
<t>There are two common features of the above two scenarios:
<list style="symbols">
<t>the combination of both wireless and wired links along the end-to-end traffic path, and</t>
<t>almost all the time, the wireless "last mile" would be the bottleneck of end-to-end service quality.</t>
</list>
</t>
<t>To make more efficient use of relatively more scarce radio resources, it is important for the core network to understand the
congestion status of both wireless and wired links along the traffic path, and make proper management of data traffic through cell
reselection or load balancing via pooling.</t>
<t>However, the wireless link's thoughput is consistently subject to other interfering factors (e.g. distance to the nearest
base station, terminal's radio signal strength, random interference, shadowing of buildings, multipath fading, etc.), which should
be properly filtered out before handing over to the network management, as they are rooted in terminal mobility and outside the realm
of mobile accessing network.</t>
<t>In other words, there is considerable gap between IP measurement results to the performance evaluation and fault detection
requirements in mobile-involved environment, if we directly employ existing passive performance measurement methods<xref target=
"I-D.draft-chen-ippm-coloring-based-ipfpm-framework"/>.</t>
</section>
<section title="Accurate Troubleshooting">
<t>As shown in <xref target="ps_core_tunnelling"/>, it is quite common that there are path partitions (belonging to different
operation and management departments) along the local data path from the UE to the Internet within an mobile operator's
local network. For large operators, employing layered network operation and management architecture based on geographic partitions,
there may be a further more subpath partitioning between local IP backhaul (managed by state subordinaries) and national IP backhaul
(managed by headerquarters). Moreover, for roaming cases under home-routed mode (meaning all the traffic from a roaming UE would
first traverse from the visited ISP and potentially another Internet operator before getting back to homing ISP network.</t>
<t>Take the example of a mobile subscriber getting access from a 3GPP network for example, besides a local
mobile network operator, intermediary ISPs may exist between its traffic before it reaches the Internet. Moreover, within the local
operator's network, radio access network (RAN), RAN backhual and local core network could actually be constructed and managed by
stuff from different departments, for they mainly come from different technical background.</t>
<t>In such complex situations, it can become frustrating to respond quickly to a simple UoE complaint, due to the exponentially
exploded complexity to accurately locate the potential faults/congestion in a transient wireless-involved end2end data path. </t>
<t>On the other hand, tunnels, including GRE [RFC2784], GTP [TS29.060], IP-in-IP [RFC2003] or
IPSec [RFC4301] etc, are widely deployed in 3GPP networks. And in 3GPP network tunnels are used to carry end user flows
within the backhaul network. Tunnels brings another complexity in realizing effective troubleshooting using end2end passive methods.</t>
<figure align="center" anchor="ps_core_tunnelling" title="Example of path partition in 3GPP network">
<artwork align="left">
<![CDATA[
\\|/
|
|
+-|---+ +------+ +------+ +------+
+--+ | | Tunnel1 | | Tunnel2 | | Ext | |
|UE|-(RAN)-| eNB |===========| S-GW |=========| P-GW |--------| SP |
+--+ | | RAN | | Core | |Network | |
+-+---+ Backhaul +---+--+ Network +---+--+ +---+--+
]]>
</artwork>
<postamble></postamble>
</figure>
<t>In other words, a flexible passive measurement framework, capable of dynamic troubleshooting for partitioned data link, even
in case of tunnels or autonomous entities is highly valuable. However, neither current active measurement framework as used
by OWAMP[RFC4656]/TWAMP[RFC5357], nor the passive framework proposed in
<xref target="I-D.draft-chen-ippm-coloring-based-ipfpm-framework"/> could fit in such case.</t>
</section>
<section title="Summary">
<t>In summary, for mobile-ended data paths, we believe there is need for
<list style="symbols">
<t>viable passive measurement framework for active measurements inject extra traffic, which may traverse along a different
path to the one used by the targeted traffic or even interfere with them.</t>
<t>robust metric against transient wireless conditions, as there is considerable gap between existing IP measurement metrics
(e.g. delay, jitter, throughput etc.), which are subject to change caused by external environmental factors and of little
use to operator's traffic management from the network side.</t>
<t>flexible and trustworthy measurement mechanisms for accurate performance monitory and troubleshooting from multi-hop data
link across operation boundaries.</t>
</list>
</t>
</section>
</section>
<section title="Further Considerations">
<section title="Congestion ratio metric">
<t>ECN signal for congestion measurement are signalled at IP header by intermediary devices before actual congestion occurs, which
is expected to be an effective indicator to potential QoE degradation, irrespective to traffic pattern/wireless conditions.</t>
<t><xref target="I-D.draft-hedin-ippm-type-p-monitor"/> proposes to echo ECN-flags into TWAMP-test feedback for active measurement.
While, packet-level echoing is not viable in passive framework, it is also suspected that more meaningful aggregated information
(such as congestion extent, defined as the ratio of marked packets versus all packets from a given IP flow) would be preferred.</t>
</section>
<section title="Multi-hop Measurement Framework">
<t>In current active measurement framework, there is only two entities on the data path, the sender and the reflector. Hence it is
not straightforward how to apply this framework to an integral multi-hop passive measurement case. </t>
<t>On the other hand, the centralized multi-hop passive framework proposed in
<xref target="I-D.draft-chen-ippm-coloring-based-ipfpm-framework"/> could encounter problems when there is no prior knowledge about
or control over different partitions along the overall data path. In other words, path discovery mechanism is needed to identify
potential measurement nodes along the way during/before the actual passive measurement. </t>
</section>
</section>
<section title="Security Considerations">
<t>If measuring nodes from different operational domains are used, proper device authentication and report authenticity protection
mechanisms should also be considered in a complete interworking-capable solution.</t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC2234;
</references>
<references title="Informative References">
<reference anchor="RFC4656">
<front>
<title>A One-way Active Measurement Protocol (OWAMP)</title>
<author initials="S." surname="Shalunov" fullname="S. Shalunov">
<organization/>
</author>
<author initials="B." surname="Teitelbaum" fullname="B. Teitelbaum">
<organization/>
</author>
<author initials="A." surname="Karp" fullname="A. Karp">
<organization/>
</author>
<author initials="J." surname="Boote" fullname="J. Boote">
<organization/>
</author>
<author initials="M." surname="Zekauskas" fullname="M. Zekauskas">
<organization/>
</author>
<date year="2006" month="September"/>
<abstract>
<t>
The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4656"/>
<format type="TXT" octets="132303" target="http://www.rfc-editor.org/rfc/rfc4656.txt"/>
</reference>
<reference anchor="RFC5357">
<front>
<title>A Two-Way Active Measurement Protocol (TWAMP)</title>
<author initials="K." surname="Hedayat" fullname="K. Hedayat">
<organization/>
</author>
<author initials="R." surname="Krzanowski" fullname="R. Krzanowski">
<organization/>
</author>
<author initials="A." surname="Morton" fullname="A. Morton">
<organization/>
</author>
<author initials="K." surname="Yum" fullname="K. Yum">
<organization/>
</author>
<author initials="J." surname="Babiarz" fullname="J. Babiarz">
<organization/>
</author>
<date year="2008" month="October"/>
<abstract>
<t>
The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5357"/>
<format type="TXT" octets="61960" target="http://www.rfc-editor.org/rfc/rfc5357.txt"/>
</reference>
<reference anchor="I-D.draft-hedin-ippm-type-p-monitor" >
<front>
<title>Differentiated Service Code Point and Explicit Congestion Notification
Monitoring in Two-Way Active Measurement Protocol (TWAMP)</title>
<author initials="J." surname="Hedin">
<organization></organization>
</author>
<author initials="G." surname="Mirsky">
<organization></organization>
</author>
<author initials="S." surname="Baillargeon">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
<seriesInfo name="draft-hedin-ippm-type-p-monitor-02" value="(work in progress)" />
</reference>
<reference anchor="I-D.draft-chen-ippm-coloring-based-ipfpm-framework" >
<front>
<title>Coloring based IP Flow Performance Measurement Framework</title>
<author initials="M." surname="Chen">
<organization></organization>
</author>
<author initials="H." surname="Liu">
<organization></organization>
</author>
<author initials="Y." surname="Yin">
<organization></organization>
</author>
<author initials="R." surname="Papneja">
<organization></organization>
</author>
<author initials="S." surname="Abhyankar">
<organization></organization>
</author>
<author initials="G." surname="Deng">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
<seriesInfo name="draft-chen-ippm-coloring-based-ipfpm-framework-01" value="(work in progress)" />
</reference>
</references>
</back>
<!-- Here we use entities that we defined at the beginning. -->
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:10 |