> On 2. Apr 2021, at 23:46, Rick van Rein <r...@openfortress.nl> wrote: > > Hello, > > I was looking into DTLS/SCTP as a carrier for Diameter. Lengths in > Diameter are 24 bit to avoid ever having to bother about that, but when > run over the preferred DTLS/SCTP carrier this may yet be a concern, so > that its only option is to fallback to a _separate_ TLS/TCP connection: > > * For DTLS over TCP or SCTP, which automatically fragment and > reassemble datagrams, there is no PMTU limitation. However, the > upper layer protocol MUST NOT write any record that exceeds the > maximum record size of 2^14 bytes. > > SCTP can offer better guarantees than UDP; this relaxation may provide > leverage to split a large application message into a sequence of DTLS > frames carried under specific guarantees. > > 1. To handle a larger application message, it is split into pieces > of 2^14 bytes, followed by one that has <2^14 (possibly 0) bytes. > Fragments are sent to the same stream, without interleaving other > content, and in-order. Upon reception, the DTLS frames are each > decoded and the result concatenated to recover the message. Doesn't that results in head of line blocking? > > 2. Since delivery is reliable for SCTP, it would (also) be possible > to send the same sequence number for the fragments. The sequence > number field is not as useful for SCTP as it is for UDP. > > 3. It may be an idea to allocate one stream for all fragmentation. > But even within a stream, it is possible to combine in-order and > out-of-order. It is probably good to continue in-order sending > until the <2^14 sized DTLS frame is acknowledged. The application > or DTLS handshake may further constrain this. > > These are three possible ways of relaxing this. If we pick a simple > one, like the 1st, we might pass more SCTP semantics over to the > application that wants DTLS but not its size constraints. What DTLS > does to Diameter is best resolved. What about using: https://tools.ietf.org/html/draft-westerlund-tsvwg-dtls-over-sctp-bis-01
Best regards Michael > > > I hope this is useful, > > Cheers, > > Rick van Rein > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
