On 4/19/2023 10:36 AM, Mirja Kuehlewind wrote:
Hi Joe, hi all, I would just quickly reply to the following part: David: I've seen literature about nested TCP, which is both nested congestion control and nested loss recovery. In my understanding, the majority of the issues come from the two layers retransmitting the same data, not from the nested congestion controllers. Joe: The lower one slams the window down due to loss; the upper one should never really see loss at all (given it’s running over TCP), but every time a loss and retransmit occurs, the RTT measurements at the upper layer take a hit. So the bottom layer does what it can, but the upper layer gets into regimes where it thinks it can send more (RTT BW*delay) than it really can, which then causes process stalls at the upper layer. Joe, this is not correct if QUIC datagrams are used as datagrams are no retransmitted and thus losses will be exposed to the tunneled connection without delay avoiding time-outs in the upper layer congestion control. This is what David meant by nested loss recovery. This may also have implications on congestion control but it’s probably less problematic.
The implication on congestion control would be no different from, for example, shared wireless or cable links whose transmission capacity varies based on local load conditions. If the end-to-end congestion control algorithm cannot cope with that, then the congestion control algorithm needs to be replaced.
-- Christian Huitema -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
