search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
49 stars 17 forks source link

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

Closed gloinul closed 1 week ago

gloinul commented 4 months ago

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 commented 4 months ago

refragmentation? When?

huitema commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

huitema commented 4 months ago

@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 commented 4 months ago

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 commented 2 months ago

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?

mirjak commented 2 weeks ago

created PR #395 to add this text in the implementation consideration section on retransmissions.