One document matched: draft-gomez-lwig-tcp-constrained-node-networks-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no"?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="bcp" docName="draft-gomez-lwig-tcp-constrained-node-networks-01"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="TCP over CNNs">
TCP over Constrained-Node Networks
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Carles Gomez" initials="C.G" surname="Gomez">
<organization>UPC/i2CAT</organization>
<address>
<postal>
<street>C/Esteve Terradas, 7</street>
<city>Castelldefels</city>
<region/>
<code>08860</code>
<country>Spain</country>
</postal>
<phone/>
<facsimile/>
<email>carlesgo@entel.upc.edu</email>
<uri/>
</address>
</author>
<author fullname="Jon Crowcroft" initials="J.C" surname="Crowcroft">
<organization>University of Cambridge</organization>
<address>
<postal>
<street>JJ Thomson Avenue</street>
<city>Cambridge</city>
<region>CB3 0FD</region>
<code/>
<country>United Kingdom</country>
</postal>
<phone/>
<facsimile/>
<email>jon.crowcroft@cl.cam.ac.uk</email>
<uri/>
</address>
</author>
<!-- uri and facsimile elements may also be added -->
<date month="October" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>APP</area>
<workgroup>LWIG Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!---->
<abstract>
<t> This document provides a profile for the Transmission Control Protocol (TCP) over Constrained-Node Networks (CNNs). The overarching goal is to offer simple measures to allow for lightweight TCP implementation and suitable operation in such environments.
</t>
</abstract>
</front>
<middle>
<section title="Introduction ">
<t>The Internet Protocol suite is being used for connecting Constrained-Node Networks (CNNs) to the Internet, enabling the so-called Internet of Things (IoT) <xref target="RFC7228"/>. In order to meet the requirements that stem from CNNs, the IETF has produced a suite of protocols specifically designed for such environments <xref target="I-D.ietf-lwig-energy-efficient"/>. </t>
<t>At the application layer, the Constrained Application Protocol (CoAP)
was developed over UDP [RFC7252]. However, the integration of some
CoAP deployments with existing infrastructure is being challenged by
middleboxes such as firewalls, which may limit and even block UDP-based
communications. This the main reason why a CoAP over TCP
specification is being developed [I-D.tschofenig-core-coap-tcp-tls].
</t>
<t>On the other hand, other application layer protocols not specifically
designed for CNNs are also being considered for the IoT space. Some
examples include HTTP/2 and even HTTP/1.1, both of which run over TCP
by default [RFC7540][RFC2616], and the Extensible Messaging and Presence Protocol (XMPP) [RFC 6120]. TCP is also used by non-IETF
application-layer protocols in the IoT space such as MQTT and its
lightweight variants [MQTTS].
</t>
<t>This document provides a profile for TCP over CNNs. The overarching goal is to offer simple measures to allow for lightweight TCP implementation and suitable operation in such environments.</t>
<section title="Conventions used in this document">
<t>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 <xref
target="RFC2119"/></t>
</section>
</section>
<section title="Characteristics of CNNs relevant for TCP">
<t>Constrained nodes are characterized by significant limitations on processing, memory, and energy resources <xref target="RFC7228"/>. The first two dimensions pose constraints on the complexity and on the memory footprint of the protocols that constrained nodes can support. The latter requires techniques to save energy, such as radio duty-cycling in wireless devices <xref target="I-D.ietf-lwig-energy-efficient"/>, as well as minimization of the number of messages transmitted/received (and their size).</t>
<t>
Constrained nodes often use physical/link layer technologies that
have been characterized as 'lossy'. Many such technologies are
wireless, therefore exhibiting a relatively high bit error rate.
However, some wired technologies used in the CNN space are also lossy
(e.g. Power Line Communication). Transmission rates of CNN radio or
wired interfaces are typically low (e.g. below 1 Mbps).
</t>
<t>
Some CNNs follow the star topology, whereby one or several hosts are linked to a central device that acts as a router connecting the CNN to the Internet. CNNs may also follow the multihop topology <xref target="RFC6606"/>.</t>
</section>
<section title="Scenario">
<t>
The main scenario for use of TCP over CNNs comprises a constrained
device and an unconstrained device that communicate over the Internet
using TCP, possibly traversing a middlebox (e.g. a firewall, NAT,
etc.). <xref target="fig_scenario"/> illustrates such scenario. Note that the scenario is
asymmetric, as the unconstrained device will typically not suffer the
severe constraints of the constrained device. The unconstrained device
is expected to be mains-powered, to have high amount of memory and
processing power, and to be connected to a resource-rich network.
</t>
<t>
Assuming that a majority of constrained devices will correspond to
sensor nodes, the amount of data traffic sent by constrained devices
(e.g. sensor node measurements) is expected to be higher than the
amount of data traffic in the opposite direction. Nevertheless,
constrained devices may receive requests (to which they may
respond), commands (for configuration purposes and for constrained
devices including actuators) and relatively infrequent
firmware/software updates.
<figure title="TCP communication between a constrained device and an
unconstrained device, traversing a middlebox."
anchor="fig_scenario">
<artwork><![CDATA[
+---------------+
o o <--------- TCP communication ------> | |
o o | |
o o | Unconstrained |
o o +-----------+ | device |
o o o ------ | Middlebox | ------- | |
o o +-----------+ | (e.g. cloud) |
o o o | |
+---------------+
constrained devices
]]></artwork></figure>
</t>
</section>
<section title="TCP over CNNs">
<section title="TCP connection initiation">
<t>
In the constrained device to unconstrained device scenario illustrated
above, a TCP connection is typically initiated by the constrained
device, in order for this device to support possible sleep periods to
save energy.
</t>
</section>
<section title="Maximum Segment Size (MSS)">
<t>Some link layer technologies in the CNN space are characterized by a short data unit payload size, e.g. up to a few tens or hundreds of bytes. For example, the maximum frame size in IEEE 802.15.4 is 127 bytes.
</t>
<t>6LoWPAN defined an adaptation layer to support IPv6 over IEEE 802.15.4 networks. The adaptation layer includes a fragmentation mechanism, since IPv6 requires the layer below to support an MTU of 1280 bytes <xref target="RFC2460"/>, while IEEE 802.15.4 lacked fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes <xref target="RFC4944"/>. Other technologies, such as Bluetooth LE <xref target="RFC7668"/>, ITU-T G.9959 <xref target="RFC7428"/> or DECT-ULE <xref target="I-D.ietf-6lo-dect-ule"/>, also use 6LoWPAN-based adaptation layers in order to enable IPv6 support. These
technologies do support link layer fragmentation. By exploiting this
functionality, the adaptation layers that enable IPv6 over such
technologies also define an MTU of 1280 bytes.
</t>
<t>For devices using technologies with a link MTU of 1280 bytes (e.g.
defined by a 6LoWPAN-based adaptation layer), in
order to avoid IP layer fragmentation, the TCP MSS must not be set
to a value greater than 1220 bytes in CNNs. (Note: IP version 6 is
assumed.) In any case, the TCP MSS must not be set to a value
leading to an IPv6 datagram size exceeding 1280 bytes.
</t>
<t>
If a link layer technology used by a constrained device offers a link
layer MTU greater than 1280 bytes, it is still useful to set the MSS so
that IPv6 datagram size does not exceed 1280 bytes, in order to
avoid issues due to Internet links that do not support greater MTUs.
</t>
</section>
<section title="Window Size">
<t>This document recommends that constrained devices advertise a TCP
window size of one MSS, and also transmit at most one MSS of
unacknowledged data.
This value for receive and send window is appropriate for simple message exchanges in
the CNN space, reduces implementation complexity and memory
requirements, and reduces overhead (see section 4.7).
</t>
<t>A TCP window size of one MSS follows the same rationale as the default setting for NSTART in <xref target="RFC7252"/>, leading to equivalent operation when CoAP is used over TCP. </t>
<t>For devices that can afford greater TCP window size, it may be useful
to use window sizes of at least five MSSs, in order to allow Fast
Retransmit and Fast Recovery <xref target="RFC5681"/>.</t>
</section>
<section title="RTO estimation">
<t>Traditionally, TCP has used the well known RTO estimation algorithm defined in <xref target="RFC6298"/>. However, experimental studies have shown that another algorithm such as the RTO estimator defined in <xref target="I-D.ietf-core-cocoa"/> (hereinafter, CoCoA RTO) outperforms state-of-art algorithms designed as improvements to RFC 6298 for TCP, in terms of packet delivery ratio, settling time after a burst of messages, and fairness (the latter is specially relevant in multihop networks connected to the Internet through a single device, such as a 6LoWPAN Border Router (6LBR) configured as a RPL root) <xref target="Commag"/>. In fact, CoCoA RTO has been designed specifically considering the challenges of CNNs, in contrast with the RFC 6298 RTO.</t>
<t>TBD: devise approaches for use of CoCoA for TCP by constrained devices,
as currently its use would conflict with several TCP MUSTs (RFC 6298,
Karn algorithm, etc.). If the unconstrained device is dedicated for
communication with constrained devices, CoCoA would be suitable as
well.</t>
</section>
<section title="TCP connection lifetime">
<section title="Long TCP connection lifetime">
<t>In CNNs, in order to minimize message overhead, a TCP connection should
be kept open as long as the two TCP endpoints have more data to
exchange or it is envisaged that further segment exchanges will take
place within an interval of two hours since the last segment has been
sent. A greater interval may be used in scenarios where applications
exchange data infrequently.</t>
<t>TCP keep-alive messages <xref target="RFC1122"/> may be supported by a server, to check whether a TCP connection is active, in order to release state of inactive connections. This may be useful for servers running on memory-constrained devices. </t>
<t>Since the keep-alive timer may not be set to a value lower than two hours <xref target="RFC1122"/>, TCP keep-alive messages are not useful to guarantee that filter state records in middleboxes such as firewalls will not be deleted after an inactivity interval typically in the order of a few minutes <xref target="RFC6092"/>. In scenarios where such middleboxes are present, alternative measures to avoid early deletion of filter state records (which might lead to frequent establishment of new TCP connections between the two involved endpoints) include increasing the initial value for the filter state inactivity timers (if possible), and using application layer heartbeat messages. </t>
</section>
<section title="Short TCP connection lifetime">
<t>A different approach to addressing the problem of traversing
middleboxes that perform early filter state record deletion relies on
using TCP Fast Open (TFO) <xref target="RFC7413"/>. In this case, instead of trying
to maintain a TCP connection for long time, possibly short-lived
connections can be opened between two endpoints while incurring low
overhead. In fact, TFO allows data to be carried in SYN (and SYN-ACK)
packets, and to be consumed immediately by the receceiving endpoint,
thus reducing overhead compared with the traditional three-way
handshake required to establish a TCP connection.</t>
<t>For security reasons, TFO requires the TCP
endpoint that will open the TCP connection (which in CNNs will
typically be the constrained device) to request a cookie from the
other endpoint. The cookie, with a size of 4 or 16 bytes, is then
included in SYN packets of subsequent connections. The cookie needs to
be refreshed (and obtained by the client) after a certain amount of
time. Nevertheless, TFO is more efficient than frequently opening new
TCP connections (by using the traditional three-way handshake) for
transmitting new data, as long as the cookie update rate is well below
the data new connection rate.</t>
</section>
</section>
<section title="Explicit congestion notification">
<t>Explicit Congestion Notification (ECN) <xref target="RFC3168"/> may be used in CNNs. ECN allows a router to signal in the IP header of a packet that congestion is arising, for example when queue size reaches a certain threshold. If such a packet encapsulates a TCP data packet, an ECN-enabled TCP receiver will echo back the congestion signal to the TCP sender by setting a flag in its next TCP ACK. The sender triggers congestion control measures as if a packet loss had happened. In that case, when the congestion window of a TCP sender has a size of one segment, the TCP sender resets the retransmit timer, and will only be able to send a new packet when the retransmit timer expires <xref target="RFC3168"/>. Effectively, the TCP sender reduces at that moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 segment per default RTO.</t>
<t>ECN can reduce packet losses, since congestion control measures can be applied earlier than after the reception of three duplicate ACKs (if the TCP sender window is large enough) or upon TCP sender RTO expiration <xref target="RFC2884"/>. Therefore, the number of retries decreases, which is particularly beneficial in CNNs, where energy and bandwidth resources are typically limited. Furthermore, latency and jitter are also reduced. </t>
<t>ECN is particularly appropriate in CNNs, since in these environments
transactional type interactions are a dominant traffic pattern. As
transactional data size decreases, the probability of detecting
congestion by the presence of three duplicate ACKs decreases. In
contrast, ECN can still activate congestion control measures without
requiring three duplicate ACKs.
</t>
</section>
<section title="TCP options">
<t>A TCP implementation needs to support options 0, 1 and 2 [RFC793].
A TCP implementation for a constrained device that uses a single-MSS
TCP receive or transmit window size will benefit from not supporting, and ignoring if
received, the following TCP options: Window scale <xref target="RFC1323"/>, TCP Timestamps <xref target="RFC1323"/>, Selective Acknowledgements (SACK) and SACK-Permitted <xref target="RFC2018"/>. Other TCP options SHOULD NOT be used, in keeping with the principle of lightweight operation. </t>
<t>Other TCP options should not be supported by a constrained device, in
keeping with the principle of lightweight implementation and operation.</t>
<t>If a device, with less severe memory and processing constraints, can afford advertising a TCP window size of several MSSs, it may support the SACK option to improve performance. SACK allows
a data receiver to inform the data sender of non-contiguous data blocks
received, thus a sender (having previously sent the SACK-Permitted
option) can avoid performing unnecessary
retransmissions, saving energy and bandwidth, as well as reducing
latency. The receiver supporting SACK will need to manage the
reception of possible out-of-order received segments, requiring
sufficient buffer space.</t>
<t>SACK adds 8*n+2 bytes to the TCP header, where n denotes the number
of data blocks received, up to 4 blocks. For a low number of out-of-
order segments, the header overhead penalty of SACK is compensated by
avoiding unnecessary retransmissions.
</t>
</section>
<section title="Delayed Acknowledgments">
<t>
A device that advertises a single-MSS receive window needs to avoid use of delayed ACKs in order to avoid contributing unnecessary delay (of up to 500 ms) to the RTT <xref target="RFC5681"/>.
</t>
<t>
Since traffic over CNNs is expected to be mostly of transactional type, with transaction size typically below one MSS, delayed ACKs are not recommended for TCP over CNNs. (Note: delayed ACKs could be useful to reduce the number of ACKs in bulk transfer type of traffic, e.g. for firmware/software updates; however, it is assumed that these will be infrequent in comparison with transactional type exchanges.)
</t>
</section>
<section title="Explicit loss notifications">
<t>There has been a significant body of research on solutions capable of explicitly indicating whether a TCP segment loss is due to corruption, in order to avoid activation of congestion control mechanisms <xref target="ETEN"/> <xref target="RFC2757"/>. While such solutions may provide significant improvement, they have not been widely deployed and remain as experimental work. In fact, as of today, the IETF has not standardized any such solution. </t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>If TFO is used, the security considerations of RFC 7413 apply.</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="ACKs" title="Acknowledgments">
<t>Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336. Part of 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.</t>
<t> The authors appreciate the feedback received for this document. The
following folks provided comments that helped improve the document:
Carsten Bormann, Zhen Cao, Wei Genyu, Michael Scharf, Ari Keranen,
Abhijan Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe
Touch, Fred Baker, Nik Sultana, Simon Brummer. </t>
</section>
<section title="Annex. TCP implementations for constrained devices">
<t>This section overviews the main features of TCP implementations for constrained devices.</t>
<section title="uIP">
<t>uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers. uIP has been deployed with Contiki and the Arduino Ethernet shield. A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) has been reported for uIP <xref target="Dunk"/>.</t>
<t>uIP provides a global buffer for incoming packets, of single-packet size. A buffer for outgoing data is not provided. In case of a retransmission, an application must be able to reproduce the same packet that had been transmitted.</t>
<t>The MSS is announced via the MSS option on connection establishment and the receive window size (of one MSS) is not modified during a connection. Stop-and-wait operation is used for sending data. Among other optimizations, this allows to avoid sliding window operations, which use 32-bit arithmetic extensively and are expensive on 8-bit CPUs.</t>
</section>
<section title="lwIP">
<t>lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. lwIP has a total code size of ~14 kB to ~22 kB (which comprises memory management, checksumming, network interfaces, IP, ICMP and TCP), and a TCP code size of ~9 kB to ~14 kB <xref target="Dunk"/>.</t>
<t>In contrast with uIP, lwIP decouples applications from the network stack. lwIP supports a TCP transmission window greater than a single segment, as well as buffering of incoming and outcoming data. Other implemented mechanisms comprise slow start, congestion avoidance, fast retransmit and fast recovery. SACK and Window Scale are not implemented.</t>
</section>
<section title="RIOT">
<t> TBD </t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include='reference.RFC.1122.xml'?>
<?rfc include='reference.RFC.1323.xml'?>
<?rfc include='reference.RFC.2018.xml'?>
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.2460.xml'?>
<?rfc include='reference.RFC.2616.xml'?>
<?rfc include='reference.RFC.2884.xml'?>
<?rfc include='reference.RFC.2757.xml'?>
<?rfc include='reference.RFC.3168.xml'?>
<?rfc include='reference.RFC.4944.xml'?>
<?rfc include='reference.RFC.5681.xml'?>
<?rfc include='reference.RFC.6092.xml'?>
<?rfc include='reference.RFC.6298.xml'?>
<?rfc include='reference.RFC.6606.xml'?>
<?rfc include='reference.RFC.7228.xml'?>
<?rfc include='reference.RFC.7252.xml'?>
<?rfc include='reference.RFC.7413.xml'?>
<?rfc include='reference.RFC.7428.xml'?>
<?rfc include='reference.RFC.7540.xml'?>
<?rfc include='reference.RFC.7668.xml'?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include='reference.I-D.ietf-lwig-energy-efficient'?>
<?rfc include='reference.I-D.ietf-6lo-dect-ule'?>
<?rfc include='reference.I-D.tschofenig-core-coap-tcp-tls'?>
<?rfc include='reference.I-D.ietf-core-cocoa'?>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<reference anchor="Commag">
<front>
<title>CoAP Congestion Control for the Internet of Things</title>
<author>
<organization>A. Betzler, C. Gomez, I. Demirkol, J. Paradells</organization>
</author>
<date year="2016" month="IEEE Communications Magazine, June"/>
</front>
</reference>
<reference anchor="ETEN">
<front>
<title>Explicit transport error notification (ETEN) for error-prone wireless and satellite networks</title>
<author>
<organization>R. Krishnan et al </organization>
</author>
<date year="2004" month="Computer Networks"/>
</front>
</reference>
<reference anchor="MQTTS">
<front>
<title>MQTT-S: A Publish/Subscribe Protocol For
Wireless Sensor Networks</title>
<author>
<organization>U. Hunkeler, H.-L. Truong, A. Stanford-Clark </organization>
</author>
<date year="2008"/>
</front>
</reference>
<reference anchor="Dunk">
<front>
<title>Full TCP/IP for 8-Bit Architectures</title>
<author>
<organization>A. Dunkels </organization>
</author>
<date year="2003"/>
</front>
</reference>
</references>
<!-- -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 20:51:40 |