[core] Re: CoAP message aggregation (over BP, and perhaps other transports)

[Carsten Bormann <[e-mail]>]

On 2024-06-18, at 11:29, Carles Gomez Montenegro <carles.gomez=[e-mail]> wrote:

[…]
> 
> In IETF 119, while presenting the CoAP over BP draft [1] in the DTN WG session, the idea of aggregating several CoAP messages over a single bundle was suggested by Joshua Deaton (thanks!). As long as the additional aggregation delay can be tolerated, the idea can be useful to reduce protocol overhead.
> 
> If there is interest to support CoAP message aggregation over BP, perhaps a more general mechanism, not necessarily dependent on BP, might be interesting, as it might be used over other transports (e.g., UDP) as well.
> 
> One way to enable CoAP message aggregation over BP would be the approach in Appendix A.2 of [2], which (in the context of CoAP message aggregation over UDP) proposes using a new CoAP option, called Payload-Length option, to delimit the payload of each aggregated message.

That document turns 10 years this year!
For me, it has been pretty much superseded by the framing approach in RFC 8323, as in:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Len  |  TKL  | Extended Length (if any, as chosen by Len) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Code     | Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: CoAP Frame for Reliable Transports

(Nothing in this format limits its applicability to reliable transports only; it really is about delimiting CoAP frames in a larger stream of bytes.)

> What would be your thoughts about reprising work such as [3] and/or enabling CoAP message aggregation over several possible transports?

Can we do something based on RFC 8323 here?

Grüße, Carsten