Subject: [TLS] DTLS retransmit question

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 01 Oct 2014 00:58:42 +0200

Hi all,

I'm having trouble interpreting some text from RFC 6347 section 4.2.4:

                           Although each flight of messages may consist
   of a number of messages, they should be viewed as monolithic for the
   purpose of timeout and retransmission.

   [...]

   There are three ways to exit the WAITING state:
   [...]
   2. The implementation reads a retransmitted flight from the peer: the
      implementation transitions to the SENDING state, [...]

Does that mean an implementation is supposed to transition from WAITING
to SENDING only when it reads the retransmission of a whole flight?
Since the underlying transport is not reliable, one of the messages of
the retransmitted flight might get lost: should that prevent from
retransmitting in return?

An option would be to retransmit as soon as a retransmitted message
from the last flight is seen, but that would result in one
retransmission per received message in the flight retransmitted by the
peer, which would result in a lot of probably useless retransmission,
which is bad for congestion.

Another option is to retransmit only when a retransmission of the last
message of the previous flight is seen, which results in less
retransmissions and is a bit less sensitive to message loss than
checking for the whole flight. It's also easier to implement (especially
for the flight containing the Finished message, since messages from
previous epochs can then be dropped by the record layer). This is
currently my preferred option, I think.

Any clarification of the intention of the RFC, or sensible advice on
what to do, would be appreciated.

Thanks,
Manuel.