Subject: Low power deep sleep pattern

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 30 Jun 2019 12:45:45 -0700

Consider a scenario where a small IoT device is able to store its state in
flash and go to deep sleep for a while.

When it wakes up it wants to transmit some data and process inbound
messages.
It does not want to spend time or power on establishing a new connection
and 0-RTT is not ideal for several reasons: it requires a roundtrip before
data are reliable and most connection state is lost and must be
renegotiated.

QUIC has a potentially long idle timeout so it could deal with a device
that is waking up.
One problem may be how retransmission is handled - will the peer be
tolerant to a 1 minute delay before seeing an ACK?

Another problem is middleboxes. While not solveable in general, it might be
worth considering to offer a signal that indicates that the usual timeouts
do not apply - the IP might not even be the same if a DHCP server assigns a
new IP on wakeup, but it still has the CID.

Mikkel

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 1 Jul 2019 00:31:36 +0300

On Sun, Jun 30, 2019 at 10:46 PM Mikkel Fahnøe Jørgensen
<[email-masked]> wrote:
> Consider a scenario where a small IoT device
> is able to store its state in flash and go to deep
> sleep for a while.
>
> When it wakes up it wants to transmit some
> data and process inbound messages..
> It does not want to spend time or power on
> establishing a new connection and 0-RTT is
> not ideal for several reasons: it requires a
> roundtrip before data are reliable and most
> connection state is lost and must be
> renegotiated.

This is — and always was — a complicated scenario for datagram-based
protocols.  It was even discussed with regards to DTLS a couple of
times before.

IIRC such a behaviour has always been left up to implementations
because advising for any hard-coded decisions here could be seen as
advocating for bad designs.  E.g. what if your device was intended to
sleep for a minute but suffered a power outage and went live a month
later instead, and the peer certificate might have expired or been
revoked — how are you going to check this if you're just "un-freezing"
a session from flash?  Session renegotiation/resumption was always
meant to be used for those cases.

(I'm personally not going to say though that this will actually
*prevent* bad designs in IoT — in fact, quite the opposite.)

> QUIC has a potentially long idle timeout

Do you mean "potentially infinite"?  Yes, this is how it's probably
going to be used in embedded code.
https://github.com/quicwg/base-drafts/pull/1765

--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 1 Jul 2019 00:44:57 +0300

On Sun, Jun 30, 2019 at 10:46 PM Mikkel Fahnøe Jørgensen
<[email-masked]> wrote:
> Another problem is middleboxes. While not
> solveable in general, it might be worth
> considering to offer a signal that indicates
> that the usual timeouts do not apply

That's a signal to whom?  Generic middleboxes are unlikely to ever
consider respecting such a signal, b/c of limited RAM if not anything
else.

For the peer, the infinite idle timeout negotiated (together with
application-specific details, known to the application developers, of
the protocol running on top of QUIC or HTTP/3) should be a signal in
itself I think.  Usually, you don't expect IoT devices to land on the
same app gateways as browsers do, so that's a distinction to be made
infrastructure-wise, not protocol-wise.

--
Töma

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 30 Jun 2019 14:51:59 -0700

I’m not so much concerned with the path towards the app gateway, but the
last/first mile with a shady wlan router, or whatever.
I don’t expect most of these to be useful, but if there is a signal, there
is a market for routers that can deal with this.
Today UDP NAT is far too short lived. That is likely to change, but IoT
might happen later. A signal would help in that regard.

Further inland, the CID might get invalidated over a period of hours or
days, no one really knows. But I imagine a device will
wake up periodically, like every 1-60 minutes, but not more often, since
that might make deep sleep inefficient, and/or require someone to take a
hike with a new battery a bit too often.

Hence, the CID liveness is not really a concern, again, those in the market
of supporting these thing will make allowances.

On 30 June 2019 at 23.45.13, Töma Gavrichenkov ([email-masked]) wrote:

-- 
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 1 Jul 2019 01:29:44 +0300

On Mon, Jul 1, 2019 at 12:52 AM Mikkel Fahnøe Jørgensen
<[email-masked]> wrote:
> I’m not so much concerned with the path
> towards the app gateway, but the last/first
> mile with a shady wlan router, or whatever.
>
> I don’t expect most of these to be useful,
> but if there is a signal, there is a market
> for routers that can deal with this.

For all (I'm not even going to beat around the bush with "most of")
the stuff in the middle a timeout is never something optional, it's
only mandatory.  Computational resources are never infinite, so
neither must be timeouts for long-dead sessions, initiated by
long-dead devices — which are sometimes just being replaced along with
their batteries b/c some of those devices appear obsolete even before
they run out of power and it's at times operationally cheaper not to
care about the rest of the boxes in the fleet.

An exception from the rule might be made for a session peer only,
because the latter (hopefully) knows how many clients or devices it's
meant to be handling.  It's still not a perfect design, but it's sort
of acceptable under certain conditions where it's — again,
operationally — cheaper not to care about corner cases.  For a
middlebox, things are much less predictable; it only knows (at best,
even) how many sessions it *could* handle, thus can never allow for an
infinite session data storage while being otherwise reliable.

> Today UDP NAT is far too short lived.

I can't really say there's no reason for that.

--
Töma