idnits 2.17.1 draft-gomez-frag-lpwan-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (August 26, 2019) is 1705 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7959' is mentioned on line 156, but not defined == Unused Reference: 'RFC1122' is defined on line 217, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-21 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LPWAN Working Group C. Gomez 3 Internet-Draft UPC 4 Intended status: Informational J. Crowcroft 5 Expires: February 27, 2020 University of Cambridge 6 August 26, 2019 8 Fragmentation in LPWAN considerations: CoAP Block vs SCHC fragmentation 9 draft-gomez-frag-lpwan-considerations-00 11 Abstract 13 The SCHC adaptation layer provides header compression and 14 fragmentation functionality between IPv6 and an underlying LPWAN 15 technology. SCHC fragmentation has been specifically designed for 16 the characteristics of LPWANs. However, when CoAP is used at the 17 application layer, there exists an alternative approach for 18 fragmentation, which is using the CoAP Block option. This document 19 aims at illustrating the advantages and limitations of each approach 20 for transferring larger payloads. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 27, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 3. Header overhead . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. L2 MTU supported . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Reliability modes . . . . . . . . . . . . . . . . . . . . . . 4 61 6. CoAP RTO calculation . . . . . . . . . . . . . . . . . . . . 4 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 9.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The Static Context Header Compression and fragmentation (SCHC) 72 framework provides an adaptation layer that has been specifically 73 designed to enable support of IPv6 over Low Power Wide Area Network 74 (LPWAN) technologies [I-D.ietf-lpwan-ipv6-static-context-hc]. SCHC 75 comprises header compression and fragmentation functionality. The 76 latter is needed when SCHC is used over technologies such as LoRaWAN 77 or Sigfox [RFC8376], and might be needed over further LPWAN 78 technologies. 80 On the other hand, considering the significant resource constraints 81 in many LPWAN scenarios, the Constrained Application Protocol (CoAP) 82 is a suitable candidate application-layer protocol for use in LPWAN. 83 CoAP has been specified over both UDP and TCP [RFC7252][RFC8323]. 84 For CoAP over UDP, the Block option can be used in order to perform 85 application-layer fragmentation [RFC7959]. In this document, CoAP 86 over UDP is assumed. 88 Therefore, when CoAP and SCHC are used in LPWAN, there exist two 89 possible approaches for fragmentation: SCHC-level fragmentation and 90 CoAP-level fragmentation. This document aims at systematically 91 analyzing the characteristics, advantages and limitations of both 92 approaches. 94 2. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. Header overhead 102 The SCHC specification defines a fragmentation header that is 103 prepended to each fragment. The SCHC fragmentation header has been 104 defined in a flexible way, yet with the aim to enable very short 105 fragmentation header sizes. Fragmentation header sizes are then 106 actually specified per LPWAN technology in corresponding SCHC-over- 107 foo documents. Fragmentation header sizes of 1-2 bytes are currently 108 being used over technologies such as Sigfox or LoRaWAN. When SCHC 109 fragmentation is used, each fragment will carry a SCHC fragmentation 110 header. The first fragment will also carry the SCHC compressed IPv6/ 111 UDP header, which may have a size of 1 byte. 113 When using CoAP blockwise transfers, each block will carry a CoAP 114 header comprising the base header (4 bytes, although perhaps it can 115 be reduced with SCHC CoAP header compression), the option format (2 116 bytes), the Block option value (1-3 bytes) and the payload marker (1 117 byte). In addition, each block will be encapsulated in a different 118 IPv6 datagram. A SCHC compressed IPv6/UDP header may have a size of 119 1 byte. 121 4. L2 MTU supported 123 Assuming that the L2 word [I-D.ietf-lpwan-ipv6-static-context-hc] of 124 the underlying LPWAN technology is 1 byte, and a SCHC fragmentation 125 header of 1 byte, SCHC fragmentation can support underlying LPWAN 126 technologies with a maximum link layer data unit payload of even only 127 2 bytes. 129 The smallest CoAP layer payload size that can be supported with 130 Blockwise transfers is 16 bytes. Note that the whole header 131 overhead, comprising IPv6, UDP and CoAP headers, even when SCHC 132 compression is applied, is added to the CoAP layer payload. While 133 some LPWAN technologies can, at least in some cases, carry a CoAP 134 Block, note that it is not possible with RFC 7959 to transport a CoAP 135 Block over Sigfox (with uplink and downlink L2 MTU values of 12 and 8 136 bytes, respectively) or over LoRaWAN DR0 in the US band (with an L2 137 MTU of 11 bytes). Assuming that SCHC header compression is used, 138 CoAP Blockwise transfers can only be supported over technologies with 139 an L2 MTU of at least ~25 bytes. 141 5. Reliability modes 143 SCHC offers a gradation of reliability modes: No-ACK, ACK-Always, and 144 ACK-on-Error. In No-ACK there is no feedback from the receiver to 145 the sender, and there is no retransmission of fragments. In ACK- 146 Always, the receiver inconditionally generates an ACK after a window 147 of fragments. In ACK-on-Error, the receiver only generates an ACK 148 after a window of fragments if at least one of the fragments of the 149 window has been lost (an exception to this behavior is the last 150 window, for which an ACK-Always behavior is used). Note that each 151 mode involves a different message overhead. 153 CoAP blockwise transfers follow a stop-and-wait behavior by default. 154 Note that congestion control defined in the basic CoAP specification 155 applies, and NON messages are not very useful in blockwise transfers, 156 as they increase the probability of non-delivery [RFC 7959]. 158 6. CoAP RTO calculation 160 CoAP CON messages require an Acknowledgment (ACK) by the receiving 161 endpoint. After sending a CON message, a sender waits for such ACK 162 for Retransmission TimeOut (RTO) time. Upon RTO expiration, the CoAP 163 sender retransmits the message. The CoAP main specification does not 164 define a mechanism for adaptively calculating the RTO based on the 165 Round Trip Time (RTT). However, it is expected that future 166 specifications will do so [I-D.ietf-core-cocoa]. The RTT comprises 167 the time since the CoAP CON message is passed to its lower layer 168 until an ACK is received. 170 When SCHC-level fragmentation is used, the RTT seen by CoAP depends 171 significantly on the corresponding IPv6 datagram size. CoAP has no 172 visibility of how many fragments are needed to carry the datagram. 173 Therefore, simple RTO schemes may be inaccurate if CON messages have 174 a variable size. Such inaccuracy may lead to either too long RTO 175 values (involving unnecessarily large delay) or too short ones 176 (leading to spurious retries, which may consume scarce transmission 177 resources). 179 In contrast, CoAP-level blockwise transfers may exploit the per-block 180 RTT samples, as in fact, each block is carried by a CoAP message, and 181 retries are carried out message-wise. Therefore CoAP blockwise 182 transfers will result in accurate RTT estimation (as long as an 183 adaptive RTO scheme based on RTT samples is used). 185 Whether the better RTO accuracy of CoAP blockwise transfers may 186 compensate the advantages of SCHC fragmentation (i.e. lower header 187 overhead, better support for payload size constrained L2 188 technologies, richer reliability approaches) needs to be determined 189 by means of further study. Note that this open question does not 190 apply for CoAP NON messages. 192 7. Security Considerations 194 TBD 196 8. Acknowledgments 198 Carles Gomez has been funded in part by the Spanish Government 199 (Ministerio de Ciencia, Innovacion y Universidades) through the Jose 200 Castillejo grant CAS18/00170 and by European Regional Development 201 Fund (ERDF) and the Spanish Government through project 202 TEC2016-79988-P, AEI/FEDER, UE. His contribution to this work has 203 been carried out during his stay as a visiting scholar at the 204 Computer Laboratory of the University of Cambridge. 206 9. References 208 9.1. Normative References 210 [I-D.ietf-lpwan-ipv6-static-context-hc] 211 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 212 Zuniga, "Static Context Header Compression (SCHC) and 213 fragmentation for LPWAN, application to UDP/IPv6", draft- 214 ietf-lpwan-ipv6-static-context-hc-21 (work in progress), 215 July 2019. 217 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 218 Communication Layers", STD 3, RFC 1122, 219 DOI 10.17487/RFC1122, October 1989, 220 . 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, 224 DOI 10.17487/RFC2119, March 1997, 225 . 227 9.2. Informative References 229 [I-D.ietf-core-cocoa] 230 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 231 "CoAP Simple Congestion Control/Advanced", draft-ietf- 232 core-cocoa-03 (work in progress), February 2018. 234 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 235 Application Protocol (CoAP)", RFC 7252, 236 DOI 10.17487/RFC7252, June 2014, 237 . 239 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 240 the Constrained Application Protocol (CoAP)", RFC 7959, 241 DOI 10.17487/RFC7959, August 2016, 242 . 244 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 245 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 246 Application Protocol) over TCP, TLS, and WebSockets", 247 RFC 8323, DOI 10.17487/RFC8323, February 2018, 248 . 250 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 251 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 252 . 254 Authors' Addresses 256 Carles Gomez 257 UPC 258 C/Esteve Terradas, 7 259 Castelldefels 08860 260 Spain 262 Email: carlesgo@entel.upc.edu 264 Jon Crowcroft 265 University of Cambridge 266 JJ Thomson Avenue 267 Cambridge, CB3 0FD 268 United Kingdom 270 Email: jon.crowcroft@cl.cam.ac.uk