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

@@ -43,7 +43,7 @@ struct qcs *qcs_new(struct qcc *qcc, uint64_t id, enum qcs_type type)
 	qcs->tx.offset = 0;
 	qcs->tx.sent_offset = 0;
 	qcs->tx.ack_offset = 0;
-	qcs->tx.acked_frms = EB_ROOT_UNIQUE;
+	qcs->tx.acked_frms = EB_ROOT;
 
 	qcs->wait_event.tasklet = NULL;
 	qcs->wait_event.events = 0;