I hope they eventually add a extension to support configurable bounds on allowed fragmentation. There is not really a good way to create a non-allocating fixed

I hope they eventually add a extension to support configurable bounds on allowed fragmentation. There is not really a good way to create a non-allocating fixed upper-bound memory implementation in the presence of worst-case fragmentation except with high overhead. You can kind of do it by maintaining a bitmap indicating received bytes, but that incurs overhead of 1/8 your advertised stream data limit/buffering size. If you could configure a stream to have a minimum alignment for the stream frame Offset field then you can reduce that quite dramatically without materially impacting the amount of frames you could pack into a packet. For instance, just going to a 16-byte alignment only requires order of 1/128 overhead which is probably fine for most constrained implementations. You do not even need to make the stream frame Length field a multiple of the alignment allowing you to support trailing non-aligned data. All that would happen is that when the stream has more data to send you would need to resend the trailing piece, but the extra channel bandwidth needed for that is bounded to the configured alignment.