Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach

[Carsten Bormann <[e-mail]>]

>  We have not taken the performance aspect of larger file transfers (e.g.,
>  transfer of a 4MB firmware update) into account when we made the
>  solution decision in Yokohama. The reason why the OIC/OCF take such
>  large file transfers into account is because of their desire to use CoAP
>  also for non-constrained devices.

Actually, we did discuss larger transfers in Yokohama (although the word
"performant" only occurs once in the minutes, specifically where
Matthias reported on the IoTivity work).  The understanding was that an
extension to -block like draft-bormann-core-block-bert would reduce the
performance gap between a 16-bit (L1) and a 32-bit length (L3), if
needed.  The sentiment in the room was a bit against creating a dialect
of CoAP with much larger payload sizes than the ones recommended in
section 4.6 of RFC 7252, but we didn't really have much input on this to
work from.

So this particular question really reduces to:  Should CoAP be extended
to provide payload sizes well over 64 KiB over TCP, TLS?  (The
Websockets framing already provides the capability, up to 16 EiB.)

Grüße, Carsten