idnits 2.17.1 draft-fossati-tsvwg-lola-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2018) is 1957 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-white-tsvwg-nqb-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Fossati 3 Internet-Draft Nokia 4 Intended status: Standards Track G. Fairhurst 5 Expires: June 19, 2019 University of Aberdeen 6 P. Aranda Gutierrez 7 Universidad Carlos III de Madrid 8 M. Kuehlewind 9 ETH Zurich 10 December 16, 2018 12 A Loss-Latency Trade-off Signal for the Mobile Network 13 draft-fossati-tsvwg-lola-00 15 Abstract 17 This document proposes a marking scheme for tagging low-latency flows 18 (for example: interactive voice and video, gaming, machine to machine 19 applications) that is safe to use by the mobile network for matching 20 such flows to suitable per-hop behaviors (EPS bearers defined by 21 3GPP) in its core and radio segments. The suggested scheme re-uses 22 NQB, a DiffServ-based signalling scheme with compatible rate-delay 23 trade-off semantics that has been recently introduced in the context 24 of fixed access to allow differential treatment of non-queue building 25 vs queue building flows. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 19, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. DiffServ Code . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Relationship to a Mobile DiffServ Domain . . . . . . . . . . 4 66 6. On Remarking and Bleaching . . . . . . . . . . . . . . . . . 4 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 73 11.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 Today's mobile networks are configured to bundle all flows to and 79 from the Internet into a single "default" EPS bearer whose buffering 80 characteristics are not compatible with low-latency traffic. The 81 established behaviour is partly rooted in the desire to prioritise 82 operators' voice services over competing over-the-top services. Of 83 late, said business consideration seems to have lost momentum and the 84 incentives might now be aligned towards allowing a more suitable 85 treatment of Internet real-time flows. However, a couple of 86 preconditions need to be satisfied before we can move on from the 87 status quo. First, the real-time flows must be efficiently 88 identified so that they can be quickly assigned to the "right" EPS 89 bearer. This is especially important with the rising popularity of 90 encrypted and multiplexed transports, which has the potential of 91 increasing the cost/accuracy ratio of Multi-Field (MF) based 92 classification over the acceptable threshold. Second, the signal 93 must be such that malicious or badly configured nodes can't abuse it. 94 Today's mobile networks take a rather extreme posture in this respect 95 by actively discarding (remarking or bleaching [Custura]) DiffServ 96 signalling coming from an interconnect. Therefore, the signal must 97 be modelled in a way that the mobile network can either trust it or, 98 even better, avoid the need of trusting it in the first place. The 99 Rate-Delay trade-off [Podlesny] satisfies the above requirements and 100 has been shown [Fossati] to integrate well with a simplified LTE QoS 101 setup that uses one dedicated low-latency bearer in addition to the 102 default. 104 This document suggests reusing the Non Queue Building (NQB) 105 signalling protocol described in [I-D.white-tsvwg-nqb] as the method 106 employed by endpoints to mark their real-time flows and by the LTE 107 network to classify and route these flows via a suitable (low- 108 latency) bearer through the LTE core network and E-UTRAN. 110 2. Terminology 112 o DPI: Deep Packet Inspection 114 o EPS bearer: Evolved Packet System bearer, a virtual circuit with a 115 given set of QoS attributes which spans the entire mobile network 116 including the LTE core and E-UTRAN segments; 118 o GBR: Guaranteed Bit Rate. EPS bearers can be GBR, in which case 119 they are guaranteed to not drop packets under congestion, or non- 120 GBR, in which case no guarantee of delivery is made by the mobile 121 network; 123 o LTE: 3GPP Long Term Evolution, aka 4G; 125 o E-UTRAN: LTE Radio Access Network; 127 o QCI: QoS Class Identifier. In LTE networks, EPS bearers are 128 partitioned into equivalency classes modulo the QoS treatment they 129 receive. QCI is an integer that labels a specific QoS class. Its 130 semantics is consistently understood by all network elements 131 involved in packet forwarding; 133 o UE: User Equipment, any device (e.g., smartphone, laptop, tablet) 134 attached to an LTE network. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 3. DiffServ Code 144 Given the semantic equivalence of a Loss-Latency trade-off with the 145 Non Queue Building (NQB) behaviour, this document reuses the NQB DSCP 146 (Section 4 of [I-D.white-tsvwg-nqb]) as-is. 148 4. Marking 150 Endpoints SHOULD mark packets that belong to the Best Effort class 151 and are latency sensitive by assigning the NQB DSCP value to the DS 152 field. 154 The marking could also be added to other BE traffic if the default 155 class could be reclassified by the network to use the NQB DSCP before 156 the packet enters the mobile domain - for example by a classifier in 157 the SGi-LAN or in an LTE router. 159 5. Relationship to a Mobile DiffServ Domain 161 The Mobile network is configured to give UEs a dedicated, low- 162 latency, non-GBR, EPS bearer with QCI 7 in addition to the default 163 EPS bearer. 165 A packet carrying the NQB DSCP shall be routed through the dedicated 166 low-latency EPS bearer. A packet that has no associated NQB marking 167 shall be routed through the default EPS bearer. 169 6. On Remarking and Bleaching 171 NQB markings SHOULD be preserved when forwarding via an interconnect. 173 The NQB DSCP can have end-to-end semantics and this might benefit any 174 NQB-marked traffic if utilised by other path elements (e.g. allowing 175 DS treatment if a bottleneck link happens to be in the part of the 176 path outisde the mobile access network segment). 178 7. IANA Considerations 180 This document makes no request to IANA. 182 8. Security Considerations 184 Internet applications cannot benefit from wrongly indicating low- 185 latency as they have to pay the expense of high loss as a trade-off. 186 Hence there is no incentive for Internet applications to set the 187 wrong code-point. 189 The NQB signal is not integrity protected and could be flipped by an 190 on-path attacker. This might negatively affect the QoS of the 191 tampered flow. 193 9. Privacy Considerations 195 As described in [Shbair] state of art encrypted traffic analysis 196 based machine learning can successfully identify the type of 197 transported application (e.g., HTTPS, SMTP, P2P, VoIP, SSH, Skype) 198 with good accuracy and without any need to access the clear-text. In 199 this context, despite it being coarse grained, a 1-bit signal such as 200 the one described in this document might be used to improve the 201 precision of the classifier. 203 10. Acknowledgments 205 We would like to thank the authors of the "Latency Loss Tradeoff PHB 206 Group" draft: Jianjie You, Michael Welzl, Brian Trammell and Kevin 207 Smith. Big thanks to Chris Seal, Dan Druta, Diego Lopez, Shamit 208 Bhat, Georg Mayer, Florin Baboescu, James Gruessing for the help. 210 This work is partially supported by the European Commission under 211 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 212 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 213 for Education, Research, and Innovation under contract no. 15.0268. 214 This support does not imply endorsement. 216 11. References 218 11.1. Normative References 220 [I-D.white-tsvwg-nqb] 221 White, G., "Identifying and Handling Non Queue Building 222 Flows in a Bottleneck Link", draft-white-tsvwg-nqb-00 223 (work in progress), October 2018. 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, 227 DOI 10.17487/RFC2119, March 1997, 228 . 230 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 231 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 232 May 2017, . 234 11.2. Informative References 236 [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP 237 modification pathologies in mobile edge networks", TMA , 238 2017. 240 [Fossati] Fossati, T., Aranda Gutierrez, P., Kuehlewind, M., and D. 241 Lopez, "Loss Latency Tradeoff and the Mobile Network", 242 2018, . 246 [Podlesny] 247 Podlesny, M. and S. Gorinsky, "Rd Network Services: 248 Differentiation Through Performance Incentives", SIGCOMM , 249 2008. 251 [Shbair] Shbair, W., Cholez, T., Francois, J., and I. Chrisment, "A 252 Multi-Level Framework to Identify HTTPS Services", NOMS , 253 2016. 255 Authors' Addresses 257 Thomas Fossati 258 Nokia 260 Email: thomas.fossati@nokia.com 262 Gorry Fairhurst 263 University of Aberdeen 265 Email: gorry@erg.abdn.ac.uk 267 Pedro A. Aranda Gutierrez 268 Universidad Carlos III de Madrid 270 Email: paranda@it.uc3m.es 272 Mirja Kuehlewind 273 ETH Zurich 275 Email: mirja.kuehlewind@tik.ee.ethz.ch