| Hi, Christian,
For TCP on TCP:
The bottom-most TCP turns an assumed fixed-capacity link with variable loss into a lossless link with variable RTT *and* it is trying to adapt to any changes in RTT and capacity.
The TCP on top then ends up as a badly oscillating flow control mechanism.
When the link transmission capacity varies; that’s a different change with presumably a relatively fixed RTT.
They’re not the same; TCP and other algs try to deal with one level of this, but none (AFAIK) are intended to be recursively (TCP on TCP) or mutually (TCP on QUIC or QUIC on TCP) stacked and end up stable.
Joe
— Dr. Joe Touch, temporal epistemologist www.strayalpha.com
On Apr 19, 2023, at 10:54 AM, Christian Huitema <huitema@xxxxxxxxxxx> wrote:
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 _______________________________________________ Int-dir mailing list Int-dir@xxxxxxxx https://www.ietf.org/mailman/listinfo/int-dir
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
