Re: [Int-dir] [Last-Call] Intdir telechat review of draft-ietf-masque-connect-ip-10

[Christian Huitema <[e-mail]>]

On 4/19/2023 11:34 AM, [e-mail] 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