is it possible to preserve packet lengths with streamsend

[timprepscius]

I'm guessing the answer is "it is a stream, not a set of packets." - but:

Currently if I streamsend packets of length:
1, 2, 3, 4, 5 immediately one right after another

I get a single packet of 15.

Is there a way within quic (I can do it myself of course), that I can get the original packets out?
(but of course have the coalescing during send for efficiency)

[nibanks]

Nope. Just like a single TCP connection, each QUIC stream is a continuous stream of bytes where each app send is independent of the corresponding receive on the peer side. If you need to have logic splits between different sends, you need some app layer "protocol" to specify that split explicitly.

[nibanks]

No, there are no guarantees around coalescing for any feature. For instance, if you send two 100 byte datagrams, even with some time between them, but the connection was currently network limited (congestion control), it's entirely possible that the two datagram frames might be put into the same QUIC packet once the network can handle the traffic.

[timprepscius]

Interesting- thanks for this.

[ThadHouse]

You will get 2 separate indications at the app layer, 1 per datagram. They just might come 1 right after the other, as they might be in the same packet at the quic layer. There is no ordering guarantees or even arrival guarantees around these events however.

[timprepscius]

One minor clarification.

Am I guaranteed that if I send an unreliable packet (which is sized < MTU), that it will arrive in the same packet.

For instance, let's say quic-MTU is 16.
Let's say I send packets size 10, 5, 5.

Am I guaranteed the last packet will not span two packets?

[nibanks]

Correct. We will never segment a single datagram frame into two different QUIC packet. This also means you cannot send a datagram that is larger than MTU.