idnits 2.17.1 draft-fairhurst-tsvwg-datagram-plpmtud-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2369 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) == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tsvwg-sctp-dtls-encaps' is defined on line 863, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-04 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-01 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 3 errors (**), 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 G. Fairhurst 3 Internet-Draft T. Jones 4 Intended status: Standards Track University of Aberdeen 5 Expires: May 01, 2018 M. Tuexen 6 I. Ruengeler 7 Muenster University of Applied Sciences 8 October 30, 2017 10 Packetization Layer Path MTU Discovery for Datagram Transports 11 draft-fairhurst-tsvwg-datagram-plpmtud-01.txt 13 Abstract 15 This document describes a robust method for Path MTU Discovery 16 (PMTUD) for datagram packetization layers. It allows these layers to 17 probe an Internet path with progressively larger packets to determine 18 a maximum packet size This method is described as an extension to RFC 19 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for IP 20 versions 4 and 6. The document provides functionally for datagram 21 transports that is equivalent to the packetization layer PMTUD 22 specification for TCP, specified in RFC4821. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 01, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Features required to provide PLPMTUD at the Transport Layer . 6 60 3.1. PMTU Probe Packets . . . . . . . . . . . . . . . . . . . . 8 61 3.2. Validation of the current effective PMTU . . . . . . . . . 9 62 3.3. Reduction of the effective PMTU . . . . . . . . . . . . . 9 63 4. Datagram PLPMTUD . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.4. Variables . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Specification of Protocol-Specific Methods . . . . . . . . . . 13 70 5.1. UDP and UDP-Lite . . . . . . . . . . . . . . . . . . . . . 13 71 5.1.1. UDP Options . . . . . . . . . . . . . . . . . . . . . 14 72 5.1.2. UDP Options required for PLPMTUD . . . . . . . . . . . 14 73 5.1.2.1. Echo Request Option . . . . . . . . . . . . . . . 14 74 5.1.2.2. Echo Response Option . . . . . . . . . . . . . . . 14 75 5.1.3. Sending UDP-Option Probe Packets . . . . . . . . . . . 14 76 5.1.4. Validating the Path with UDP Options . . . . . . . . . 15 77 5.1.5. Handling of PTB Messages by UDP . . . . . . . . . . . 15 78 5.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 5.2.1. SCTP/IP4 and SCTP/IPv6 . . . . . . . . . . . . . . . . 15 80 5.2.1.1. Sending SCTP Probe Packets . . . . . . . . . . . . 15 81 5.2.1.2. Validating the Path with SCTP . . . . . . . . . . 16 82 5.2.1.3. PTB Message Handling by SCTP . . . . . . . . . . . 16 83 5.2.2. SCTP/UDP . . . . . . . . . . . . . . . . . . . . . . . 16 84 5.2.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . . 16 85 5.2.2.2. Validating the Path with SCTP/UDP . . . . . . . . 16 86 5.2.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . . 16 87 5.2.3. SCTP/DTLS . . . . . . . . . . . . . . . . . . . . . . 16 88 5.2.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 17 89 5.2.3.2. Validating the Path with SCTP/DTLS . . . . . . . . 17 90 5.2.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 17 91 5.3. Other IETF Transports . . . . . . . . . . . . . . . . . . 17 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 98 Appendix A. Event-driven state changes . . . . . . . . . . . . . . 19 99 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 102 1. Introduction 103 The IETF has specified datagram transport using UDP, SCTP, SCTP/UDP, 104 DCCP, and DCCP/UDP, as well as protocols layered on top of these 105 transports. 107 Classical Path Maximum Transmission Unit Discovery (PMTUD) can be 108 used with any transport that is able to process ICMP Packet Too Big 109 (PTB) messages (e.g., [RFC1191] and [RFC8201]). It adjusts the 110 effective Path MTU (PMTU), based on reception of ICMP Path too Big 111 (PTB) messages to decrease the PMTU when a packet is sent with a size 112 larger than the value supported along a path, and a method that from 113 time-to-time increases the packet size in attempt to discover an 114 increase in the supported PMTU. 116 However, Classical PMTUD is subject to protocol failures. One 117 failure arises when traffic using a packet size larger than the 118 actual supported PMTU is blackholed (silently discarded). This may 119 happen when ICMP PTB messages are not delivered back to the sender 120 for some reason [RFC2923]). For example, ICMP messages are 121 increasingly filtered by middleboxes (including Firewalls) [RFC4890], 122 and may not be correctly processed by tunnel endpoints. 124 Another failure could result if a system not on the path sends a PTB 125 that attempts to force the sender to change the effective PMTU 126 [RFC8201]. A sender could protect itself by using the quoted packet 127 within the PTB message payload to verify that the received PTB 128 message was generated in response to a packet that had actually been 129 sent. However, there are situations where a sender is unable to 130 provide this verification (e.g., when the PTB message does not 131 include sufficient information, often the case for IPv4; or where the 132 information corresponds to an encrypted packet). At the network layer 133 there also could be insufficient context to perform this 134 verification, which depends on information about the active transport 135 flows (e.g., the socket/address pairs being used, and other protocol 136 header information). This verification is more straight forward at a 137 the Packetization Layer (PL) or a higher layer. 139 The term Packetization Layer has been introduced to describe the 140 layer that is responsible for placing data blocks into the payload of 141 packets and selecting an appropriate maximum packet size. This 142 function is often performed by a transport protocol, but can also be 143 performed by other encapsulation methods working below the 144 application. 146 In contrast to PMTUD, Packetization Layer Path MTU Discovery 147 (PLPMTUD) [RFC4821] does not rely upon reception and verification of 148 PTB messages. It is therefore more robust than Classical PMTUD. This 149 has become the recommended approach for implementing PMTU discovery 150 with TCP. It uses a general strategy where the PL searches for an 151 appropriate PMTU by sending probe packets along the network path with 152 a progressively larger packet size. If a probe packet is 153 successfully delivered (as determined by the PL), then the effective 154 Path MTU is raised to the probe size. 156 PLPMTUD introduces flexibility in the implementation of PMTU 157 discovery. At one extreme, it can be configured to only perform PTB 158 black hole recovery to increase the robustness of Classical PMTUD, or 159 at the other extreme, all PTB processing can be disabled and PLPMTUD 160 can completely replace Classical PMTUD. PLPMTUD can also include 161 additional consistency checks without increasing the risk of 162 blackholing. 164 The UDP-Guidelines [RFC8085] state "an application SHOULD either use 165 the path MTU information provided by the IP layer or implement Path 166 MTU Discovery (PMTUD)", but does not provide a mechanism for 167 discovering the largest size of unfragmented datagram than can be 168 used on a path. PLPMTUD has not currently been specified for UDP, 169 while Section 10.2 of [RFC4821] recommends a PLPMTUD probing method 170 for SCTP that utilises heartbeat messages as packet probes, but does 171 not provide a complete specification. This document provides the 172 details to complete that specification. Similarly, the method 173 defined in this specification could be used with the Datagram 174 Congestion Control Protocol (DCCP) [RFC4340] requires implementations 175 to support Classical PMTUD and states that a DCCP sender "MUST 176 maintain the maximum packet size (MPS) allowed for each active DCCP 177 session". It also defines the current congestion control maximum 178 packet size (CCMPS) supported by a path. This recommends use of 179 PMTUD, and suggests use of control packets (DCCP-Sync) as path probe 180 packets, because they do not risk application data loss. The 181 document also contains information that enables the implementation of 182 PLPMTUD with other datagram transports 184 Section Section 4 of this document presents a set of algorithms for 185 datagram protocols to discover a maximum size for the effective PMTU 186 across a path. The methods described rely on features of the PL 187 Section 3 and apply to transport protocols over IPv4 and IPv6. It 188 does not require cooperation from the lower layers (except that they 189 are consistent about which packet sizes are acceptable). It can 190 utilise PTB messages when these are available. 192 2. Terminology 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 Other terminology is directly copied from [RFC4821], and the 199 definitions in [RFC1122]. 201 Black-Holed: When the sender is unaware that packets are not 202 delivered to the destination endpoint (e.g., when the sender is 203 unaware of a change in the path to one with a smaller PMTU). 205 Classical Path MTU Discovery: Classical PMTUD is a process described 206 in [RFC1191] and [RFC8201], in which nodes rely on PTB messages to 207 learn the largest size of unfragmented datagram than can be used 208 across a path. 210 Datagram: A datagram is a transport-layer protocol data unit, 211 transmitted in the payload of an IP packet. 213 Effective PMTU: The current estimated value for PMTU used by a 214 Packetization Layer. 216 EMTU_S: The Effective MTU for sending (EMTU_S) is defined in 217 [RFC1122] as "the maximum IP datagram size that may be sent, for a 218 particular combination of IP source and destination addresses...". 220 EMTU_R: The Effective MTU for receiving (EMTU_R) is designated in 221 [RFC1122] as "the largest datagram size that can be reassembled by 222 EMTU_R ("Effective MTU to receive")". 224 Link: A communication facility or medium over which nodes can 225 communicate at the link layer, i.e., a layer below the IP layer. 226 Examples are Ethernet LANs and Internet (or higher) layer and 227 tunnels. 229 Link MTU: The Maximum Transmission Unit (MTU) is the size in bytes of 230 the largest IP packet, including the IP header and payload, that 231 can be transmitted over a link. Note that this could more 232 properly be called the IP MTU, to be consistent with how other 233 standards organizations use the acronym MTU. This includes the IP 234 header, but excludes link layer headers and other framing that is 235 not part of IP or the IP payload. Other standards organizations 236 generally define link MTU to include the link layer headers. 238 MPS: The Maximum Packet Size (MPS), the largest size of application 239 data block that may be sent unfragmented across a path. In 240 PLPMTUD this quantity is derived from Effective PMTU by taking 241 into consideration the size of the application and lower protocol 242 layer headers, and may be limited by the application protocol. 244 Packet: An IP header plus the IP payload. 246 Packetization Layer (PL): The layer of the network stack that places 247 data into packets and performs transport protocol functions. 249 Path: The set of link and routers traversed by a packet between a 250 source node and a destination node. 252 Path MTU (PMTU): The minimum of the link MTU of all the links forming 253 a path between a source node and a destination node. 255 PLPMTUD: Packetization Layer Path MTU Discovery, the method described 256 in this document for datagram PLs, which is an extension to 257 Classical PMTU Discovery. 259 3. Features required to provide PLPMTUD at the Transport Layer 261 TCP PLPMTUD has been defined using standard TCP protocol mechanisms. 262 All of the requirements in [RFC4821] also apply to use of the 263 technique with a datagram PL. Unlike TCP, some datagram PLs require 264 additional mechanisms to implement PLPMTUD. 266 There are ten requirements for performing the datagram PLPMTUD method 267 described in this specification: 269 1. PMTU parameters: A PLPMTUD sender is REQUIRED to provide 270 information about the maximum size of packet that can be 271 transmitted by the sender on the local link (the Link MTU and MAY 272 utilize similar information about the receiver when this is 273 supplied (note this may be less than EMTU_R). Some applications 274 also have a maximum transport protocol data unit (PDU) size, in 275 which case there may be no benefit from probing for a size larger 276 than this (unless a transport allows multiplexing multiple 277 applications PDUs into the same datagram.) 279 2. Effective PMTU: A datagram application MUST be able to choose the 280 size of datagrams sent to the network, up to the effective PMTU, 281 or a smaller value (such as the MPS) derived from this. This 282 value is managed by the PMTUD method. The effective PMTU 283 (specified in Section 1 of [RFC1191]) is equivalent to the EMTU_S 284 (specified in [RFC1122]). 286 3. Probe packets: On request, a PLPMTUD sender is REQUIRED to be 287 able to transmit a packet larger than the current effective PMTU 288 (but always with a total size less than the link MTU), which the 289 method can use as a probe packet. In IPv4, a probe packet is 290 always sent with the Don't Fragment (DF) bit set and without 291 network layer endpoint fragmentation. 293 4. Processing PTB messages: A PLPMTUD sender MAY optionally utilize 294 PTB messages received from the network layer to help identify 295 when a path does not support the current size of packet probe. 296 Any received PTB message SHOULD/MUST be verified before it is 297 used to update the PMTU discovery information [RFC8201]. This 298 verification confirms that the PTB message was sent in response 299 to a packet originating by the sender, and needs to be performed 300 before the PMTU discovery method reacts to the PTB message. When 301 the router link MTU is indicated in the PTB message this MAY be 302 used by datagram PLPMTUD to reduce the size of a probe, but MUST 303 NOT be used increase the effective PMTU. 305 5. Reception feedback: The destination PL endpoint is REQUIRED to 306 provide a feedback method that indicates when a probe packet has 307 been received by the destination endpoint. The local PL endpoint 308 is REQUIRED to pass this feedback to the sender PLPMTUD method. 310 6. Probing and congestion control: The isolated loss of a probe 311 packet SHOULD NOT be treated as an indication of congestion and 312 its loss not directly trigger a congestion control reaction. 314 7. Probe loss recovery: If the data block carried by a probe message 315 needs to be sent reliably, the PL (or layers above) MUST arrange 316 retransmission/repair of any resulting loss. This method MUST be 317 robust in the case where paket probes are lost due to other 318 reasons (including link transmission error, congestion). The 319 PLPMTUD method treats isolated loss of a probe packet (with or 320 without an PTB message) as a potential indication of a PMTU limit 321 on the path. The PL is permitted to retransmit any data included 322 in a lost probe packet without adjusting its congestion window. 324 8. Cached effective PMTU: The sender MUST cache the effective PMTU 325 value between probes and needs also to consider the disruption 326 that could be incurred by an unsuccessful probe - both upon the 327 flow that incurs a probe loss, and other flows that experience 328 the effect of additional probe traffic. 330 9. Shared effective PMTU state: The specification of PLPMTUD 331 [RFC4821] states: "If PLPMTUD updates the MTU for a particular 332 path, all Packetization Layer sessions that share the path 333 representation (as described in Section 5.2 of [RFC4821]) SHOULD 334 be notified to make use of the new MTU and make the required 335 congestion control adjustments". Such methods need to robust to 336 the wide variety of underlying network forwarding behaviours. 337 Considerations about caching have been noted [RFC8201]. 339 In addition the following design principles are stated: 341 o Suitable MPS: The PLPMTUD method SHOULD avoid forcing an 342 application to use an arbitrary small MPS (effective PMTU) for 343 transmission while the method is searching for the currently 344 supported PMTU. Datagram PLs do not necessarily support 345 fragmentation of PDUs larger than the PMTU. A reduced MPS can 346 adversely impact the performance of a datagram application. 348 o Path validation: The PLPMTUD method MUST be robust to path changes 349 that could have occurred since the path characteristics were last 350 confirmed. 352 o Datagram reordering: A method MUST be robust to the possibility 353 that a flow encounters reordering, or has the traffic (inlcuding 354 probe packets) is divided over more than one network path. 356 o When to probe: The PLPMTUD method SHOULD determine whether the 357 path capacity has increased since it last measured the path. This 358 determines when the path should again be probed. 360 3.1. PMTU Probe Packets 362 PMTU discovery relies upon the sender being able to generate probe 363 messages with a specific size. TCP is able to generate probe packets 364 by choosing to appropriately segment data being sent [RFC4821]. 366 In contrast, datagram PLs either have to request an application to 367 send a data block with a specified size, or to utilise padding 368 functions to extend the datagram beyond the size of the application 369 data block. Protocols that permit exchange of control messages 370 (without an application data block) could alternatively prefer to 371 generate a probe packet by extending a control message with padding 372 data. 374 When the method fails to validate the PMTU for the path, the required 375 size of probe packet can need to be less than the size of the data 376 block generated by an application. In this case, the PL could 377 provide a wat to fragment a datagram at the PL, or could instead 378 utilise a control packet with padding. 380 A receiver needs to be able to be able to distinguish in-band data 381 from any added padding, and ensure that any added padding is not 382 passed to an application at the receiver. 384 This results in three ways that a sender can create a probe packet: 386 Probing using appication data: A probe packet that contains a data 387 block supplied by an application that matches the size required 388 for the probe. This requires a method to request the application 389 to issue a data block of the desired probe size. If the 390 application/transport needs protection from the loss of this probe 391 packet, the application/transport may perform transport-layer 392 retransmission/repair of the data block (e.g., by retransmission 393 after loss is detected or by duplicating the data block in a 394 datagram without the padding data). 396 Probing using appication data: A probe packet that contains a data 397 block supplied by an application that is combined with padding to 398 inflate the length of the datagram to the size required for the 399 probe. If the application/transport needs protection from the 400 loss of this probe packet, the application/transport may perform 401 transport-layer retransmission/repair of the data block (e.g., by 402 retransmission after loss is detected or by duplicating the data 403 block in a datagram without the padding data). 405 Probing using appication data: A probe packet that contains only 406 control information and padding to inflate the packet to the size 407 required for the probe. Since these probe packets do not carry 408 any application-supplied data block,they do not typically require 409 retransmission, although they do still consume network capacity. 411 3.2. Validation of the current effective PMTU 413 The PL needs a method to determine when packet probes have been 414 successfully received end-to-end across a network path. 416 Transport protocols can include end-to-end methods that detect and 417 report reception of specific datagrams that they send (e.g., DCCP and 418 SCTP provide keep-alive/heartbeat features). This can also be used by 419 PLPMTUD to acknowledge reception of a probe packet. 421 A PL that does not acknowledge data reception (e.g., UDP and UDP- 422 Lite) is unable to detect when the packets it sends are discarded 423 because their size is greater than the actual PMTUD. These PLs need 424 to either reply on application protocol to detect this, or use of an 425 additional transport method such as UDP-Options [I-D.ietf-tsvwg-udp- 426 options], and then need to send a reachability probe (e.g., 427 periodically solicit a response) to determine if the current 428 effective PMTU is still supported by the network path. 430 PMTU discovery can also utilise PTB messages to detect when the 431 actual PMTU supported by a network path is less than the current size 432 of datagrams that are being sent. 434 3.3. Reduction of the effective PMTU 436 When the current effective PMTU is no longer supported by the network 437 path, the transport needs to detect this and reduce the effective 438 PMTU. 440 o A PL that sends a datagram larger than the actual PMTU that 441 includes no application data block, or one that does not attempt 442 to provide any retransmission, can send a new probe packet with an 443 updated probe size. 445 o A PL that wishes to resend the application data block, may need to 446 re-fragment the data block to a smaller datagram size. This could 447 utilise network-layer or PL fragmentation when these are 448 available. 450 4. Datagram PLPMTUD 452 This section specifies Datagram PLPMTUD. 454 The central idea of PLPMTU discovery is probing by a sender. Probe 455 packets of increasing size are sent to find out the maximum size of a 456 user message that is completely transferred across the network path 457 from the sender to the destination. If a PTB message is received 458 from a router or middlebox, this information ought to be verified and 459 SHOULD used. The PTB messages can improve performance compared to 460 one that relies solely on probing. 462 4.1. Probing 464 The PLPMTUD method utilises a timer to trigger the generation of 465 probe packets. The probe_timer is started each time a probe packet 466 is sent to the destination and is cancelled when receipt of the probe 467 packet is acknowledged. Each time the probe_timer expires, the 468 probe_error_counter is incremented, and the probe packet is 469 retransmitted. The counter is initialised to zero when a probe 470 packet is first sent with a particular size. The maximum number of 471 retransmissions per probing size is configured (MAX_PROBES). If the 472 value of the PROBE_COUNT exceeds MAX_PROBES, probing will be stopped 473 and the last successfully probed PMTU is set as the effective PMTU. 475 Once probing is completed, the sender continues to use the effective 476 PMTU until either a PTB message is received or the PMTU_RAISE_TIMER 477 expires. If the PL is unable to verify reachability to the 478 destination endpoint after probing has completed, the method uses a 479 REACHABILITY_TIMER to periodically repeat a probe packet for the 480 current effective PMTU size, while the PMTU_RAISE_TIMER is running. 481 If the resulting probe packet is not acknowledged (i.e. the 482 PROBE_TIMER expires), the method re-starts probing for the PMTU. 484 4.2. Timers 486 This method utilises three timers: 488 PROBE_TIMER: Configured to expire after a period longer than the 489 maximum time to receive an acknowledgment to a probe packet. 491 PMTU_RAISE_TIMER: Configured to the period a sender ought to continue 492 use the current effective PMTU, after which it re-commences 493 probing for a higher PMTU. This timer has a period of 600 secs, as 494 recommended by [RFC4821]. 496 REACHABILITY_TIMER: Configured to the period a sender ought to wait 497 before confirming the current effective PMTU is still supported. 498 This is less than the PMTU_RAISE_TIMER. 500 An implementation could implement the various timers using a single 501 timer process. 503 4.3. Constants 505 The following constants are defined: 507 MAX_PROBES: The maximum value of the PROBE_ERROR_COUNTER. 509 MIN_PMTU: The smallest allowed probe packet size. This value is 1280 510 bytes as specified in [RFC2460]. 512 BASE_PMTU: The BASE_PMTU is a considered a size that should work in 513 most cases. The size equal to or larger than the minimum 514 permitted and smaller than the maximum allowed. In the case of 515 IPv6, this value is 1280 bytes as specified in [RFC2460]. When 516 using IPv4, a size of 1200 is RECOMMENDED. 518 MAX_PMTU: This is the largest size of PMTU that is probed. It must 519 be less than or equal to the minimum of the local MTU of the 520 outgoing interface and the destination effective MTU for 521 receiving. 523 4.4. Variables 525 This method utilises a set of variables: 527 effective PMTU: The effective PMTU is the maximum size of datagram 528 that the method has currently determined can be supported along 529 the entire path. 531 PROBED_SIZE: The PROBED_SIZE is the size of the current probe packet. 532 This is a tentative value for the effective PMTU, which is 533 awaiting confirmation by an acknowledgment. 535 PROBE_COUNT: This is a count of the number of unsuccessful probe 536 packets that have been sent with size PROBED_SIZE. The value is 537 initialised to zero when a particular size of PROBED_SIZE is first 538 attempted. 540 PTB_SIZE: The PTB_Sizde is value returned by a verified PTB message 541 indicating the local MTU size of a router along the path. 543 4.5. State Machine 545 A state machine for Datagram PLPMTUD is depicted in Figure 1. If 546 multihoming is supported, a state machine is needed for each active 547 path. 549 +------------+ 550 | PROBE_NONE | 551 +------------+ 552 | Connectivity confirmed 553 v 554 ---------- +------------+ -- PROBE_TIMER expiry 555 MAX_PMTU acked | | PROBE_BASE | | (PROBE_COUNT < MAX_PROBES) 556 PTB (>= BASE_PMTU)| -----> +------------+ <- 557 ---------------- | /\ | | 558 | | | | | PTB 559 | PMTU_RAISE_TIMER| | | | (PTB_SIZE < BASE_PMTU) 560 | or reachability | | | | or 561 | (PROBE_COUNT | | | | PROBE_TIMER expiry 562 | = MAX_PROBES) | | | | (PROBE_COUNT = MAX_PROBES) 563 | ------------- | | \ 564 | | PTB | | \ 565 | | (< PROBED_SIZE)| | \ 566 | | | | --------------- 567 | | | | | 568 | | | | Probe | 569 | | | | acked | 570 v | | v v 571 +------------+ +--------------+ Probe +-------------+ 572 | PROBE_DONE |<-------------- | PROBE_SEARCH |<-------| PROBE_ERROR | 573 +------------+ MAX_PMTU acked +--------------+ acked +-------------+ 574 /\ | or /\ | 575 | | PROBE_TIMER expiry | | 576 | |(PROBE_COUNT = MAX_PROBES) | | 577 | | | | 578 ----- ------ 579 Reachability probe acked PROBE_TIMER expiry 580 or PROBE_TIMER expiry (PROBE_COUNT < MAX_PROBES) 581 (PROBE_COUNT < MAX_PROBES) 583 The following states are defined to reflect the probing process. 585 PROBE_NONE: The PROBE_NONE state is the initial state before probing 586 has started. PLPMTUD is not performed in this state. The state 587 transitions to PROBE_BASE, when a path has been confirmed, i.e. 588 when a packet has arrived on this path. The effective PMTU is set 589 to the BASE_PMTU size. Probing ought to start immediately after 590 connection setup to prevent the loss of user data. 592 PROBE_BASE: The PROBE_BASE state is the starting point for datagram 593 PLPMTUD, and used to confirm whether the BASE_PMTU size is 594 supported by the network path. On entry, the PROBED_SIZE is set 595 to the BASE_PMTU size and the PROBE_COUNT is set to zero. A probe 596 packet is sent, and the PROBE_TIMER is started. The state is left 597 when the PROBE_COUNT reaches MAX_PROBES; a PTB message is 598 received, or a probe packet is acknowledged. 600 PROBE_SEARCH: The PROBE_SEARCH state is the main probing state. This 601 state is entered either when probing for the BASE_PMTU was 602 successful or when there is a successful reachability test in the 603 PROBE_ERROR state. On entry, the effective PMTU is set to the 604 last acknowledged PROBED_SIZE. 606 On the first probe packet for each probed size, the PROBE_COUNT is 607 set to zero. Each time a probe packet is acknowledged, the 608 effective PMTU is set to the PROBED_SIZE, and then the PROBED_SIZE 609 is increased. When a probe packet is not acknowledged within the 610 period of the PROBE_TIMER, the PROBE_COUNT is incremented and the 611 probe packet is retransmitted. The state is exited when the 612 PROBE_COUNT reaches MAX_PROBES; a PTB message is verified; or a 613 probe of size PMTU_MAX is acknowledged. 615 PROBE_ERROR: The PROBE_ERROR state represents the case where the 616 network path is not known to support an effective PMTU of at least 617 the BASE_PMTU size. It is entered when either a probe of size 618 BASE_PMTU has not been acknowledged or a verified PTB message 619 indicates a smaller link MTU than the BASE_PMTU. On entry, the 620 PROBE_COUNT is set to zero and the PROBED_SIZE is set to the 621 MIN_PMTU size, and the effective PMTU is reset to MIN_PMTU size. 622 In this state, a probe packet is sent, and the PROBE_TIMER is 623 started. The state transitions to the PROBE_SEARCH state when a 624 probe packet is acknowledged. 626 PROBE_DONE: The PROBE_DONE state indicates a successful end to a 627 probing phase. Datagram PLPMTUD remains in this state until 628 either the PMTU_RAISE_TIMER expires or a PTB message is verified. 630 When PLPMTUD uses an unacknowledged PL and is in the PROBE_DONE 631 state, a REACHABILITY_TIMER periodically resets the PROBE_COUNT 632 and schedules a probe packet with the size of the effective PMTU. 633 If the probe packet fails to be acknowledged after MAX_PROBES 634 attempts, the method enters the PROBE_BASE state. An acknowledged 635 PL SHOULD NOT continue to probe in this state. 637 Appendix Appendix A contains an informative description of key 638 events: 640 5. Specification of Protocol-Specific Methods 642 This section specifies protocol-specific details for datagram PLPMTUD 643 for IETF-specified transport protocols. 645 5.1. UDP and UDP-Lite 646 The current specifications of UDP and UDP-LIte [RFC3828] do not 647 define a method in the RFC-series that supports PLPMTUD. In 648 particular, these transport do not provide the transport layer 649 features needed to implement datagram PLPMTUD. 651 5.1.1. UDP Options 653 UDP-Options [I-D.ietf-tsvwg-udp-options] supply the additional 654 functionality required to implement datagram PLPMTUD. This enables 655 padding to be added to UDP datagrams and can be used to provide 656 feedback acknowledgement of received probe packets. 658 5.1.2. UDP Options required for PLPMTUD 660 This subsection proposes two new UDP-Options that add support for 661 requesting a datagram response be sent and to mark this datagram as a 662 response to a request. 664 << We may define a parameter in an Option to indicate the EMTU_R to 665 the peer.>> 667 5.1.2.1. Echo Request Option 669 The Echo Request Option allows a sending endpoint to solicit a 670 response from a destination endpoint. The Echo Request carries a 671 four byte token set by the sender. 673 +---------+--------+-----------------+ 674 | Kind=9 | Len=6 | Token | 675 +---------+--------+-----------------+ 676 1 byte 1 byte 4 bytes 678 5.1.2.2. Echo Response Option 680 The Echo Response Option is generated by the PL in response to 681 reception of a previously received Echo Request. The Token field is 682 associates the response with the Token value carried in the most 683 recently-received Echo Request. The rate of generation of UDP 684 packets carrying an Echo Response Option MAY be rate-limited. 686 +---------+--------+-----------------+ 687 | Kind=10 | Len=6 | Token | 688 +---------+--------+-----------------+ 689 1 byte 1 byte 4 bytes 691 5.1.3. Sending UDP-Option Probe Packets 693 This method specifies a probe packet that does not carry an 694 application data block. The probe packet consists of a UDP datagram 695 header followed by a UDP Option containing the ECHOREQ option, which 696 is followed by NOP Options to pad the remainder of the datagram 697 payload. The NOP padding is used to control the length of the probe 698 packet. 700 A UDP Option carrying the ECHORES option is used to provide feedback 701 when the probe packet is received at the destination endpoint. 703 5.1.4. Validating the Path with UDP Options 705 Since UDP is an unacknowledged PL, a sender that does not have 706 higher-layer information confirming correct delivery of datagrams 707 SHOULD implement the REACHABILITY_TIMER to periodically send probe 708 packets while in the PROBE_DONE state. 710 5.1.5. Handling of PTB Messages by UDP 712 Normal ICMP verification MUST be performed as specified in Section 713 5.2 of [RFC8085]. This requires that the PL verifies each received 714 PTB messages to verify these are received in response to transmitted 715 traffic. A verified PTB message MAY be used as input to the PLPMTUD 716 algorithm. 718 5.2. SCTP 720 Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing 721 method for SCTP. It recommends the use of the PAD chunk, defined in 722 [RFC4820] to be attached to a minimum length HEARTBEAT chunk to build 723 a probe packet. This enables probing without affecting the transfer 724 of user messages and without interfering with congestion control. 725 This is preferred to the use of DATA chunks (with padding as 726 required) to serve as path probes. 728 << We might define a parameter contained in the INIT and INIT ACK 729 chunk to indicate the MTU to the peer. However, multihoming makes 730 this a bit complex, so it might not be worth doing.>> 732 5.2.1. SCTP/IP4 and SCTP/IPv6 734 The base protocol is specified in [RFC4960]. 736 5.2.1.1. Sending SCTP Probe Packets 738 Probe packets consist of an SCTP common header followed by a 739 HEARTBEAT chunk and a PAD chunk. The PAD chunk is used to control 740 the length of the probe packet. The HEARTBEAT chunk is used to 741 trigger the sending of a HEARTBEAT ACK chunk. The reception of the 742 HEARTBEAT ACK chunk acknowledges reception of a successful probe. 744 The HEARTBEAT chunk carries a Heartbeat Information parameter which 745 should include, besides the information suggested in [RFC4960], the 746 probing size, which is the MTU size the complete datagram will add up 747 to. The size of the PAD chunk is therefore computed by reducing the 748 probing size by the IPv4 or IPv6 header size, the SCTP common header, 749 the HEARTBEAT request and the PAD chunk header. The payload of the 750 PAD chunk contains arbitrary data. 752 To avoid the fragmentation of retransmitted data, probing starts 753 right after the handshake before data is sent. Assuming normal 754 behaviour (i.e., the PMTU is smaller than or equal to the interface 755 MTU), this process will take a few RTTs depending on the number of 756 PMTU sizes probed. The Heartbeat timer can be used to implement the 757 PROBE_TIMER. 759 5.2.1.2. Validating the Path with SCTP 761 Since SCTP provides an acknowledged PL, a sender does MUST NOT 762 implement the REACHABILITY_TIMER while in the PROBE_DONE state. 764 5.2.1.3. PTB Message Handling by SCTP 766 Normal ICMP verification MUST be performed as specified in Appendix C 767 of [RFC4960]. This requires that the first 8 bytes of the SCTP 768 common header are quoted in the payload of the PTB message , which 769 can be the case for ICMPv4 and is normally the case for ICMPv6. When 770 the verification is completed, the router Link MTU indicated in the 771 PTB message SHOULD be used with the PLPMTUD algorithm. 773 5.2.2. SCTP/UDP 775 The UDP encapsulation of SCTP is specified in [RFC6951]. 777 5.2.2.1. Sending SCTP/UDP Probe Packets 779 Packet probing can be performed as specified in Section 5.2.1.1. The 780 maximum payload is reduced by 8 bytes, which has to be considered 781 when filling the PAD chunk. 783 5.2.2.2. Validating the Path with SCTP/UDP 785 Since SCTP provides an acknowledged PL, a sender does MUST NOT 786 implement the REACHABILITY_TIMER while in the PROBE_DONE state. 788 5.2.2.3. Handling of PTB Messages by SCTP/UDP 790 Normal ICMP verification MUST be performed for PTB messages as 791 specified in Appendix C of [RFC4960]. This requires that the first 8 792 bytes of the SCTP common header are contained in the PTB message, 793 which can be the case for ICMPv4 (but note the UDP header also 794 consumes a part of the quoted packet header) and is normally the case 795 for ICMPv6. When the verification is completed, the router Link MTU 796 size indicated in the PTB message SHOULD be used with the PLPMTUD 797 algorithm. 799 5.2.3. SCTP/DTLS 801 The DTLS encapsulation of SCTP is specified in [I-D.ietf-tsvwg-sctp- 802 dtls-encaps]. It is used for data channels in WebRTC 803 implementations. 805 5.2.3.1. Sending SCTP/DTLS Probe Packets 807 Packet probing can be done as specified in Section 5.2.1.1. 809 5.2.3.2. Validating the Path with SCTP/DTLS 811 Since SCTP provides an acknowledged PL, a sender does MUST NOT 812 implement the REACHABILITY_TIMER while in the PROBE_DONE state. 814 5.2.3.3. Handling of PTB Messages by SCTP/DTLS 816 It is not possible to perform normal ICMP verification as specified 817 in [RFC4960], since even if the ICMP contains enough information, the 818 reflected SCTP common header would be encrypted. Therefore it is not 819 possible to process PTB messages at the PL. 821 5.3. Other IETF Transports 823 QUIC is a UDP-based transport that provides reception feedback [I-D 824 .ietf-quic-transport]. 826 << This section will be completed in a future revision of this ID >> 828 6. Acknowledgements 830 This work was partially funded by the European Union's Horizon 2020 831 research and innovation programme under grant agreement No. 644334 832 (NEAT). The views expressed are solely those of the author(s). 834 7. IANA Considerations 836 This memo includes no request to IANA. 838 If there are no requirements for IANA, the section will be removed 839 during conversion into an RFC by the RFC Editor. 841 8. Security Considerations 843 The security considerations for the use of UDP and SCTP are provided 844 in the references RFCs. Security guidance for applications using UDP 845 is provided in the UDP-Guidelines [RFC8085]. 847 PTB messages could potentially be used to cause a node to 848 inappropriately reduce the effective PMTU. A node supporting PLPMTUD 849 SHOULD appropriately verify the payload of PTB messages to ensure 850 these are received in response to transmitted traffic (i.e., a 851 reported error condition that corresponds to a datagram actually sent 852 by the path layer. 854 9. References 856 9.1. Normative References 858 [I-D.ietf-quic-transport] 859 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 860 and Secure Transport", Internet-Draft draft-ietf-quic- 861 transport-04, June 2017. 863 [I-D.ietf-tsvwg-sctp-dtls-encaps] 864 Tuexen, M., Stewart, R., Jesup, R. and S. Loreto, "DTLS 865 Encapsulation of SCTP Packets", Internet-Draft draft-ietf- 866 tsvwg-sctp-dtls-encaps-09, January 2015. 868 [I-D.ietf-tsvwg-udp-options] 869 Touch, J., "Transport Options for UDP", Internet-Draft 870 draft-ietf-tsvwg-udp-options-01, June 2017. 872 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 873 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 874 RFC1122, October 1989, . 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 879 RFC2119, March 1997, . 882 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 883 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 884 December 1998, . 886 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.Ed., 887 and G. Fairhurst, Ed., "The Lightweight User Datagram 888 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 889 2004, . 891 [RFC4820] Tuexen, M., Stewart, R. and P. Lei, "Padding Chunk and 892 Parameter for the Stream Control Transmission Protocol 893 (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, 894 . 896 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 897 RFC 4960, DOI 10.17487/RFC4960, September 2007, . 900 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 901 Control Transmission Protocol (SCTP) Packets for End-Host 902 to End-Host Communication", RFC 6951, DOI 10.17487/ 903 RFC6951, May 2013, . 906 [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage 907 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 908 March 2017, . 910 [RFC8201] McCann, J., Deering, S., Mogul, J. and R. Hinden, Ed., 911 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 912 DOI 10.17487/RFC8201, July 2017, . 915 9.2. Informative References 917 [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", RFC 918 1191, DOI 10.17487/RFC1191, November 1990, . 921 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 922 2923, DOI 10.17487/RFC2923, September 2000, . 925 [RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion 926 Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, 927 March 2006, . 929 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 930 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 931 . 933 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 934 ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/ 935 RFC4890, May 2007, . 938 Appendix A. Event-driven state changes 940 This appendix contains an informative description of key events: 942 Path Setup: When a new path is initiated, the state is set to 943 PROBE_NONE. As soon as the path is confirmed, the state changes to 944 PROBE_BASE and the probing mechanism for this path is started. A 945 probe packet with the size of the BASE_PMTU is sent. 947 Arrival of an Acknowledgment: Depending on the probing state, the 948 reaction differs according to Figure 4, which is just a 949 simplification of Figure 1 focusing on this event. 951 +--------------+ 952 | PROBE_NONE | -------------- 953 +--------------+ \ 954 \ 955 +--------------+ \ 956 | PROBE_ERROR | --------------- \ 957 +--------------+ \ \ 958 \ \ 959 +--------------+ \ \ +--------------+ 960 | PROBE_BASE | --1---------- \ ------------> | PROBE_BASE | 961 +--------------+ --2----- \ \ +--------------+ 962 \ \ \ 963 +--------------+ \ \ ------------> +--------------+ 964 | PROBE_SEARCH | --2--- \ -----------------> | PROBE_SEARCH | 965 +--------------+ --1---\----\---------------------> +--------------+ 966 \ \ 967 +--------------+ \ \ +--------------+ 968 | PROBE_DONE | \ -------------------> | PROBE_DONE | 969 +--------------+ -----------------------> +--------------+ 971 Condition 1: The maximum PMTU size has not yet been reached. 972 Condition 2: The maximum PMTU size has been reached. 974 Probing timeout: The PROBE_COUNT is initialised to zero each time the 975 value of PROBED_SIZE is changed. The PROBE_TIMER is started each 976 time a probe packet is sent. It is stopped when an acknowledgment 977 arrives that confirms delivery of a probe packet. If the probe 978 packet is not acknowledged before,the PROBE_TIMER expires, the 979 PROBE_ERROR_COUNTER is incremented. When the PROBE_COUNT equals 980 the value MAX_PROBES, the state is changed, otherwise a new probe 981 packet of the same size (PROBED_SIZE) is resent. The state 982 transitions are illustrated in Figure 5. This shows a 983 simplification of Figure 1 with a focus only on this event. 985 +--------------+ 986 | PROBE_NONE | 987 +--------------+ 989 +--------------+ +--------------+ 990 | PROBE_ERROR | -----------------> | PROBE_ERROR | 991 +--------------+ / +--------------+ 992 / 993 +--------------+ --2----------/ +--------------+ 994 | PROBE_BASE | --1------------------------------> | PROBE_BASE | 995 +--------------+ +--------------+ 997 +--------------+ +--------------+ 998 | PROBE_SEARCH | --1------------------------------> | PROBE_SEARCH | 999 +--------------+ --2--------- +--------------+ 1000 \ 1001 +--------------+ \ +--------------+ 1002 | PROBE_DONE | -------------------> | PROBE_DONE | 1003 +--------------+ +--------------+ 1005 Condition 1: The maximum number of probe packets has not been 1006 reached. Condition 2: The maximum number of probe packets has been 1007 reached. 1009 PMTU raise timer timeout: The path through the network can change 1010 over time. It impossible to discover whether a path change has 1011 increased in the actual PMTU by exchanging packets less than or 1012 equal to the effective PMTU. This requires PLPMTUD to periodically 1013 send a probe packet to detect whether a larger PMTU is possible. 1014 This probe packet is generated by the PMTU_RAISE_TIMER. When the 1015 timer expires, probing is restarted with the BASE_PMTU and the 1016 state is changed to PROBE_BASE. 1018 Arrival of an ICMP message: The active probing of the path can be 1019 supported by the arrival of PTB messages sent by routers or 1020 middleboxes with a link MTU that is smaller than the probe packet 1021 size. If the PTB message includes the router link MTU, three 1022 cases can be distinguished: 1024 1. The indicated link MTU in the PTB message is between the 1025 already probed and effective MTU and the probe that triggered 1026 the PTB message. 1028 2. The indicated link MTU in the PTB message is smaller than the 1029 effective PMTU. 1031 3. The indicated link MTU in the PTB message is equal to the 1032 BASE_PMTU. 1034 In first case, the PROBE_BASE state transitions to the PROBE_ERROR 1035 state. In the PROBE_SEARCH state, a new probe packet is sent with 1036 the sized reported by the PTB message. Its result is handled 1037 according to the former events. 1039 The second case could be a result of a network re-configuration. 1040 If the reported link MTU in the PTB message is greater than the 1041 BASE_MTU, the probing starts again with a value of PROBE_BASE. 1042 Otherwise, the method enters the state PROBE_ERROR. 1044 In the third case, the maximum possible PMTU has been reached. 1045 This is probed again, because there could be a link further along 1046 the path with a still smaller MTU. 1048 Note: Not all routers include the link MTU size when they send a 1049 PTB message. If the PTB message does not indicate the link MTU, 1050 the probe is handled in the same way as condition 2 of Figure 5. 1052 Appendix B. Revision Notes 1054 Note to RFC-Editor: please remove this entire section prior to 1055 publication. 1057 Individual draft -00: 1059 o Comments and corrections are welcome directly to the authors or 1060 via the IETF TSVWG working group mailing list. 1062 o This update is proposed for WG comments. 1064 Individual draft -01: 1066 o Contains the first representation of the algorithm, showing the 1067 states and timers 1069 o The text describing when to set the effective PMTU has not yet 1070 been verified by the authors 1072 o The text describing how to handle a PTB message indicating a link 1073 MTU larger than the probe has yet not been verified by the authors 1075 o No text currently describes how to handle inconsistent results 1076 from arbitrary re-routing along different parallel paths 1078 o Some middleboxes lie about the MTU they report in PTB messages. 1080 o Some constants and times do not yet have recommended values 1082 o To determine security to off-path-attacks: We need to decide 1083 whether a received PTB message SHOULD be verified or MUST be 1084 verified? 1086 o This update is proposed for WG comments. 1088 Authors' Addresses 1090 Godred Fairhurst 1091 University of Aberdeen 1092 School of Engineering 1093 Fraser Noble Building 1094 Aberdeen, AB24 3UE 1095 UK 1097 Email: gorry@erg.abdn.ac.uk 1099 Tom Jones 1100 University of Aberdeen 1101 School of Engineering 1102 Fraser Noble Building 1103 Aberdeen, AB24 3UE 1104 UK 1106 Email: tom@erg.abdn.ac.uk 1108 Michael Tuexen 1109 Muenster University of Applied Sciences 1110 Stegerwaldstrasse 39 1111 Steinfurt, 48565 1112 DE 1114 Email: tuexen@fh-muenster.de 1116 Irene Ruengeler 1117 Muenster University of Applied Sciences 1118 Stegerwaldstrasse 39 1119 Steinfurt, 48565 1120 DE 1122 Email: i.ruengeler@fh-muenster.de