Re: [Dtls-iot] AD review of draft-ietf-dice-profile-13

["FOSSATI, Thomas (Thomas)" <[e-mail]>]

Hi Stephen,

On 06/07/2015 17:16, "dtls-iot on behalf of Stephen Farrell"
<[e-mail] on behalf of [e-mail]> wrote:
>(6) 13: sorry I don't get why a 1 second initial timer
>is an issue because messages "need longer" (we're not in
>a DTN, right:-) I don't think you've justified the 10s
>initial value and that might be bad in fact e.g.  for
>sleepy nodes one might want a much shorter initial
>timeout so the node can go back to snoozing.  (It could
>be that this 10s value was justified on the list, but
>I'm not getting it from the text. Or is it appendix A
>you're thinking of? If so, that seems overly specialised
>for a generic 10s recommendation.)

the relevant text is: "[...] these values are too aggressive and lead to
spurious failures when messages in flight need longer." which I reckon is
a bit too terse.

The full story is:
* TLS protocol steps can take longer due to the time spent figuring out
  the crypto bits on the constrained side;
* DTLS retransmission, which is per-flight, interacts very badly with low
  bandwidth networks;
so, it's essential that the probability of a spurious rertansmit is
minimised.

Also, on packet loss, the sending node should not react too aggressively:
if lost packets are re-injected too quickly into a temporarily congested
WSN, congestion worsens.

The 10s is a conservative guess that tries to cater for the worse case
(i.e. very constrained endpoints and/or networks that are congested or
with high delay variance - e.g. GSM-SMS).

Re: sleepy nodes.  Even when starting with a 1s timeout, they need to be
prepared to stay awake for the maximum wait time which is roughly 1
minute.  This is not a MUST, anyway, so sleepy nodes could use a lower
value, both for the initial timer and, most importantly, for the threshold.


I have this new text in my working copy.  (Note I have slightly tweaked
the value -- 10 has become 9 -- to get the same max wait you'd get with
the usual 1s initial timeout):

   TLS protocol steps can take longer due to higher processing time on
   the constrained side.  On the other hand, the way DTLS handles
   retransmission, which is per-flight instead of per-segment, tends to
   interact poorly with low bandwidth networks.

   For these reasons, it's essential that the probability of a spurious
   retransmit is minimized and, on timeout, the sending endpoint does
   not react too aggressively.  The latter is particularly relevant when
   the WSN is temporarily congested: if lost packets are re-injected too
   quickly, congestion worsens.

   An initial timer value of 9 seconds with exponential back off up to
   no less then 60 seconds is therefore RECOMMENDED.

   This value is chosen big enough to absorb large latency variance due
   to either slow computation on constrained endpoints or to intrinsic
   network characteristics (e.g.  GSM-SMS), as well as to produce a low
   number of retransmission events and relax the pacing between them.
   Its worst case wait time is the same as using 1s timeout (i.e. 63s),
   while triggering less then half retransmissions (2 instead of 5).

   In order to minimise the wake time during DTLS handshake, sleepy
   nodes might decide to select a lower threshold, and consequently a
   smaller initial timeout value.  If this is the case, the
   implementation MUST keep into account the considerations about
   network stability described in this section.

How does it sound?

Cheers, t