lsquic icon indicating copy to clipboard operation
lsquic copied to clipboard

Does the code handle case where a sent but not ACKed STREAM has to be repathed to a lower MTU path?

Open pjakma opened this issue 1 year ago • 1 comments

Hi,

I'm trying to figure out if the code handles the case where a STREAM frame that has been buffered (but not sent) has to be repathed onto a new path, where the new path has an MTU that can not accommodate the STREAM frame as it is.

I'd expect either the STREAM frame itself has to be split up into multiple frames, or the data queued in the frame has to be pushed back up to the stream code for it to handle it. But I can't find this code. I can see how packet-resize splits out frames of a packet, but nothing on how a over-size STREAM might be split.

How should this work?

Thanks, Paul

pjakma avatar Aug 10 '22 14:08 pjakma

From a comment on slack it seems split_buffered/lost should be doing this. But (AFAICT) it can only split out whole frames from packets - it can not further split a frame. So it sounds like lsquic_stream.c or somewhere needs a facility to split a STREAM frame, so that split_* in lsquic_sendctl.c can use that, as needed.

pjakma avatar Aug 17 '22 10:08 pjakma