idnits 2.17.1 draft-elkins-ippm-pdm-nn-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 (March 29, 2017) is 2585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-ippm-6man-pdm-option-09 == Outdated reference: A later version (-01) exists of draft-nieminen-ippm-nn-measurements-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT N. Elkins 3 B. Jouris 4 Intended Status: Informational Inside Products 5 Expires: September 30, 2017 March 29, 2017 7 Using PDM to Monitor Net Neutrality 8 draft-elkins-ippm-pdm-nn-00 10 Abstract 12 Monitoring of net neutrality is of interest to regulators as well as 13 users throughout the world. Standardized metrics are lacking. 14 Measurements need to be at the end user client, be able to accurately 15 separate wire and host time, detect quality of service provided to 16 individual applications and be lightweight. The IPv6 Performance and 17 Diagnostic Metrics (PDM) Destination Option meets all these criteria. 18 We propose that PDM be used for such measurements. A gap analysis 19 shows that PDM is available for IPv6 only and not for IPv4 or low 20 powered devices. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 49 3: This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://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 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 What Measurements Does PDM Provide? . . . . . . . . . . . . 3 63 1.2 How Does PDM Provide This Information? . . . . . . . . . . . 3 64 1.3 Definitions of Round-Trip Delay and Server Delay . . . . . . 4 65 1.4 How Will PDM Be Used to Measure Net Neutrality? . . . . . . 4 66 2 Advantages of PDM . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1 Advantages of PDM for Measurement . . . . . . . . . . . . . 4 68 2.2 Advantage of PDM for Scaleability . . . . . . . . . . . . . 5 69 2.3 Isolating Wire Time Accurately . . . . . . . . . . . . . . . 5 70 2.4 Measurement of the Application . . . . . . . . . . . . . . . 5 71 2.5 Calculation of speed . . . . . . . . . . . . . . . . . . . . 6 72 2.6 Lightweight measurement technique . . . . . . . . . . . . . 6 73 2.7 Universal Measurement Technique . . . . . . . . . . . . . . 6 74 3 Gap Analysis of PDM in Net Neutrality Measurements . . . . . . . 7 75 3.1 PDM for IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2 PDM for Low Powered Devices . . . . . . . . . . . . . . . . 7 77 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 78 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 79 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 81 6.2 Informative References . . . . . . . . . . . . . . . . . . . 7 82 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1 Background 87 The question of whether one is actually getting the wire speed that 88 one is paying for is complex. In [NNRequire], European regulators 89 make the use case: "The European Regulation requires internet service 90 providers (ISPs) to specify new speed values for example minimum, 91 maximum, and normally available speeds in fixed network. The 92 measurement use case is to assess if these contractual speed values 93 are met. The problem is to define measurements that can be run by 94 end-users and is accurate enough to have legal value." 96 A number of factors enter into measuring such time: 98 1. Measurement which resides at the end-user client 100 2. Separating wire time from the application / stack time 102 3. Accuracy of measurement 104 The hybrid measurement technique, IPv6 PDM defined in [PDM] embeds 105 timing information in each packet. Such values may be used to 106 estimate QoS as experienced by an end user device. PDM also provides 107 the ability to determine quickly if the (latency) problem is in the 108 network or in the server (application). 110 1.1 What Measurements Does PDM Provide? 112 PDM provides: 114 1. Round-trip delay (wire time) 115 2. Server delay (host time) 117 1.2 How Does PDM Provide This Information? 119 From [PDM], Section 2: Measurement Information Derived from PDM 121 "Each packet contains information about the sender and receiver. In 122 IP protocol, the identifying information is called a "5-tuple". 124 The 5-tuple consists of: 126 SADDR : IP address of the sender 127 SPORT : Port for sender 128 DADDR : IP address of the destination 129 DPORT : Port for destination 130 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 132 The PDM contains the following base fields: 134 PSNTP : Packet Sequence Number This Packet 135 PSNLR : Packet Sequence Number Last Received 136 DELTATLR : Delta Time Last Received 137 DELTATLS : Delta Time Last Sent" 139 This information, combined with the 5-tuple, allows the measurement 140 of round-trip delay (wire time) and server delay (host time). 142 1.3 Definitions of Round-Trip Delay and Server Delay 144 The PDM description defines the measurement fields of interest. 146 From PDM [PDM]: 148 "Round-trip *Network* delay is the delay for packet transfer from a 149 source host to a destination host and then back to the source host. 150 This measurement has been defined, and the advantages and 151 disadvantages discussed in "A Round-trip Delay Metric for IPPM" 152 [RFC2681]." 154 "Server delay is the interval between when a packet is received by a 155 device and the first corresponding packet is sent back in response. 156 This may be "Server Processing Time". It may also be a delay caused 157 by acknowledgements. Server processing time includes the time taken 158 by the combination of the stack and application to return the 159 response. The stack delay may be related to network performance. If 160 this aggregate time is seen as a problem, and there is a need to make 161 a clear distinction between application processing time and stack 162 delay, including that caused by the network, then more client based 163 measurements are needed." 165 1.4 How Will PDM Be Used to Measure Net Neutrality? 167 Since PDM is embedded in the packet, any measuring tool that is able 168 to capture packets may serve as a capture point. Such devices range 169 from a simple Wireshark packet capture to a large network of agents 170 and controllers using the LMAP [RFC7594] protocol. 172 2 Advantages of PDM 174 2.1 Advantages of PDM for Measurement 176 From [PDM] 178 "Advantages include: 180 1. Real measure of actual transactions. 182 2. Independence from transport layer protocols. 184 3. Ability to span organizational boundaries with consistent 185 instrumentation. 187 4. No time synchronization needed between session partners 189 5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) in 190 a uniform way " 192 2.2 Advantage of PDM for Scaleability 194 The advantage of PDM in scaleability for measuring net neutrality is 195 that no additional client software needs to be implemented. The task 196 of having some agent at each client that one wishes to measure 197 throughout the world is nothing less than daunting. Having said 198 that, some organizations, for example, with the RIPE probes, have 199 undertaken this task with quite a bit of success. 201 Imagine how much simpler this might be if nothing needed to be 202 installed at the client -- if the actual data needed for accurate 203 measurement was in the packet itself. This is what PDM provides. 205 2.3 Isolating Wire Time Accurately 207 From [NNRequire], one of the requirements of net neutrality is to 208 isolate the wire time from other factors: 210 "When measurement tasks are run by an end-user, end-user environment 211 specific factors like cross-traffic, measurement interface 212 (fixed/wireless), firewalls, client operating system and hardware 213 can influence the measurement result. These factors have to be 214 detected and taken into account when assessing measurements 215 performed by end-users." 217 PDM is implemented as close to the network interface as possible so 218 the isolation of wire time is expected to be quite accurate. 220 2.4 Measurement of the Application 222 PDM is embedded in each packet. Each packet inherently has a 5- 223 tuple. So, as the packet is captured and analyzed via analysis 224 tools, data on application usage is available. 226 2.5 Calculation of speed 228 One of the requirements from [NNRequire] states that "speed should be 229 calculated based on IP packet payload". Since PDM is embedded in the 230 packet, and packets are being captured by the measurement device, the 231 length of the IP and upper layer headers are readily differentiated 232 from the size of the actual payload. 234 2.6 Lightweight measurement technique 236 Another of the requirements of [NNRequire] states that "measurement 237 does not block the internet access usage for whole day and does not 238 generate excessive network load." 240 PDM is embedded in the packet and so clearly does not block usage of 241 the Internet for the end-user for any task required. 243 As far as load, from [PDM], Appendix C: Potential Overhead 244 Considerations, discusses the additional overhead created by adding 245 PDM to a packet. 247 "Below is a table outlining the potential overhead in terms of 248 additional time to deliver the response to the end user for various 249 assumed RTTs. 251 Bytes RTT Bytes Bytes New Overhead 252 in Packet Per Millisec in PDM RTT 253 ===================================================================== 254 1000 1000 milli 1 16 1016.000 16.000 milli 255 1000 100 milli 10 16 101.600 1.600 milli 256 1000 10 milli 100 16 10.160 .160 milli 257 1000 1 milli 1000 16 1.016 .016 milli 259 Below are some examples of actual RTTs for packets traversing large 260 enterprise networks. 262 Bytes RTT Bytes Bytes New Overhead 263 in Packet Per Millisec in PDM RTT 264 ===================================================================== 265 1000 17 milli 58 16 17.360 .360 milli 267 2.7 Universal Measurement Technique 269 [NNRequire] would like technique which is universal. That is: 271 "In principle, any solution should be equally applicable to both 272 fixed and mobile Internet access services from narrow band to multi- 273 gigabit connections." 275 PDM is embedded in the IP packet. The operating system merely needs 276 to implement it. PDM has no favorites: fixed or mobile are as one to 277 it. 279 3 Gap Analysis of PDM in Net Neutrality Measurements 281 3.1 PDM for IPv4 283 Much as we might want the world to use IPv6 exclusively, the thorny 284 issue of a world wide base of IPv4 on the Internet which refuses to 285 die quietly remains. Today, PDM is able to measure IPv6 only. PDM 286 needs to be extended to measure IPv4. 288 3.2 PDM for Low Powered Devices 290 The world is becoming filled with small, somewhat intelligent devices 291 which communicate across networks. Should net neutrality be 292 extended to such devices, then PDM will need to be defined for low 293 powered devices. Having said that, the overhead created by PDM, 294 though inconsequential for laptops and cell phones, may be too much 295 for very small devices. 297 4 IANA Considerations 299 There are no IANA considerations. 301 5 Security Considerations 303 Security considerations for PDM are detailed in the PDM [PDM] 304 description. 306 6 References 308 6.1 Normative References 310 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 311 Delay Metric for IPPM", RFC 2681, September 1999. 313 [RFC7594] Eardley, P., "A Framework for Large-Scale Measurement of 314 Broadband Performance (LMAP)", RFC 7594, October, 2015. 316 6.2 Informative References 318 [PDM] Elkins, N. "IPv6 Performance and Diagnostic Metrics (PDM) 319 Destination Option", draft-ietf-ippm-6man-pdm-option-09, March, 2017 320 [Work in Progress] 322 [NNRequire] Nieminen, K., "Net Neutrality Measurements: Regulatory 323 Use Case and Problem Statement", draft-nieminen-ippm-nn-measurements- 324 00, February, 2017 [Work in Progress] 326 Acknowledgments 328 Authors' Addresses 330 Nalini Elkins 331 Inside Products, Inc. 332 36A Upper Circle 333 Carmel Valley, CA 93924 334 United States 335 Phone: +1 831 659 8360 336 Email: nalini.elkins@insidethestack.com 337 http://www.insidethestack.com 339 William Jouris 340 Inside Products, Inc. 341 36A Upper Circle 342 Carmel Valley, CA 93924 343 United States 344 Phone: +1 831 659 8360 345 Email: bill.jouris@insidethestack.com 346 http://www.insidethestack.com