Clarify refragmenting of stream data when MTU is different and retransmission happens on other path.

[gloinul]

Section 7.6
Is refragmentation of data in DATA frames allowed to cope with PMTUD. Maybe should be mentioned explicitly to ensure that this is not resulting in implementation issues. Sender responsibility?

[mirjak]

refragmentation? When?

[huitema]

Picoquic has been doing refragmentation of retransmitted packets for several years. That is tested in the interop runner, and does not create any particular interop issue. Hey, I think that the code may well split a stream_data_frame in several segments and send the segments over different paths...

[gloinul]

I think it would be good to add some text in the specification that sender MAY do this and receiver MUST be able to accept refragmentation done in retransmissions.

[mirjak]

Why is this different in the multipath case than in RFC9000?

[huitema]

@mirjak exactly. Besides, if the packet was lost, the receiver has not seen the first copy of the frame, so it cannot tell that it is a retransmission. It is a well tested feature of RFC9000.

[gloinul]

I don't think it is different. It is just more likely to occur. In RFC 9000 an MTU change is most likely to occur due to a connection migration event. Thus you may have some outstanding stream data ranges that needs to be retransmitted. In MP-QUIC you might attempt to send retransmission for a 1400 byte block over the other path that can only fit a 1200 byte data block. Thus, you will be forced to create two stream frames and send them in two packets if you are going to retransmitt.

[mirjak]

So something like:

As noted in {{Section 2.2 of QUIC-TRANSPORT}}, STREAM frame boundaries are not expected to be preserved when data is transmitted. Especially when STREAM frames have to be retransmitted over a different path with a smaller MTU limit, new smaller STREAM frames might need to be sent instead.

Should we add that somewhere?