Internet DRAFT - draft-fossati-tsvwg-lola
draft-fossati-tsvwg-lola
Network Working Group T. Fossati
Internet-Draft Nokia
Intended status: Standards Track G. Fairhurst
Expires: June 19, 2019 University of Aberdeen
P. Aranda Gutierrez
Universidad Carlos III de Madrid
M. Kuehlewind
ETH Zurich
December 16, 2018
A Loss-Latency Trade-off Signal for the Mobile Network
draft-fossati-tsvwg-lola-00
Abstract
This document proposes a marking scheme for tagging low-latency flows
(for example: interactive voice and video, gaming, machine to machine
applications) that is safe to use by the mobile network for matching
such flows to suitable per-hop behaviors (EPS bearers defined by
3GPP) in its core and radio segments. The suggested scheme re-uses
NQB, a DiffServ-based signalling scheme with compatible rate-delay
trade-off semantics that has been recently introduced in the context
of fixed access to allow differential treatment of non-queue building
vs queue building flows.
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 June 19, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fossati, et al. Expires June 19, 2019 [Page 1]
Internet-Draft Loss-Latency Tradeoff December 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DiffServ Code . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Relationship to a Mobile DiffServ Domain . . . . . . . . . . 4
6. On Remarking and Bleaching . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . 4
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
11.1. Normative References . . . . . . . . . . . . . . . . . . 5
11.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Today's mobile networks are configured to bundle all flows to and
from the Internet into a single "default" EPS bearer whose buffering
characteristics are not compatible with low-latency traffic. The
established behaviour is partly rooted in the desire to prioritise
operators' voice services over competing over-the-top services. Of
late, said business consideration seems to have lost momentum and the
incentives might now be aligned towards allowing a more suitable
treatment of Internet real-time flows. However, a couple of
preconditions need to be satisfied before we can move on from the
status quo. First, the real-time flows must be efficiently
identified so that they can be quickly assigned to the "right" EPS
bearer. This is especially important with the rising popularity of
encrypted and multiplexed transports, which has the potential of
increasing the cost/accuracy ratio of Multi-Field (MF) based
classification over the acceptable threshold. Second, the signal
must be such that malicious or badly configured nodes can't abuse it.
Today's mobile networks take a rather extreme posture in this respect
by actively discarding (remarking or bleaching [Custura]) DiffServ
signalling coming from an interconnect. Therefore, the signal must
Fossati, et al. Expires June 19, 2019 [Page 2]
Internet-Draft Loss-Latency Tradeoff December 2018
be modelled in a way that the mobile network can either trust it or,
even better, avoid the need of trusting it in the first place. The
Rate-Delay trade-off [Podlesny] satisfies the above requirements and
has been shown [Fossati] to integrate well with a simplified LTE QoS
setup that uses one dedicated low-latency bearer in addition to the
default.
This document suggests reusing the Non Queue Building (NQB)
signalling protocol described in [I-D.white-tsvwg-nqb] as the method
employed by endpoints to mark their real-time flows and by the LTE
network to classify and route these flows via a suitable (low-
latency) bearer through the LTE core network and E-UTRAN.
2. Terminology
o DPI: Deep Packet Inspection
o EPS bearer: Evolved Packet System bearer, a virtual circuit with a
given set of QoS attributes which spans the entire mobile network
including the LTE core and E-UTRAN segments;
o GBR: Guaranteed Bit Rate. EPS bearers can be GBR, in which case
they are guaranteed to not drop packets under congestion, or non-
GBR, in which case no guarantee of delivery is made by the mobile
network;
o LTE: 3GPP Long Term Evolution, aka 4G;
o E-UTRAN: LTE Radio Access Network;
o QCI: QoS Class Identifier. In LTE networks, EPS bearers are
partitioned into equivalency classes modulo the QoS treatment they
receive. QCI is an integer that labels a specific QoS class. Its
semantics is consistently understood by all network elements
involved in packet forwarding;
o UE: User Equipment, any device (e.g., smartphone, laptop, tablet)
attached to an LTE network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Fossati, et al. Expires June 19, 2019 [Page 3]
Internet-Draft Loss-Latency Tradeoff December 2018
3. DiffServ Code
Given the semantic equivalence of a Loss-Latency trade-off with the
Non Queue Building (NQB) behaviour, this document reuses the NQB DSCP
(Section 4 of [I-D.white-tsvwg-nqb]) as-is.
4. Marking
Endpoints SHOULD mark packets that belong to the Best Effort class
and are latency sensitive by assigning the NQB DSCP value to the DS
field.
The marking could also be added to other BE traffic if the default
class could be reclassified by the network to use the NQB DSCP before
the packet enters the mobile domain - for example by a classifier in
the SGi-LAN or in an LTE router.
5. Relationship to a Mobile DiffServ Domain
The Mobile network is configured to give UEs a dedicated, low-
latency, non-GBR, EPS bearer with QCI 7 in addition to the default
EPS bearer.
A packet carrying the NQB DSCP shall be routed through the dedicated
low-latency EPS bearer. A packet that has no associated NQB marking
shall be routed through the default EPS bearer.
6. On Remarking and Bleaching
NQB markings SHOULD be preserved when forwarding via an interconnect.
The NQB DSCP can have end-to-end semantics and this might benefit any
NQB-marked traffic if utilised by other path elements (e.g. allowing
DS treatment if a bottleneck link happens to be in the part of the
path outisde the mobile access network segment).
7. IANA Considerations
This document makes no request to IANA.
8. Security Considerations
Internet applications cannot benefit from wrongly indicating low-
latency as they have to pay the expense of high loss as a trade-off.
Hence there is no incentive for Internet applications to set the
wrong code-point.
Fossati, et al. Expires June 19, 2019 [Page 4]
Internet-Draft Loss-Latency Tradeoff December 2018
The NQB signal is not integrity protected and could be flipped by an
on-path attacker. This might negatively affect the QoS of the
tampered flow.
9. Privacy Considerations
As described in [Shbair] state of art encrypted traffic analysis
based machine learning can successfully identify the type of
transported application (e.g., HTTPS, SMTP, P2P, VoIP, SSH, Skype)
with good accuracy and without any need to access the clear-text. In
this context, despite it being coarse grained, a 1-bit signal such as
the one described in this document might be used to improve the
precision of the classifier.
10. Acknowledgments
We would like to thank the authors of the "Latency Loss Tradeoff PHB
Group" draft: Jianjie You, Michael Welzl, Brian Trammell and Kevin
Smith. Big thanks to Chris Seal, Dan Druta, Diego Lopez, Shamit
Bhat, Georg Mayer, Florin Baboescu, James Gruessing for the help.
This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat
for Education, Research, and Innovation under contract no. 15.0268.
This support does not imply endorsement.
11. References
11.1. Normative References
[I-D.white-tsvwg-nqb]
White, G., "Identifying and Handling Non Queue Building
Flows in a Bottleneck Link", draft-white-tsvwg-nqb-00
(work in progress), October 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Fossati, et al. Expires June 19, 2019 [Page 5]
Internet-Draft Loss-Latency Tradeoff December 2018
11.2. Informative References
[Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP
modification pathologies in mobile edge networks", TMA ,
2017.
[Fossati] Fossati, T., Aranda Gutierrez, P., Kuehlewind, M., and D.
Lopez, "Loss Latency Tradeoff and the Mobile Network",
2018, <https://github.com/mami-
project/roadshows/blob/master/ietf-103-lola/hotrfc/build/
main.pdf>.
[Podlesny]
Podlesny, M. and S. Gorinsky, "Rd Network Services:
Differentiation Through Performance Incentives", SIGCOMM ,
2008.
[Shbair] Shbair, W., Cholez, T., Francois, J., and I. Chrisment, "A
Multi-Level Framework to Identify HTTPS Services", NOMS ,
2016.
Authors' Addresses
Thomas Fossati
Nokia
Email: thomas.fossati@nokia.com
Gorry Fairhurst
University of Aberdeen
Email: gorry@erg.abdn.ac.uk
Pedro A. Aranda Gutierrez
Universidad Carlos III de Madrid
Email: paranda@it.uc3m.es
Mirja Kuehlewind
ETH Zurich
Email: mirja.kuehlewind@tik.ee.ethz.ch
Fossati, et al. Expires June 19, 2019 [Page 6]