On 4/19/2023 11:34 AM, touch@xxxxxxxxxxxxxx wrote:
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.
Many links do not have a fixed capacity from point A to point B. This is not new. TCP used to work over yellow cable Ethernet or X.25 virtual circuits, and in both cases the capacity of the "link" varied with the competing load on other Ethernet connections or other virtual circuits. Congestion control algorithm like Reno, Cubic or BBR are all designed to adapt to variable capacity.
The loss detection algorithms are also designed to deal with variable end-to-end delays. Some algorithms such as Ledbat or BBR do depend on an estimate of the min RTT, but that's not affected here.
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.
Maybe. If the "link" TCP is a small part of the path, I would be surprised to see big issues, but if the two TCP connections are exactly superposed, there might be some issues. That probably depends a lot on deployment condition, such as which congestion control algorithm is used at each layer. I would be interested to read the papers that describe the issue.
Concretely, this seems an issue not so much with the "link" itself as with the management of the input queue. As far as Masque is concerned, I think the proper way to address that is to document the issue, cite the papers that you refer to, and recommend that deployments place adequate queue management algorithms in front of the tunnel. Do we have an AQM best practice RFC that could be cited?
-- Christian Huitema -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
