idnits 2.17.1 draft-johansson-quic-ecn-02.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 (April 4, 2017) is 2576 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Bagnulo' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'ECN-fallback' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC6789' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC7560' is defined on line 512, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-02 == Outdated reference: A later version (-08) exists of draft-ietf-tsvwg-ecn-experimentation-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Johansson 3 Internet-Draft Ericsson AB 4 Intended status: Informational April 4, 2017 5 Expires: October 6, 2017 7 ECN support in QUIC 8 draft-johansson-quic-ecn-02 10 Abstract 12 This memo outlines the ECN (Explicit Congestion Notification) support 13 in QUIC. The draft specifies the ECN negotiation and the ECN echo 14 and in addition, different aspects of fallback in case of ECN failure 15 as well as OS specific issues with ECN and monitoring for ECN 16 capability. The intention is that most of the material ends up 17 updating other new or existing QUIC protocol specifications, thus it 18 may be possible that this draft does not warrant a working group 19 status. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 October 6, 2017. 44 Copyright Notice 46 Copyright (c) 2017 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 (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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Elements of ECN support . . . . . . . . . . . . . . . . . . . 3 63 2.1. ECN negotiation . . . . . . . . . . . . . . . . . . . . . 3 64 2.1.1. Challenge/Response . . . . . . . . . . . . . . . . . 4 65 2.1.2. Determine degree of ECN support . . . . . . . . . . . 5 66 2.2. ECN bits in the IP header, semantics . . . . . . . . . . 5 67 2.3. ECN echo . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.4. Fallback in case of ECN fault . . . . . . . . . . . . . . 8 69 2.5. OS socket specifics, access to the ECN bits . . . . . . . 8 70 2.6. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 9 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 4. Open questions . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 7.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 ECN support in transport protocols is a fundamental feature that 83 should be included in the QUIC specification as a mandatory element. 84 ECN has the key benefit that it allows for non-destructive congestion 85 notification by network node, i.e packets are marked instead 86 discarded. This is particularly beneficial for realtime applications 87 with requirements on latency, ECN also has the benefit that it 88 provides with a congestion signal that is unambiguous. The benefits 89 with ECN is described in more detail in [I-D.ietf-aqm-ecn-benefits]. 90 The ECN support should be implemented to support both present and 91 future ECN, the latter is outlined in 92 [I-D.ietf-tsvwg-ecn-experimentation], of particular interest is the 93 ability to discriminate between classic ECN and L4S ECN by means of 94 differentiation between the use of the ECT(0) and ECT(1) code points. 95 This draft does however not delve into the details of the congestion 96 control implementation. 98 2. Elements of ECN support 100 This draft covers the following aspects of ECN support: 102 o ECN negotiation 104 o ECN echo 106 o ECN bits in the IP header, semantics 108 o Fallback in case of ECN fault 110 o OS socket specifics, access to the ECN bits 112 o Monitoring 114 2.1. ECN negotiation 116 ECN support in QUIC needs to be negotiated. The reasons is that 117 network elements may not support ECN and may either clear the ECN 118 bits or simply discard packets that have the ECN bits set. In 119 addition, a QUIC implementation may not have access to the ECN bits 120 in the IP header due to OS dependent restrictions, investigations 121 (Piers O'Hanlon) have indicated that this is in certain cases an 122 asymmetric property, for instance while it is possible to set the ECN 123 bits it is not possible to read them. 125 It is also required that the ECN negotiation does not interfere with 126 the connection setup, in other words a failed ECN negotiation should 127 not cause an extra roundtrip for the connection setup. 129 The suggested method in this draft is to send an ECN negotiation 130 frame when connection setup is completed. Both peers MUST transmit 131 the ECN negotiation frame. The ECN negotiation frame is shown below. 133 0 1 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Type |C|R|W|U U U|E E| 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Figure 1: ECN negotation frame 141 The 2nd byte contains the flags: 143 o C: Challenge bit, indicates that the transmitted ECN negotiation 144 frame is a challenge, if bit is not set then it is a response. 146 o R: Possible to read ECN bits in IP header 148 o W: Possible to write ECN bits in IP header 150 o EE : Echo of ECN bits 152 o U: Unused 154 The ECN negotiation has two steps. 156 o Challenge/response 158 o Determine degree of ECN support 160 2.1.1. Challenge/Response 162 A peer transmits the ECN negotiation frame with the R,W and EE bits 163 in the 2nd byte set to '0' and the C bit set to '1'. This frame is 164 echoed back with the flags set according to the degree of ECN support 165 and with the ECN bits in the IP header of the received ECN 166 negotiation frame copied to the EE field, the C bit is '0'. As both 167 peers MUST transmit an ECN negotiation frame there will be a total of 168 4 ECN negotiation frames transmitted, two challenges and two 169 responses. 171 An ECN negotiation frame should be transmitted in a unique packet, 172 this to avoid that possible loss of ECN negotiation packets cause 173 loss of other frames than the ECN negotiation frame. 175 The IP header for the ECN negotiation frame should set the ECN bits 176 to CE '11'. When the corresponding response is received then an EE 177 pattern of '11' indicates that ECN is likely supported in the 178 network. This does not give a full guarantee that ECN is supported 179 in the network. Monitoring of the ECN field in the ACK-frame serves 180 to give further indication of ECN support once ECN is turned on. 182 An ECN negotiation is declared successful when an ECN negotiation 183 response is received that indicates ECN support. A peer is not 184 allowed to set ECT on outgoing data packets until a successful ECN 185 negotiation is done. In other words it is only the ECN negotiation 186 frame that is allowed to set the ECN bits in the IP header until ECN 187 negotiation is concluded and successful. 189 A lack of an ECN negotiation response may indicate that the ECN 190 challenge frame or the ECN response frame was lost or that a node in 191 the network deliberately discards ECN-CE marked packets. The peer 192 should transmit an additional ECN challenge within an RTO interval in 193 case a negotiation response is not received, a maximum of 194 retransmissions are attempted. 196 A failed challenge/response phase indicates that ECN should not be 197 used in the connection. [NOTE, a special case is where one peer does 198 not receive an ECN negotiation response but still receives ECT and CE 199 marked packets from the other peer. It is T.B.D how this should be 200 handled] 202 2.1.2. Determine degree of ECN support 204 If the ECN challenge/response is successful, the degree of ECN 205 capability depends on how the R, W and EE bits are set. 207 o R='1' and EE= '11': It is possible to set the ECN bits in outgoing 208 packets. 210 o R='0' or EE <> '11': ECN support is not certain as it is either 211 not possible for remote peer to read the ECN bits or that the ECN 212 bits are altered. 214 o W='1' : It is meaningful to send ECN feedback 216 o W='0' : It is not meaningful to send ECN feedback as the remote 217 peer cannot set (write) the ECN bits in the IP header. 219 The mode mechanism in [RFC6679] can serve as in input to a solution 220 for the support of ECN in the case that OS ECN support is asymmetric. 221 It is however unclear how a QUIC implementation can determine 222 asymmetric ECN support in the underlying OS. For instance the method 223 to send ECN marked packets to the local host to determine OS support 224 does not reveal if the OS ECN support is asymmetric. 226 2.2. ECN bits in the IP header, semantics 228 The ECN bits in the IP header should be set according to the 229 recommendations in [I-D.ietf-tsvwg-ecn-experimentation]. This means 230 that the meaning of ECT(0) and ECT(1) differ. 232 2.3. ECN echo 234 The ECN echo should go into the ACK frame [I-D.ietf-quic-transport], 235 this is beneficial as the ECN information can then use some of the 236 already existing data in the ACK frame for improved efficiency, this 237 applies especially to alternatives 1 and 2 below. It is suggested 238 that the 'U' bit in the ACK frame type is renamed 'E' to indicate the 239 presence of an ECN field in the ACK frame, this makes it possible to 240 omit the ECN information for the cases where ECN is not supported for 241 the connection. 243 There are two alternatives how to add ECN support to the ACK frames. 245 The first alternative encodes the number of bytes that are marked 246 ECT(0), ECT(1) and CE with 32 bits each, the total extra overhead is 247 thus 12 octets. 249 0 1 2 3 250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | First Ack Block Length (8/16/32/48) ... 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | [Gap 1 (8)] | [Ack Block 1 Length (8/16/32/48)] ... 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | [Gap 2 (8)] | [Ack Block 2 Length (8/16/32/48)] ... 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ... 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | [Gap N (8)] | [Ack Block N Length (8/16/32/48)] ... 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | # ECT(0) bytes (32) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | # ECT(1) bytes (32) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | # ECN-CE bytes (32) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 2: ECN field in ACK frame ACK block, alt 1 271 The second alternative use an extra byte to encode how many bits that 272 encode each of the ECT/CE fields. 274 0 1 2 3 275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | First Ack Block Length (8/16/32/48) ... 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | [Gap 1 (8)] | [Ack Block 1 Length (8/16/32/48)] ... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | [Gap 2 (8)] | [Ack Block 2 Length (8/16/32/48)] ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 ... 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | [Gap N (8)] | [Ack Block N Length (8/16/32/48)] ... 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |R|R|E1 |E2 |CE | # ECT(0) bytes (0/16/32/48) ... 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | # ECT(1) bytes (0/16/32/48) ... 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | # ECN-CE bytes (0/16/32/48) ... 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 3: ECN field in ACK frame ACK block, alt 2 296 The E1,E2 and CE fields indicate the length of each encoding for the 297 number of ECT(0), ECT(1) and ECN-CE marked bytes. This is encoded 298 as: 300 o 00: 0 bits 302 o 01: 16 bits 304 o 10: 32 bits 306 o 11: 48bits 308 R indicates reserved bits. 310 There are pros an cons with the four alternatives: 312 o Alt 1: Has a fixed 12 octet overhead which may be beneficial as it 313 gives a deterministic overhead. The possible drawback is that it 314 is not possible to know exactly which frames have been remarked, 315 something that can limit the ability to detect network ECN faults 316 based on the method to transmit a pattern on ECT and CE marked 317 packets. 319 o Alt 2: Is a variation to Alt 1 but has a variable length encoding 320 that should consume less space, especially in the cases that one 321 of the ECT code points is not used and for the case that packets 322 are only sporadically ECN-CE marked. This alternative also makes 323 it unnecessary to use a bit in the ACK frame type to indicate the 324 presence of an ECN field as this can be indicated in a efficient 325 way with the one byte header in this format. E0=E1=CE = 00 326 indicates that the following ECT and CE fields are encoded with 327 zero bits. 329 Which of the three formats above (or something else) that is the best 330 alternative is subject to discussion. 332 2.4. Fallback in case of ECN fault 334 ECN can be subject to issues in network equipment, such as remarking 335 to Not-ECN, remarking from ECT(0) to ECT(1) and vice versa or 336 constant remarking to ECN-CE. Furthermore ECT marked packets may be 337 discarded in the network. While these problems seem to be rare, see 338 for instance [McQuistin-Perkins]and [APPLE-ECN], it is still 339 necessary to safeguard against such problems. 341 A peer should disable ECN for its outgoing packets if ECN fault is 342 detected, it is however still possible for the other peer to use ECN. 344 TODO add more information as regards to how to detect network ECN 345 faults. [ECN-fallback](expired) gives a few examples for fault 346 detection. Examples on how to detect ECN faults include for instance 347 the method to set ECT and CE for outgoing packets according to a 348 given pattern. 350 Fallback in case of ECN faults is not an issue only for QUIC, it is 351 here suggested that mechanisms for this is described in a non QUIC 352 related draft, for instance in TSVWG. 354 2.5. OS socket specifics, access to the ECN bits 356 ECN support in QUIC comes with the additional challenge that it is 357 necessary to somehow access the ECN bits in the IP headers. In TCP 358 this is provided without major concerns as TCP is generally 359 implemented in OS kernel space. QUIC can however be implemented both 360 in user space or kernel space and is layered on top of UDP, which 361 means that access to the ECN bits is not a given, instead various 362 tricks are needed. 364 The text below is copy-pasted from [OHanlon]. 366 "To set ECN on Linux, BSD and OSX one can use IP_TOS socket option, 367 with the setsockopt() call, to set the relevant ECN bits of the TOS 368 byte. On Windows one can use a similar technique though firstly one 369 has to enable TOS byte setting by enabling a particular Registry key 370 ( DisableUserTOSSetting=0 (see https://msdn.microsoft.com/en- 371 us/library/windows/desktop/dd874008%28v=vs.85%29.aspx One could also 372 probably use the libpcap write functionality." 374 "To obtain the ECN bits from a packet one needs a mechanism to 375 retrieve the ECN bits from each packet. On Linux, one needs to 376 firstly set the IP_RECVTOS socket option on the receiving socket, and 377 use the recvmsg() call to receive a packet, and then retrieve the TOS 378 byte from the associated csmg structure returned by the recvmsg() 379 call. This still works with linux-4.2.3. On OSX/BSD there are no 380 suitable socket options to retrieve the ECN/TOS bits and one cannot 381 use raw sockets as they do not function for UDP/TCP sockets (they do 382 work with ICMP), so one has to use alternatives such the bpf 383 interface, or a REDIRECT socket. Whilst on Windows it seems that the 384 only way to retrieve the ECN bits is via a raw socket, or custom NDIS 385 driver, though it's possible there's an API I'm missing." 387 TODO: Write a more detailed description on how to implement ECN 388 support in QUIC for different OS stacks. 390 2.6. Monitoring 392 A QUIC implementation should monitor the ECN functionality in order 393 to provide input to e.g. service providers to improve ECN support in 394 the networks. Items of interest are: 396 o Black holes, ECT or CE marked packets are discarded. 398 o Faulty remarking, e.g. ECT(0) is remarked to ECT(1) or Not-ECT. 400 o Continuous CE marking, possible indication of faulty on/off ECN 401 marking, but can also be an effect of severe congestion. 403 o Degree of L4S support. L4S should generally give low queue 404 latency. Estimation of one way queue delay for L4S enabled QUIC 405 connections can be used to determine if there are congested nodes 406 along the path that are not L4S capable. 408 3. IANA Considerations 410 T.B.D. 412 4. Open questions 414 A list of open questions: 416 o Is it sufficient that one peer sends an ECN negotiation challenge 417 frame?. 419 o Should all packets be ECT or should there be special patterns to 420 improve fault detection. 422 o Write up a more detailed description on how to implement ECN 423 support in QUIC for different OS stacks. 425 o Determine which ECN echo encoding in the ACK frame is the best 426 alternative. 428 o Is a completely new ACK frame an alternative ? 430 o Should amount on ECT(0), ECT(1) and CE marked bytes account for 431 the IP+UDP headers or is it only the QUIC header + data that 432 counts ? 434 o Outline possible connection migration actions 436 o Are there any security implications with the small ECN negotiation 437 frame ? 439 5. Security Considerations 441 T.B.D 443 6. Acknowledgements 445 The following persons have contributed with comments and suggestions 446 for improvements: Mirja Kuehlewind, Koen De Schepper, Piers O'Hanlon, 447 Michael Welzl, Marcelo Bagnulo Braun, Martin Duke 449 7. References 451 7.1. Normative References 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 7.2. Informative References 460 [APPLE-ECN] 461 Apple Inc., "TCP ECN: Experience with Enabling ECN on the 462 Internet", . 466 [Bagnulo] "Adding Explicit Congestion Notification (ECN) to TCP 467 control packets and TCP retransmissions", 468 . 471 [ECN-fallback] 472 "A Mechanism for ECN Path Probing and Fallback", 473 . 476 [I-D.ietf-aqm-ecn-benefits] 477 Fairhurst, G. and M. Welzl, "The Benefits of using 478 Explicit Congestion Notification (ECN)", draft-ietf-aqm- 479 ecn-benefits-08 (work in progress), November 2015. 481 [I-D.ietf-quic-transport] 482 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 483 and Secure Transport", draft-ietf-quic-transport-02 (work 484 in progress), March 2017. 486 [I-D.ietf-tsvwg-ecn-experimentation] 487 Black, D., "Explicit Congestion Notification (ECN) 488 Experimentation", draft-ietf-tsvwg-ecn-experimentation-01 489 (work in progress), March 2017. 491 [McQuistin-Perkins] 492 ""Is Explicit Congestion Notification usable with UDP?", 493 Proceedings of the ACM Internet Measurement Conference, 494 Tokyo, Japan, October 2015. DOI:10.1145/2815675.2815716", 495 . 498 [OHanlon] "ECN support in different OS stacks", 499 . 502 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 503 and K. Carlberg, "Explicit Congestion Notification (ECN) 504 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 505 2012, . 507 [RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., 508 "Congestion Exposure (ConEx) Concepts and Use Cases", 509 RFC 6789, DOI 10.17487/RFC6789, December 2012, 510 . 512 [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, 513 "Problem Statement and Requirements for Increased Accuracy 514 in Explicit Congestion Notification (ECN) Feedback", 515 RFC 7560, DOI 10.17487/RFC7560, August 2015, 516 . 518 Author's Address 520 Ingemar Johansson 521 Ericsson AB 522 Laboratoriegraend 11 523 Luleaa 977 53 524 Sweden 526 Phone: +46 730783289 527 Email: ingemar.s.johansson@ericsson.com