Layer separation when determining what is congestion controlled

[gloinul]

Section 9: When the protocol running inside the tunnel uses congestion control (e.g., [TCP] or [QUIC]), the proxied traffic will incur at least two nested congestion controllers. When tunneled packets are sent using QUIC DATAGRAM frames, the outer HTTP connection MAY disable congestion control for those packets that contain only QUIC DATAGRAM frames encapsulating Ethernet frames. Implementers will benefit from reading the guidance in Section 3.1.11 of [UDP-USAGE].

Is there need to discuss the potential need to traverse up the stack from Ethernet frames to determine if traffic flow is congestion controlled or identify flows that are? Or is this an overreaching layer violation to accomplish this. I think we have a bit of a problem here and it depends on how the network is being used. A network that predominately transport IP over Ethernet may be possible to assume that it carries congestion controlled traffic. However if there are usages that not IP and run more directly on Ethernet this may not be true.

[asedeno]

There are some interesting opportinities for implementers to inspect the Ethernet frames being transported and make some decisions based on what they see. At the MASQUE meeting at IETF 119, I mentioned the possibility the Ethernet proxying endpoints using TCP MSS clamping to squeeze TCP packets into the (unfortunately potentially variable) connection MTU, for example.

I'm not opposed to an appendix of such ideas for implementers to consider if their use cases warrant it, though I don't want to require such behavior from implementers.

[gloinul]

Yes, I don't want to forbid anything but also I don't think we can require anything. I think the text can be clearer on that most mechanism we have to affect these would require analyzing several layers on top of Ethernet and that it is up to implementation to select the trade-off here. So I think appendix or seperate section that is clear on the none requirements.