[Dtls-iot] FW: [dice] #36 (profile): Appendix C. DTLS Fragmentation -- Not complete?

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

On 22/07/2015 10:02, "dice issue tracker" <[e-mail]> wrote:
>#36: Appendix C.  DTLS Fragmentation -- Not complete?
>
>Comment (by [e-mail]):
>
> We had a further round of reviews from Robert and Matthias (thanks!).
>
> The email exchange, together with the new text, is copied below.
>
> ----
>
> From: <[e-mail]> on behalf of Robert Cragie
> <[e-mail]>
> Reply-To: "[e-mail]" <[e-mail]>
> Date: Wednesday, 22 July 2015 00:27
> To: Thomas Fossati <[e-mail]>
> Cc: Thomas Fossati <[e-mail]>, Kovatsch Matthias
> <[e-mail]>, Hannes Tschofenig <[e-mail]>
> Subject: Re: DICE ticket #36
>
> Hi Thomas - looks good!
>
> Robert
>
> On 21 Jul 2015 19:44, "FOSSATI, Thomas (Thomas)" <thomas.fossati@alcatel-
> lucent.com> wrote:
> Hi Robert, thanks very much for the comments.
>
> I've removed any reference to specific network technologies because
> fragment size adjustments and consequent overlaps happen whenever we go
> from a bigger to a smaller MTU (e.g. 1500 -> 1280).  Here's the new text:
>
> =-=-=-=
>
>    Section 4.2.3 of [RFC6347] advises DTLS implementations to not
>    produce overlapping fragments.  However, it requires receivers to be
>    able to cope with them.  The need for the latter requisite is
>    explained in Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU)
>    estimation may be traded for shorter handshake completion time.
>
>    In many cases, the cost of handling fragment overlaps has proved to
>    be unaffordable for constrained implementations, particularly because
>    of the increased complexity in buffer management.
>
>    In order to reduce the likelihood of producing different fragment
>    sizes and consequent overlaps within the same handshake, this
>    document RECOMMENDs:
>
>    o  clients (handshake initiators) to use reliable PMTU information for
> the intended destination;
>
>    o  servers to mirror the fragment size selected by their clients.
>
>    The PMTU information comes either from a "fresh enough" discovery
>    performed by the client ([RFC1981], [RFC4821]), or from some other
>    reliable out-of-band channel.
>
> =-=-=-=
>
> Cheers, t
>
> From: <[e-mail]> on behalf of Robert Cragie
> <[e-mail]>
> Reply-To: "[e-mail]" <[e-mail]>
> Date: Tuesday, 21 July 2015 17:18
> To: Thomas Fossati <[e-mail]>
> Cc: Kovatsch Matthias <[e-mail]>, Thomas Fossati
> <[e-mail]>, Hannes Tschofenig <[e-mail]>
> Subject: Re: DICE ticket #36
>
> A couple of points:
>
> Point 1:
>
> "the cost on the constrained implementation in terms of memory (due to
>re-
> buffering) and latency (due to re-transmission) would be much higher than
> the benefit that it would get from a theoretically shorter handshake."
>
> I presume this means "the cost from assuming an infeasibly large MTU..."?
> Maybe this should be made clear.
>
> Point 2:
>
> If IEEE 802.15.4 is being used, 6LoWPAN is the only shim available and
> fragmentation would occur at the 6LoWPAN shim. This means that the MTU is
> effectively 1280. So for that reason, I would probably take out IEEE
> 802.15.4. Also, I believe that BT Smart also does its own fragmentation
> and reassembly in the L2CAP layer so I presume the same would apply to BT
> Smart (although I am not an expert).
>
> Robert
>
>
>
> On 21 July 2015 at 13:56, FOSSATI, Thomas (Thomas) <thomas.fossati
> @alcatel-lucent.com> wrote:
> On 21/07/2015 14:38, "Kovatsch  Matthias" <[e-mail]> wrote:
> >>Good feedback, thanks very much!  Just to avoid any ambiguity: PMTU
> >> doesn't need to be done before each DTLS handshake.  It could be done
> >> once and the information cached for as long as it's reasonable.
> >
> >Yes, that's what I assumed. I was even thinking about adding this
> >information to the draft. And since you clarified this here, I now think
> >it would be best to also put this reminder into the document :)
>
> I agree it's worth a further editorial pass :-)
>
> >> I've slightly re-written the text to match your suggestion:
> >
> >Sounds good.
> >
> >Ciao
> >Matthias
>
>-- 
>-------------------------------------+------------------------------------
>-
> Reporter:                           |       Owner:  draft-ietf-dice-
>  [e-mail]          |  [e-mail]
>     Type:  defect                   |      Status:  new
> Priority:  major                    |   Milestone:
>Component:  profile                  |     Version:
> Severity:  Waiting for Shepherd     |  Resolution:
>  Writeup                            |
> Keywords:                           |
>-------------------------------------+------------------------------------
>-
>
>Ticket URL: <http://trac.tools.ietf.org/wg/dice/trac/ticket/36#comment:2>
>dice <http://tools.ietf.org/dice/>