idnits 2.17.1 draft-kuhn-quic-4-sat-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2020) is 1512 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6534' is defined on line 556, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-26 == Outdated reference: A later version (-03) exists of draft-roca-nwcrg-rlc-fec-scheme-for-quic-02 == Outdated reference: A later version (-04) exists of draft-swett-nwcrg-coding-for-quic-03 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Kuhn 3 Internet-Draft CNES 4 Intended status: Informational G. Fairhurst 5 Expires: September 7, 2020 University of Aberdeen 6 J. Border 7 Hughes Network Systems, LLC 8 E. Stephan 9 Orange 10 March 6, 2020 12 QUIC for SATCOM 13 draft-kuhn-quic-4-sat-04 15 Abstract 17 QUIC has been designed for use across Internet paths. Initial 18 designs of QUIC have focussed on common deployment scenarios for web 19 traffic and have not focussed on the performance when using a path 20 with a large Bandwidth-Delay Product (BDP). A path can combine 21 satellites network segment together with a wide variety of other 22 network technologies (Ethernet, cable modems, WiFi, cellular, radio 23 links, etc): this complicates the characteristics of the end-to-end 24 path. One example of such a scenario occurs when a satellite 25 communication (SATCOM) system is used to provide all or a part of the 26 end-to-end path. If this is not addressed, the end-to-end quality of 27 experience can be degraded. 29 This memo identifies the characteristics of a SATCOM link that impact 30 the operation of the QUIC transport protocol. It proposes regression 31 tests to evaluate QUIC over SATCOM links. It discusses how to ensure 32 acceptable protocol performance. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 7, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Operating over a path with a large BDP . . . . . . . . . . . 3 69 3. TCP Split Solution . . . . . . . . . . . . . . . . . . . . . 5 70 4. Regression tests . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Small public satellite broadband access . . . . . . . . . 6 72 4.2. Medium public satellite broadband access . . . . . . . . 6 73 4.3. Loss-free large public satellite broadband access . . . . 7 74 4.4. Lossy large public satellite broadband access . . . . . . 8 75 5. Mechanisms that improve the performance of QUIC for SATCOM . 8 76 5.1. Getting up to speed . . . . . . . . . . . . . . . . . . . 8 77 5.2. Maximum window . . . . . . . . . . . . . . . . . . . . . 9 78 5.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.4. ACK ratio . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 9. Informative References . . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 The end-to-end performance of an application using an Internet path 89 can be impacted by the Bandwidth-Delay Product (BDP) of the links and 90 network devices forming the path. For instance, the page load time 91 for a complex page can be much larger when the path includes a 92 satellite link. A significant contribution to this reduced 93 performance arises from the initialisation and design of transport 94 mechanisms. QUIC's default congestion control is based on TCP 95 NewReno [I-D.ietf-quic-recovery] and the recommended initial window 96 is defined by [RFC6928]. Although QUIC's CC and recovery have been 97 designed for use across Internet Paths, the initial design could not 98 optimise for the wide diversity of path characteristics that can 99 occur. This document therefore considers the specific implications 100 of paths with a significant BDP. 102 Satellite communications (SATCOM) systems have long been used to 103 support point-to-point links and specialised networks. The 104 predominate current use is as a link-layer for Internet Protocols. 105 Typical example applications include: use as an access technology for 106 remote locations, backup and rapid deployment of new services, 107 transit networks and backhaul of various types of IP networks, and 108 provision to mobile (maritime, aircraft, etc.). In most scenarios, 109 the satellite IP network segment usually only forms one part of the 110 end-to-end path. This means user traffic can experience a path that 111 includes satellite link together with a wide variety of other network 112 technologies (Ethernet, cable modems, WiFi, cellular, radio links, 113 etc). Although a user can sometimes know the presence of the 114 satellite service, a typical user does not deploy special software or 115 applications because they expect a satellite network is being used. 116 Often a user is unaware of the technologies underpinning the links 117 forming the network path. 119 This memo identifies the characteristics of a SATCOM link that impact 120 the operation of the QUIC transport protocol. It proposes regression 121 tests to evaluate QUIC over SATCOM links. It discusses how to ensure 122 acceptable protocol performance. 124 2. Operating over a path with a large BDP 126 Satellite communications systems have been deployed using many space 127 orbits, including low earth orbit, medium earth orbits, 128 geosynchronous orbits, elliptical orbits and more. This document 129 focuses on Geosynchronous Earth Orbit (GEO) satellite systems. 131 The characteristics of systems using Geosynchronous Earth Orbit (GEO) 132 satellites differ from paths only using terrestrial links in their 133 path characteristics: 135 o A large propagation delay of at least 250ms one-way delay; 137 o Employ radio resource management (often using techniques similar 138 to cellular mobile or DOCSIS cable networks, but differing to 139 accommodate the satellite propagation delay); 141 o Links can be highly asymmetric (in terms of capacity, one-way 142 delay and in their cost of operation). 144 Many systems use the DVB-S2 specifications, published by the European 145 Telecomunications Standards Institute (ETSI), where the key concept 146 is to ensure both a good usage of the satellite resource and a Quasi 147 Error Free (QEF) link. It consists of monitoring the link quality in 148 real-time, with the help of known symbol sequences, included along 149 with regular packets, on which an estimation of the current signal- 150 to-noise ratio can be done. Then, this estimation is sent back to 151 the transmitter that can adapt its coding rate and modulation in 152 order to best fit the actual transmission conditions. 154 It is common to consider the satellite network segment composed of a 155 forward link and a return link. The two links can have different 156 capacities and employ different technologies to carry the IP packets. 157 On the forward link, the satellite gateway uses all the available 158 bandwidth, possibly with several carriers, to communicate with the 159 remote terminals. A carrier is a single Time-Division-Multiplexing 160 channel where packets addressed to terminals are multiplexed. On the 161 return link, the satellite resource is shared among the users. Two 162 access methods can be distinguished: on-demand access or contention 163 access. In the former, a terminal receives dedicated resources on 164 its own to communicate with the gateway. In the latter, some 165 resources are reserved for contention access, where several terminals 166 can compete to obtain the resource. Dedicated access, which is more 167 common in currently deployed systems, can be through a Demand 168 Assigned Multiple Access (DAMA) mechanism, while contention access 169 techniques are usually based on Slotted Aloha (SA) and its numerous 170 derivatives. More information on satellite links characteristics can 171 be found in [RFC2488][IJSCN17]. 173 Beyond that, even for characteristics shared with terrestrial links, 174 the impact on a satellite link could be more and can be amplified by 175 the large RTT. For example, systems can exhibit a high loss-rate 176 (e.g. mobile users or users behind a Wi-Fi link) which would impact 177 loss recovery mechanisms and congestion control reaction to such loss 178 events. The characteristics of a GEO SATCOM system impact the 179 performance of congestion control: 181 o Transport initialization: the 3-way handshake takes a long time to 182 complete, delaying the time at which actual data can be 183 transmitted (there could be other transport protocol exchanges, 184 such as TLS); 186 o Size of windows required: to fully exploit the bottleneck 187 capacity, a high BDP will increase the number of in-flights 188 packets; 190 o Reliability: packet loss detection and correction is slow (the 191 performance of end-to-end retransmission is also impacted when 192 using a high RTT path); 194 o Getting up to speed: the exponential increase of the data rate 195 during slow start for a channel capacity probing is slowed down 196 when the RTT is high; 198 o Asymmetry : when the links are asymmetric, for various reasons, 199 the sizing of the return link may induce modifications of the 200 transport level acknowledgement traffic. 202 3. TCP Split Solution 204 High BDP networks commonly break the TCP end-to-end paradigm to adapt 205 the transport protocol. Splitting TCP allows adaptations to this 206 specific use-case and assessing the issues discussed in section 207 Section 2. Satellite communications commonly deploy Performance 208 Enhancement Proxy (PEP) for compression, caching and TCP acceleration 209 services [RFC3135]. Their deployment can result in 50% page load 210 time reduction in a SATCOM use-case [ICCRG100]. 212 [NCT13] and [RFC3135] describe the main functions of SATCOM TCP split 213 solutions. Shortly, for traffic originated at a gateway to an 214 endpoint connected via a satellite terminal, the TCP split intercepts 215 TCP SYN packets to act on behalf of the endpoint and adapt the data 216 rate transmission to the SATCOM scenario. The split solution 217 specifically tunes the TCP parameters to the context (latency, 218 available capacity) of each link. When a PEP is used on each side of 219 the satellite link, a protocol other than TCP, optimized for the 220 satellite link, may be used. The tuning can be achieved using a 221 priori information about the satellite system and/or by measuring the 222 properties of the network segment that includes the satellite system. 223 Split connections also allow for recovery from packet losses that is 224 local to the part of the connection on which the packet losses 225 occurred. This eliminates the need for end-to-end recovery of lost 226 packets. 228 One important advantage of a TCP split solution is that it does not 229 require any end-to-end modifications and is independent for both 230 client and server sides. That being said, this comes with a 231 drawback: TCP splitters often are unable to track the most recent 232 end-to-end improvements in protocol mechanisms (e.g., RACK, ECN, TCP 233 Fast Open support) contributing to ossification of the transport 234 system. The methods configured in the split proxy usually continue 235 to be used until a split solution is finally updated. This can 236 delay/negate the benefit of any end-to-end improvements. 238 4. Regression tests 240 This section proposes regression tests for QUIC. We define by: 242 o Download path: from Internet to host 244 o Upload path: from the host to Internet 246 4.1. Small public satellite broadband access 248 The characteristics of the architecture under test are the following: 250 o Satellite downlink path: 10 Mbps 252 o Satellite uplink path: 2 Mbps 254 o No emulated packet loss 256 o RTT: 650 ms 258 o Buffer size : BDP 260 During the transmission of 100 MB on both download and upload paths, 261 the test should report the downloading time of 2 MB, 10 MB and 100 262 MB. 264 Initial thoughts of the performance obectives for QUIC are the 265 following: 267 o 3 s for downloading 2 MB 269 o 10 s for downloading 10 MB 271 o 85 s for downloading 100 MB 273 o 10 s for uploading 2 MB 275 o 50 s for uploading 10 MB 277 o 420 s for uploading 100 MB 279 4.2. Medium public satellite broadband access 281 The characteristics of the architecture under test are the following: 283 o Satellite downlink path: 50 Mbps 285 o Satellite uplink path: 10 Mbps 286 o No emulated packet loss 288 o RTT: 650 ms 290 o Buffer size : BDP 292 During the transmission of 100 MB on the download path, the test 293 should report the downloading time of 2 MB, 10 MB and 100 MB. 295 Initial thoughts of the performance obectives for QUIC are the 296 following: 298 o 3 s for downloading 2 MB 300 o 5 s for downloading 10 MB 302 o 20 s for downloading 100 MB 304 4.3. Loss-free large public satellite broadband access 306 The characteristics of the architecture under test are the following: 308 o Satellite downlink path: 250 Mbps 310 o Satellite uplink path: 3 Mbps 312 o No emulated packet loss 314 o RTT: 650 ms 316 o Buffer size : BDP 318 During the transmission of 100 MB on the download path, the test 319 should report the downloading time of 2 MB, 10 MB and 100 MB. 321 Initial thoughts of the performance obectives for QUIC are the 322 following: 324 o 3 s for downloading 2 MB 326 o 5 s for downloading 10 MB 328 o 8 s for downloading 100 MB 330 4.4. Lossy large public satellite broadband access 332 The characteristics of the architecture under test are the following: 334 o Satellite downlink path: 250 Mbps 336 o Satellite uplink path: 3 Mbps 338 o Emulated packet loss on both downlink and uplink paths: 340 * Uniform random transmission link losses: 1% 342 o RTT: 650 ms 344 o Buffer size : BDP 346 During the transmission of 100 MB on the download path, the test 347 should report the downloading time of 2 MB, 10 MB and 100 MB. 349 Initial thoughts of the performance obectives for QUIC are the 350 following: 352 o 3 s for downloading 2 MB (uniform transmission link losses) 354 o 6 s for downloading 10 MB (uniform transmission link losses) 356 o 10 s for downloading 100 MB (uniform transmission link losses) 358 5. Mechanisms that improve the performance of QUIC for SATCOM 360 5.1. Getting up to speed 362 The advantage of using QUIC is that it includes the TLS and TCP 363 negotiations that reduce the time at which the data can be 364 transmitted. That being said, results of [IJSCN19] illustrate that 365 it will take many RTTs for the congestion controller to increase the 366 rate before it fills the bottleneck capacity. This dominates 367 performance when a path has a large RTT (as in GEO SATCOM networks). 368 There can be an issue in QUIC getting up to speed in a SATCOM context 369 if the congestion and flow controls are not adapted. 371 The tuning of the initial window described in 372 [I-D.irtf-iccrg-sallantin-initial-spreading] which has been shown to 373 improve performance both for high BDP and more common BDP 374 [CONEXT15][ICC16] could be a relevant solution. That being said, 375 such solution requires the usage of pacing to avoid important bursts 376 of packets in a network that does not have a large BDP. 378 5.2. Maximum window 380 A large number of in-flight packets are prewired to fully exploit the 381 bottleneck capacity, when there is a large BDP. Default values of 382 maximum windows may not be suitable for a SATCOM context. 384 Such as presented in [PANRG105], only increasing the initial 385 congestion window is not the only way that can improve QUIC 386 performance in a SATCOM context: increasing maximum congestion 387 windows can also result in much better performance. Other protocol 388 mechanisms also need to be considered, such as flow control at the 389 stream level in QUIC. 391 5.3. Reliability 393 Packet loss detection and loss repair take additional time on paths 394 with a larger RTT. This increases the time that a server needs to 395 react to a congestion event. Both can impact the user experience. 396 This happens when a user uses a Wi-Fi link to access a SATCOM 397 terminal. Although the benefits need to weighed against the 398 additional capacity in introducing end-to-end FEC and the potential 399 to use link-local ARQ and/or link-adaptive FEC. End-to-end 400 connections may suffer from losses not only in the Wi-Fi segment, but 401 also from congestion losses in the satellite operator ground segment 402 (and even on the Internet itself). Using the mechanisms proposed in 403 [I-D.ferrieux-hamchaoui-quic-lossbits], congestion losses have been 404 identified on the ground segment. 406 Introducing network coding in QUIC such as proposed in 407 [I-D.swett-nwcrg-coding-for-quic] and 408 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] could help in recovering 409 from the residual Wi-Fi or congestion losses. Another solution would 410 be the usage of QUIC tunnels [I-D.schinazi-masque]. 412 5.4. ACK ratio 414 Asymmetry in capacity (or in the way capacity is granted to a flow) 415 can lead to cases where the throughput in one direction of 416 communication is restricted by the acknowledgement traffic flowing in 417 the opposite direction. The limitations of specific underlying 418 networks could be in terms of the volume of acknowledgement traffic 419 (limited return path capacity) or in the number of acknowledgement 420 packets (e.g., when a radio-resource management system has to track 421 channel usage) or both. 423 TCP Performance Implications of Network Path Asymmetry [RFC3449] 424 describes a range of mechanisms that can mitigate the impact of path 425 asymmetry. One simple method is to tell the remote endpoint to send 426 compound acknowledgments less frequently. A rate of one ACK every 427 RTT/4 can significantly reduce this traffic. 429 Many of these mitigations have been deployed in satellite systems, 430 often as a mechanism within a PEP. Despite their benefits over paths 431 with a high asymmetry of capacity, most mechanisms rely on being able 432 to inspect and/or modify the transport layer header information of 433 TCP ACK packets. This is not possible when the transport layer 434 information is encrypted. The QUIC transport specification may 435 evolve to allow the ACK Ratio to be adjusted. 437 6. Discussion 439 Many of the issues identified already exist for any encrypted 440 transport service that uses a path that employs encryption at the IP 441 layer. This includes endpoints that utilise IPsec at the network 442 layer, or use VPN technology over the satellite network segment. 443 These uses are unable to benefit from enhancement within the 444 satellite network segment, and often the user is unaware of the 445 presence of the satellite link on their path, except through 446 observing the impact it has on the performance they experience. 448 One solution would be to provide PEP functions at the termination of 449 the security association (e.g., in a VPN client). Another solution 450 could be to fall-back to using TCP (possibly with TLS or similar 451 methods being used on the transport payload). A final solution could 452 be to deploy and maintain a bespoke protocol tailored to high BDP 453 environments. In the future, we anticipate that fall-back will 454 become less desirable, and methods that rely upon bespoke 455 configurations or protocols will be unattractive. In parallel, new 456 methods such as QUIC will become widely deployed. The opportunity 457 therefore exists to ensure that the new generation of protocols offer 458 acceptable performance over high BDP paths without requiring 459 operating tuning or specific updates by users. 461 7. Acknowledgements 463 The authors would like to thank Christian Huitema, Igor Lubashev, 464 Alexandre Ferrieux, Francois Michel, Emmanuel Lochin and the 465 partipants of the IETF106 side-meeting on QUIC for high BDP for their 466 useful feedbacks. 468 8. Security Considerations 470 This document does not propose changes to the security functions 471 provided by the QUIC protocol. QUIC uses TLS encryption to protect 472 the transport header and its payload. Security is considered in the 473 "Security Considerations" of cited IETF documents. 475 9. Informative References 477 [CONEXT15] 478 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 479 Flows Quickly and Safely", ACM CoNEXT , 2015. 481 [I-D.ferrieux-hamchaoui-quic-lossbits] 482 Ferrieux, A. and I. Hamchaoui, "The QUIC Loss Bits", 483 draft-ferrieux-hamchaoui-quic-lossbits-00 (work in 484 progress), April 2019. 486 [I-D.ietf-quic-recovery] 487 Iyengar, J. and I. Swett, "QUIC Loss Detection and 488 Congestion Control", draft-ietf-quic-recovery-26 (work in 489 progress), February 2020. 491 [I-D.irtf-iccrg-sallantin-initial-spreading] 492 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 493 E., and A. Beylot, "Safe increase of the TCP's Initial 494 Window Using Initial Spreading", draft-irtf-iccrg- 495 sallantin-initial-spreading-00 (work in progress), January 496 2014. 498 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] 499 Roca, V., Michel, F., Swett, I., and M. Montpetit, 500 "Sliding Window Random Linear Code (RLC) Forward Erasure 501 Correction (FEC) Schemes for QUIC", draft-roca-nwcrg-rlc- 502 fec-scheme-for-quic-02 (work in progress), November 2019. 504 [I-D.schinazi-masque] 505 Schinazi, D., "The MASQUE Protocol", draft-schinazi- 506 masque-02 (work in progress), January 2020. 508 [I-D.swett-nwcrg-coding-for-quic] 509 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 510 for QUIC", draft-swett-nwcrg-coding-for-quic-03 (work in 511 progress), July 2019. 513 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 514 E., and A-L. Beylot, "Reducing web latency through TCP IW: 515 Be smart", IEEE ICC , 2016. 517 [ICCRG100] 518 Kuhn, N., "MPTCP and BBR performance over Internet 519 satellite paths", IETF ICCRG 100, 2017. 521 [IJSCN17] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 522 and N. Kuhn, "Software-defined satellite cloud RAN", 523 International Journal of Satellite Communications and 524 Networking , 2017. 526 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 527 QUIC performance over a public SATCOM access", 528 International Journal of Satellite Communications and 529 Networking , 2019. 531 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 532 performances over geostationary satellite link", Network 533 and Communication Technologies , 2013. 535 [PANRG105] 536 Kuhn, N., Stephan, E., Border, J., and G. Fairhurst, "QUIC 537 Over In-sequence Paths with Different Characteristics", 538 IRTF PANRG 105, 2019. 540 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 541 Over Satellite Channels using Standard Mechanisms", 542 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 543 . 545 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 546 Shelby, "Performance Enhancing Proxies Intended to 547 Mitigate Link-Related Degradations", RFC 3135, 548 DOI 10.17487/RFC3135, June 2001, 549 . 551 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 552 Sooriyabandara, "TCP Performance Implications of Network 553 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 554 December 2002, . 556 [RFC6534] Duffield, N., Morton, A., and J. Sommers, "Loss Episode 557 Metrics for IP Performance Metrics (IPPM)", RFC 6534, 558 DOI 10.17487/RFC6534, May 2012, 559 . 561 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 562 "Increasing TCP's Initial Window", RFC 6928, 563 DOI 10.17487/RFC6928, April 2013, 564 . 566 Authors' Addresses 568 Nicolas Kuhn 569 CNES 571 Email: nicolas.kuhn@cnes.fr 573 Godred Fairhurst 574 University of Aberdeen 576 Email: gorry@erg.abdn.ac.uk 578 John Border 579 Hughes Network Systems, LLC 581 Email: border@hns.com 583 Emile Stephan 584 Orange 586 Email: emile.stephan@orange.com