idnits 2.17.1 draft-ietf-tcpm-alternativebackoff-ecn-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 4, 2017) is 2547 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-tsvwg-ecn-experimentation-02 == Outdated reference: A later version (-10) exists of draft-ietf-aqm-codel-07 == Outdated reference: A later version (-07) exists of draft-ietf-tcpm-cubic-04 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-01 == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-dctcp-02 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 N. Khademi 3 Internet-Draft M. Welzl 4 Intended status: Experimental University of Oslo 5 Expires: November 5, 2017 G. Armitage 6 Swinburne University of Technology 7 G. Fairhurst 8 University of Aberdeen 9 May 4, 2017 11 TCP Alternative Backoff with ECN (ABE) 12 draft-ietf-tcpm-alternativebackoff-ecn-01 14 Abstract 16 Recent Active Queue Management (AQM) mechanisms instantiate shallow 17 buffers with burst tolerance to minimise the time that packets spend 18 enqueued at a bottleneck. However, shallow buffering can cause 19 noticeable performance degradation when TCP is used over a network 20 path with a large bandwidth-delay-product. Traditional methods rely 21 on detecting network congestion through reported loss of transport 22 packets. Explicit Congestion Notification (ECN) instead allows a 23 router to directly signal incipient congestion. A sending endpoint 24 can distinguish when congestion is signalled via ECN, rather than by 25 packet loss. An ECN signal indicates that an AQM mechanism has done 26 its job, and therefore the bottleneck network queue is likely to be 27 shallow. This document therefore proposes an update to the TCP 28 sender-side ECN reaction in congestion avoidance to reduce the 29 FlightSize by a smaller amount than the congestion control 30 algorithm's reaction to loss. Future versions of this document will 31 also describe a corresponding method for the Stream Control 32 Transmission Protocol (SCTP). 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 http://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 November 5, 2017. 50 Copyright Notice 52 Copyright (c) 2017 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 (http://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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Why Use ECN to Vary the Degree of Backoff? . . . . . . . 4 72 4.2. Focus on ECN as Defined in RFC3168 . . . . . . . . . . . 5 73 4.3. Discussion: Choice of ABE Multiplier . . . . . . . . . . 5 74 5. Status of the Update . . . . . . . . . . . . . . . . . . . . 6 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 10. Revision Information . . . . . . . . . . . . . . . . . . . . 8 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 11.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Definitions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Introduction 93 Explicit Congestion Notification (ECN) [RFC3168] makes it possible 94 for an Active Queue Management (AQM) mechanism to signal the presence 95 of incipient congestion without incurring packet loss. This lets the 96 network deliver some packets to an application that would have been 97 dropped if the application or transport did not support ECN. This 98 packet loss reduction is the most obvious benefit of ECN, but it is 99 often relatively modest. There are also significant other benefits 100 from deploying ECN [RFC8087], including reduced end-to-end network 101 latency. 103 The rules for ECN were originally written to be very conservative, 104 and required the congestion control algorithms of ECN-capable 105 transport protocols to treat ECN congestion signals exactly the same 106 as they would treat a packet loss [RFC3168]. 108 Research has demonstrated the benefits of reducing network delays due 109 to excessive buffering [BUFFERBLOAT]; this has led to the creation of 110 new AQM mechanisms like PIE [RFC8033] and CoDel [CODEL2012] 111 [I-D.CoDel], which avoid causing the bloated queues that are common 112 with a simple tail-drop behaviour (also known as a First-In First- 113 Out, FIFO, queue). 115 These AQM mechanisms instantiate short queues that are designed to 116 tolerate packet bursts. However, congestion control mechanisms 117 cannot always utilise a bottleneck link well where there are short 118 queues. For example, to allow a single TCP connection to fully 119 utilise a network path, the queue at the bottleneck link must be able 120 to compensate for TCP halving the "FlightSize" and "ssthresh" 121 variables in response to a lost packet [RFC5681]. This requires the 122 bottleneck queue to be able to store at least an end-to-end 123 bandwidth-delay product (BDP) of data, which effectively doubles both 124 the amount of data that can be in flight and the round-trip time 125 (RTT) experience using the network path. 127 Modern AQM mechanisms can use ECN to signal the early signs of 128 impending queue buildup long before a tail-drop queue would be forced 129 to resort to dropping packets. It is therefore appropriate for the 130 transport protocol congestion control algorithm to have a more 131 measured response when an early-warning signal of congestion is 132 received in the form of an ECN CE-marked packet. Recognizing these 133 changes in modern AQM practices, more recent rules have relaxed the 134 strict requirement that ECN signals be treated identically to packet 135 loss [I-D.ECN-exp]. Following these newer, more flexible rules, this 136 document defines a new sender-side-only congestion control response, 137 called "ABE" (Alternative Backoff with ECN). ABE improves the 138 performance when routers use shallow buffered AQM mechanisms. 140 3. Specification 142 This specification describes an update to the congestion control 143 algorithm of an ECN-capable TCP transport protocol. It allows a TCP 144 stack to update the TCP sender response when it receives feedback 145 indicating reception of a CE-marked packet. It RECOMMENDS that a TCP 146 sender multiplies the FlightSize by 0.8 and reduces the slow start 147 threshold (ssthresh) in congestion avoidance following reception of a 148 TCP segment that sets the ECN-Echo flag (defined in [RFC3168]). 150 4. Discussion 152 Much of the technical background to this congestion control response 153 can be found in a research paper [ABE2017]. This paper used a mix of 154 experiments, theory and simulations with standard NewReno and CUBIC 155 to evaluate the technique. It examined the impact of enabling ECN 156 and letting individual TCP senders back off by a reduced amount in 157 reaction to the receiver that reports ECN CE-marks from AQM-enabled 158 bottlenecks. The technique was shown to present "...significant 159 performance gains in lightly-multiplexed scenarios, without losing 160 the delay-reduction benefits of deploying CoDel or PIE". The 161 performance improvement is achieved when reacting to ECN-Echo in 162 congestion avoidance by multiplying FlightSize and sstthresh with a 163 value in the range [0.7..0.85]. 165 4.1. Why Use ECN to Vary the Degree of Backoff? 167 The classic rule-of-thumb dictates that a network path needs to 168 provide a BDP of bottleneck buffering if a TCP connection wishes to 169 optimise path utilisation. A single TCP bulk transfer running 170 through such a bottleneck will have increased its congestion window 171 (cwnd) up to 2*BDP by the time that packet loss occurs. When packet 172 loss is detected (regarded as a notification of congestion), Standard 173 TCP halves the FlightSize and ssthresh [RFC5681], which causes the 174 TCP congestion control to go back to allowing only a BDP of packets 175 in flight -- just sufficient to maintain 100% utilisation of the 176 bottleneck on the network path. 178 AQM mechanisms such as CoDel [I-D.CoDel] and PIE [RFC8033] set a 179 delay target in routers and use congestion notifications to constrain 180 the queuing delays experienced by packets, rather than in response to 181 impending or actual bottleneck buffer exhaustion. With current 182 default delay targets, CoDel and PIE both effectively emulate a 183 shallow buffered bottleneck (section II, [ABE2017]) while also 184 allowing short traffic bursts into the queue. This provides 185 acceptable performance for TCP connections over a path with a low 186 BDP, or in highly multiplexed scenarios (many concurrent transport 187 connections). However, it interacts badly for a lightly-multiplexed 188 case (few concurrent connections) over a path with a large BDP. 189 Conventional TCP backoff in such cases leads to gaps in packet 190 transmission and under-utilisation of the path. 192 Instead of discarding packets, an AQM mechanism is allowed to mark 193 ECN-capable packets with an ECN CE-mark. The reception of a CE-mark 194 not only indicates congestion on the network path, it also indicates 195 that an AQM mechanism exists at the bottleneck along the path, and 196 hence the CE-mark likely came from a bottleneck with a shallow queue. 197 Reacting differently to an ECN CE-mark than to packet loss can then 198 yield the benefit of a reduced back-off, as with CUBIC [I-D.CUBIC], 199 when queues are short, yet it can avoid generating excessive delay 200 when queues are long. Using ECN can also be advantageous for several 201 other reasons [RFC8087]. 203 The idea of reacting differently to loss and detection of an ECN CE- 204 mark pre-dates this document. For example, previous research 205 proposed using ECN CE-marks to modify TCP congestion control 206 behaviour via a larger multiplicative decrease factor in conjunction 207 with a smaller additive increase factor [ICC2002]. The goal of this 208 former work was to operate across AQM bottlenecks using Random Early 209 Detection (RED) that were not necessarily configured to emulate a 210 shallow queue ([RFC7567] notes the current status of RED as an AQM 211 method.) 213 4.2. Focus on ECN as Defined in RFC3168 215 Some transport protocol mechanisms rely on ECN semantics that differ 216 from the original ECN definition [RFC3168] -- for example, Congestion 217 Exposure (ConEx) [RFC7713] and Datacenter TCP (DCTCP) 218 [I-D.ietf-tcpm-dctcp] need more accurate ECN information than that 219 offered by the original feedback method. Other mechanisms (e.g., 220 [I-D.ietf-tcpm-accurate-ecn]) allow the sender to adjust the rate 221 more frequently than once each path RTT. Use of these mechanisms is 222 out of the scope of the current document. 224 4.3. Discussion: Choice of ABE Multiplier 226 ABE decouples the reaction of a TCP sender to loss and ECN CE-marks 227 when in the congestion avoidance phase. The description respectively 228 uses beta_{loss} and beta_{ecn} to refer to the multiplicative 229 decrease factors applied in response to packet loss, and in response 230 to a receiver indicating that an ECN CE-mark was received on an ECN- 231 enabled TCP connection. For non-ECN-enabled TCP connections, no ECN 232 CE-marks are received and only beta_{loss} applies. 234 In other words, in response to detected loss: 236 FlightSize_(n+1) = FlightSize_n * beta_{loss} 238 and in response to an indication of a received ECN CE-mark: 240 FlightSize_(n+1) = FlightSize_n * beta_{ecn} 242 where FlightSize is the amount of outstanding data in the network, 243 upper-bounded by the sender's cwnd and the receiver's advertised 244 window (rwnd) [RFC5681]. The higher the values of beta_{loss} and 245 beta_{ecn}, the less aggressive the response of any individual 246 backoff event. 248 The appropriate choice for beta_{loss} and beta_{ecn} values is a 249 balancing act between path utilisation and draining the bottleneck 250 queue. More aggressive backoff (smaller beta_*) risks underutilising 251 the path, while less aggressive backoff (larger beta_*) can result in 252 slower draining of the bottleneck queue. 254 The Internet has already been running with at least two different 255 beta_{loss} values for several years: the standard value is 0.5 256 [RFC5681], and the Linux implementation of CUBIC [I-D.CUBIC] has used 257 a multiplier of 0.7 since kernel version 2.6.25 released in 2008. 258 ABE proposes no change to beta_{loss} used by current TCP 259 implementations. 261 beta_{ecn} depends on how the response of a TCP connection to shallow 262 AQM marking thresholds is optimised. beta_{loss} reflects the 263 preferred response of each congestion control algorithm when faced 264 with exhaustion of buffers (of unknown depth) signalled by packet 265 loss. Consequently, for any given TCP congestion control algorithm 266 the choice of beta_{ecn} is likely to be algorithm-specific, rather 267 than a constant multiple of the algorithm's existing beta_{loss}. 269 A range of tests (section IV, [ABE2017]) with NewReno and CUBIC over 270 CoDel and PIE in lightly-multiplexed scenarios have explored this 271 choice of parameter. The results of these tests indicate that CUBIC 272 connections benefit from beta_{ecn} of 0.85 (cf. beta_{loss} = 0.7), 273 and NewReno connections see improvements with beta_{ecn} in the range 274 0.7 to 0.85 (cf. beta_{loss} = 0.5). 276 5. Status of the Update 278 This update is a sender-side only change. Like other changes to 279 congestion-control algorithms, it does not require any change to the 280 TCP receiver or to network devices. It does not require any ABE- 281 specific changes in routers or the use of Accurate ECN feedback 282 [I-D.ietf-tcpm-accurate-ecn] by a receiver. 284 The currently published ECN specification requires that the 285 congestion control response to a CE-marked packet is the same as the 286 response to a dropped packet [RFC3168]. The specification is 287 currently being updated to allow for specifications that do not 288 follow this rule [I-D.ECN-exp]. The present specification defines 289 such an experiment and has thus been assigned an Experimental status 290 before being proposed as a Standards-Track update. 292 The purpose of the Internet experiment is to collect experience with 293 deployment of ABE, and confirm the safety in deployed networks using 294 this update to TCP congestion control. 296 When used with bottlenecks that do not support ECN-marking the 297 specification does not modify the transport protocol. 299 To evaluate the benefit, this experiment therefore requires support 300 in AQM routers (except to enable an ECN-marking mechanism [RFC3168] 301 [RFC7567]) for ECN-marking of packets carrying the ECN Capable 302 Transport, ECT(0), codepoint [RFC3168]. 304 If the method is only deployed by some senders, and not by others, 305 the senders that use this method can gain some advantage, possibly at 306 the expense of other flows that do not use this updated method. 307 Because this advantage applies only to ECN-marked packets and not to 308 loss indications, the new method cannot lead to congestion collapse. 310 The result of this Internet experiment will be reported by 311 presentation to the TCPM WG (or IESG) or an implementation report at 312 the end of the experiment. 314 6. Acknowledgements 316 Authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by 317 the European Community under its Seventh Framework Programme through 318 the Reducing Internet Transport Latency (RITE) project (ICT-317700). 319 The views expressed are solely those of the authors. 321 The authors would like to thank Stuart Cheshire for many suggestions 322 when revising the draft, and the following people for their 323 contributions to [ABE2017]: Chamil Kulatunga, David Ros, Stein 324 Gjessing, Sebastian Zander. Thanks also to (in alphabetical order) 325 Bob Briscoe, Markku Kojo, John Leslie, Dave Taht and the TCPM working 326 group for providing valuable feedback on this document. 328 The authors would finally like to thank everyone who provided 329 feedback on the congestion control behaviour specified in this update 330 received from the IRTF Internet Congestion Control Research Group 331 (ICCRG). 333 7. IANA Considerations 335 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 337 This document includes no request to IANA. 339 8. Implementation Status 341 ABE is implemented as a patch for Linux and FreeBSD. It is meant for 342 research and available for download from 343 http://heim.ifi.uio.no/naeemk/research/ABE/ This code was used to 344 produce the test results that are reported in [ABE2017]. 346 9. Security Considerations 348 The described method is a sender-side only transport change, and does 349 not change the protocol messages exchanged. The security 350 considerations for ECN [RFC3168] therefore still apply. 352 This is a change to TCP congestion control with ECN that will 353 typically lead to a change in the capacity achieved when flows share 354 a network bottleneck. This could result in some flows receiving more 355 than their fair share of capacity. Similar unfairness in the way 356 that capacity is shared is also exhibited by other congestion control 357 mechanisms that have been in use in the Internet for many years 358 (e.g., CUBIC [I-D.CUBIC]). Unfairness may also be a result of other 359 factors, including the round trip time experienced by a flow. ABE 360 applies only when ECN-marked packets are received, not when packets 361 are lost, hence use of ABE cannot lead to congestion collapse. 363 10. Revision Information 365 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 367 -01. Text improved, mainly incorporating comments from Stuart 368 Cheshire. The reference to a technical report has been updated to a 369 published version of the tests [ABE2017]. Used "AQM Mechanism" 370 throughout in place of other alternatives, and more consistent use of 371 technical language and clarification on the intended purpose of the 372 experiments required by EXP status. There was no change to the 373 technical content. 375 -00. draft-ietf-tcpm-alternativebackoff-ecn-00 replaces draft- 376 khademi-tcpm-alternativebackoff-ecn-01. Text describing the nature 377 of the experiment was added. 379 Individual draft -01. This I-D now refers to draft-black-tsvwg-ecn- 380 experimentation-02, which replaces draft-khademi-tsvwg-ecn- 381 response-00 to make a broader update to RFC3168 for the sake of 382 allowing experiments. As a result, some of the motivating and 383 discussing text that was moved from draft-khademi-alternativebackoff- 384 ecn-03 to draft-khademi-tsvwg-ecn-response-00 has now been re- 385 inserted here. 387 Individual draft -00. draft-khademi-tsvwg-ecn-response-00 and draft- 388 khademi-tcpm-alternativebackoff-ecn-00 replace draft-khademi- 389 alternativebackoff-ecn-03, following discussion in the TSVWG and TCPM 390 working groups. 392 11. References 394 11.1. Normative References 396 [I-D.ECN-exp] 397 Black, D., "Explicit Congestion Notification (ECN) 398 Experimentation", Internet-draft, IETF work-in-progress 399 draft-ietf-tsvwg-ecn-experimentation-02, April 2017. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 407 of Explicit Congestion Notification (ECN) to IP", 408 RFC 3168, DOI 10.17487/RFC3168, September 2001, 409 . 411 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 412 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 413 . 415 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 416 Recommendations Regarding Active Queue Management", 417 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 418 . 420 11.2. Informative References 422 [ABE2017] Khademi, N., Armitage, G., Welzl, M., Fairhurst, G., 423 Zander, S., and D. Ros, "Alternative Backoff: Achieving 424 Low Latency and High Throughput with ECN and AQM", IFIP 425 NETWORKING 2017, Stockholm, Sweden, June 2017. 427 [BUFFERBLOAT] 428 "Bufferbloat project", 429 . 432 [CODEL2012] 433 Nichols, K. and V. Jacobson, "Controlling Queue Delay", 434 July 2012, . 436 [I-D.CoDel] 437 Nichols, K., Jacobson, V., McGregor, V., and J. Iyengar, 438 "Controlled Delay Active Queue Management", Internet- 439 draft, IETF work-in-progress draft-ietf-aqm-codel-07, 440 March 2017. 442 [I-D.CUBIC] 443 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 444 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 445 Internet-draft, IETF work-in-progress draft-ietf-tcpm- 446 cubic-04, February 2017. 448 [I-D.ietf-tcpm-accurate-ecn] 449 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 450 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 451 ecn-01 (work in progress), June 2016. 453 [I-D.ietf-tcpm-dctcp] 454 Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., 455 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 456 Control for Datacenters", draft-ietf-tcpm-dctcp-02 (work 457 in progress), July 2016. 459 [ICC2002] Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior 460 with Explicit Congestion Notification (ECN)", IEEE 461 ICC 2002, New York, New York, USA, May 2002, 462 . 464 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 465 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 466 DOI 10.17487/RFC7713, December 2015, 467 . 469 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 470 "Proportional Integral Controller Enhanced (PIE): A 471 Lightweight Control Scheme to Address the Bufferbloat 472 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 473 . 475 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 476 Explicit Congestion Notification (ECN)", RFC 8087, 477 DOI 10.17487/RFC8087, March 2017, 478 . 480 Authors' Addresses 482 Naeem Khademi 483 University of Oslo 484 PO Box 1080 Blindern 485 Oslo N-0316 486 Norway 488 Email: naeemk@ifi.uio.no 490 Michael Welzl 491 University of Oslo 492 PO Box 1080 Blindern 493 Oslo N-0316 494 Norway 496 Email: michawe@ifi.uio.no 498 Grenville Armitage 499 Centre for Advanced Internet Architectures 500 Swinburne University of Technology 501 PO Box 218 502 John Street, Hawthorn 503 Victoria 3122 504 Australia 506 Email: garmitage@swin.edu.au 508 Godred Fairhurst 509 University of Aberdeen 510 School of Engineering, Fraser Noble Building 511 Aberdeen AB24 3UE 512 UK 514 Email: gorry@erg.abdn.ac.uk