]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: quic: Blocked STREAM when retransmitted
authorFrédéric Lécaille <flecaille@haproxy.com>
Sun, 13 Mar 2022 11:31:36 +0000 (12:31 +0100)
committerWilly Tarreau <w@1wt.eu>
Tue, 15 Mar 2022 09:38:48 +0000 (10:38 +0100)
commit2ee5c8b3dd22e58af338a8e993c10f7b35dff1ff
tree0d2f60d453a6d1926e669bea00c6fa3d86fd718f
parenta4af1b7633cfa5726c84c081ba46265380de510f
BUG/MEDIUM: quic: Blocked STREAM when retransmitted

STREAM frames which are not acknowledged in order are inserted in ->tx.acked_frms
tree ordered by the STREAM frame offset values. Then, they are consumed in order
by qcs_try_to_consume(). But, when we retransmit frames, we possibly have to
insert the same STREAM frame node (with the same offset) in this tree.
The problem is when they have different lengths. Unfortunately the restransmitted
frames are not inserted because of the tree nature (EB_ROOT_UNIQUE). If the STREAM
frame which has been successfully inserted has a smaller length than the
retransmitted ones, when it is consumed they are tailing bytes in the STREAM
(retransmitted ones) which indefinitively remains in the STREAM TX buffer
which will never properly be consumed, leading to a blocking state.

At this time this may happen because we sometimes build STREAM frames
with null lengths. But this is another issue.

The solution is to use an EB_ROOT tree to support the insertion of STREAM frames
with the same offset but with different lengths. As qcs_try_to_consume() support
the STREAM frames retransmission this modification should not have any impact.
src/mux_quic.c