Subject: [Dtls-iot] Fragmentation, overlapping, and PMTU handling (ticket #23)

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Thu, 18 Dec 2014 11:27:47 +0000

Hi all,

we have have been pondering about how to turn the comments received so far into a set of recommendations on how to avoid fragments overlapping.

Reading through the DTLS spec there are two points re: fragmentation, overlapping and PMTU handling:

  1.  https://tools.ietf.org/html/rfc6347#section-4.2.3 "Handshake Message Fragmentation and Reassembly"
     *   "When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges. [...] The ranges SHOULD NOT overlap."
     *   "DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes."
  2.  https://tools.ietf.org/html/rfc6347#section-4.1.1.1 "PMTU Issues"
     *    "[...] the handshake protocol PMTU handling places a premium on rapid completion over accurate PMTU discovery".

Combining the two together: it looks like the problematic 1.2 (that Matthias would like to drop) exists only to allow the "casual" PMTU discovery during handshake hinted in 2.1.

Maybe one simple thing that we could recommend to reduce the likelihood of producing different fragment sizes (and consequent overlaps) is:

  *   for clients, (handshake initiators), to perform PMTU discovery towards the server accurately *before* handshake starts, and not rely on any a-priori guess (unless the network path characteristics are known OOB);
  *   for servers, to mirror the fragment size selected by their clients.

We don't think the document should suggest a one-size-fits-all value (i.e. Robert's suggestion about using the typical 1280 bytes MTU), because if you have to go through a 6lowPAN or other narrow band bearers then it's going to be problematic.

We are aware that this "know your PMTU" suggestion is a bit lame (but that's it, we really can't change DTLS here), so if you have better ideas please shout — maybe even saying that the topic should be dropped due to lack of useful guidance and moved completely to LWIG.

(We plan to submit -08 tomorrow.)

Cheers, t