Fragmentation in LPWAN considerations: CoAP Block vs SCHC fragmentation
draft-gomez-frag-lpwan-considerations-00

Abstract

The SCHC adaptation layer provides header compression and fragmentation functionality between IPv6 and an underlying LPWAN technology. SCHC fragmentation has been specifically designed for the characteristics of LPWANs. However, when CoAP is used at the application layer, there exists an alternative approach for fragmentation, which is using the CoAP Block option. This document aims at illustrating the advantages and limitations of each approach for transferring larger payloads.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 28, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions used in this document
• 3. Header overhead
• 4. L2 MTU supported
• 5. Reliability modes
• 6. CoAP RTO calculation
• 7. Security Considerations
• 8. Acknowledgments
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

The Static Context Header Compression and fragmentation (SCHC) framework provides an adaptation layer that has been specifically designed to enable support of IPv6 over Low Power Wide Area Network (LPWAN) technologies [I-D.ietf-lpwan-ipv6-static-context-hc]. SCHC comprises header compression and fragmentation functionality. The latter is needed when SCHC is used over technologies such as LoRaWAN or Sigfox [RFC8376], and might be needed over further LPWAN technologies.

On the other hand, considering the significant resource constraints in many LPWAN scenarios, the Constrained Application Protocol (CoAP) is a suitable candidate application-layer protocol for use in LPWAN. CoAP has been specified over both UDP and TCP [RFC7252][RFC8323]. For CoAP over UDP, the Block option can be used in order to perform application-layer fragmentation [RFC7959]. In this document, CoAP over UDP is assumed.

Therefore, when CoAP and SCHC are used in LPWAN, there exist two possible approaches for fragmentation: SCHC-level fragmentation and CoAP-level fragmentation. This document aims at systematically analyzing the characteristics, advantages and limitations of both approaches.

2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Header overhead

The SCHC specification defines a fragmentation header that is prepended to each fragment. The SCHC fragmentation header has been defined in a flexible way, yet with the aim to enable very short fragmentation header sizes. Fragmentation header sizes are then actually specified per LPWAN technology in corresponding SCHC-over-foo documents. Fragmentation header sizes of 1-2 bytes are currently being used over technologies such as Sigfox or LoRaWAN. When SCHC fragmentation is used, each fragment will carry a SCHC fragmentation header. The first fragment will also carry the SCHC compressed IPv6/UDP header, which may have a size of 1 byte.

When using CoAP blockwise transfers, each block will carry a CoAP header comprising the base header (4 bytes, although perhaps it can be reduced with SCHC CoAP header compression), the option format (2 bytes), the Block option value (1-3 bytes) and the payload marker (1 byte). In addition, each block will be encapsulated in a different IPv6 datagram. A SCHC compressed IPv6/UDP header may have a size of 1 byte.

4. L2 MTU supported

Assuming that the L2 word [I-D.ietf-lpwan-ipv6-static-context-hc] of the underlying LPWAN technology is 1 byte, and a SCHC fragmentation header of 1 byte, SCHC fragmentation can support underlying LPWAN technologies with a maximum link layer data unit payload of even only 2 bytes.

The smallest CoAP layer payload size that can be supported with Blockwise transfers is 16 bytes. Note that the whole header overhead, comprising IPv6, UDP and CoAP headers, even when SCHC compression is applied, is added to the CoAP layer payload. While some LPWAN technologies can, at least in some cases, carry a CoAP Block, note that it is not possible with RFC 7959 to transport a CoAP Block over Sigfox (with uplink and downlink L2 MTU values of 12 and 8 bytes, respectively) or over LoRaWAN DR0 in the US band (with an L2 MTU of 11 bytes). Assuming that SCHC header compression is used, CoAP Blockwise transfers can only be supported over technologies with an L2 MTU of at least ~25 bytes.

5. Reliability modes

SCHC offers a gradation of reliability modes: No-ACK, ACK-Always, and ACK-on-Error. In No-ACK there is no feedback from the receiver to the sender, and there is no retransmission of fragments. In ACK-Always, the receiver inconditionally generates an ACK after a window of fragments. In ACK-on-Error, the receiver only generates an ACK after a window of fragments if at least one of the fragments of the window has been lost (an exception to this behavior is the last window, for which an ACK-Always behavior is used). Note that each mode involves a different message overhead.

CoAP blockwise transfers follow a stop-and-wait behavior by default. Note that congestion control defined in the basic CoAP specification applies, and NON messages are not very useful in blockwise transfers, as they increase the probability of non-delivery [RFC 7959].

6. CoAP RTO calculation

CoAP CON messages require an Acknowledgment (ACK) by the receiving endpoint. After sending a CON message, a sender waits for such ACK for Retransmission TimeOut (RTO) time. Upon RTO expiration, the CoAP sender retransmits the message. The CoAP main specification does not define a mechanism for adaptively calculating the RTO based on the Round Trip Time (RTT). However, it is expected that future specifications will do so [I-D.ietf-core-cocoa]. The RTT comprises the time since the CoAP CON message is passed to its lower layer until an ACK is received.

When SCHC-level fragmentation is used, the RTT seen by CoAP depends significantly on the corresponding IPv6 datagram size. CoAP has no visibility of how many fragments are needed to carry the datagram. Therefore, simple RTO schemes may be inaccurate if CON messages have a variable size. Such inaccuracy may lead to either too long RTO values (involving unnecessarily large delay) or too short ones (leading to spurious retries, which may consume scarce transmission resources).

In contrast, CoAP-level blockwise transfers may exploit the per-block RTT samples, as in fact, each block is carried by a CoAP message, and retries are carried out message-wise. Therefore CoAP blockwise transfers will result in accurate RTT estimation (as long as an adaptive RTO scheme based on RTT samples is used).

Whether the better RTO accuracy of CoAP blockwise transfers may compensate the advantages of SCHC fragmentation (i.e. lower header overhead, better support for payload size constrained L2 technologies, richer reliability approaches) needs to be determined by means of further study. Note that this open question does not apply for CoAP NON messages.

7. Security Considerations

TBD

8. Acknowledgments

Carles Gomez has been funded in part by the Spanish Government (Ministerio de Ciencia, Innovacion y Universidades) through the Jose Castillejo grant CAS18/00170 and by European Regional Development Fund (ERDF) and the Spanish Government through project TEC2016-79988-P, AEI/FEDER, UE. His contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses