Original text:
control unless it has an out-of-band way of knowing with absolute certainty that the inner traffic is congestion-controlled.  When the protocol running over UDP that is being proxied uses loss recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used.  10. There are significant risks in allowing arbitrary clients to

Reviewer comments:
On a related note, the text in #performance talks about disabling congestion control on a "connection," but I believe this is actually a per-endpoint decision. (The client could easily have more information than the proxy on the tunneled connections).
Even if CONNECT-UDP has no explicit ECN support without an extension, there is ambiguity relating to copying of ECN bits between 'inner' and 'outer' datagrams. MASQUE is not strictly IP-in-IP, though it's close to it, so it's not clear if RFC 6040 applies. Nevertheless, I would propose the following principles: ECN markings on the MASQUE connection SHOULD NOT be copied to any resulting UDP datagrams sent by the proxy; they should apply to the MASQUE connection only. If MASQUE congestion control is disabled per section 9, it MUST mark all packets non-ECT. ECN markings on incoming UDP datagrams SHOULD NOT be copied to the IP headers of MASQUE packets that encapsulate them: upstream congestion should not affect the congestion state of the MASQUE connection. I'm happy to write a PR to that effect.
When using CONNECT-UDP without extensions, the server-facing UDP sockets on the proxy will not be configured to use ECN, so there will not be any ECN markings on the proxy-server path. In other words, ECN will not be in use, so do we need text about it? Adding text to clarify this sounds reasonable, but it probably should be generic to anything in the IP header.
The extensions explicitly concern markings on DATAGRAM frames in the inner connection. The server may very well be sending packets with ECT(0). With no extension, it will eventually stop, but nevertheless these shouldn’t appear in MASQUE IP headers.
Agreed. I'll take you up on your offer to write a PR then :)
Yes, I think that being clear that for this case the two legs needs to be kept seperate unless internal signalling is used on client to proxy leg to influence the external side setting and receiving of these values.
Thanks!

Revised text:
control unless it has an out-of-band way of knowing with absolute certainty that the inner traffic is congestion-controlled. <ins> If a client or proxy with a connection containing a CONNECT-UDP stream disables congestion control, it MUST NOT signal ECN support on that connection.  That is, it MUST mark all IP headers with the Not- ECT codepoint.  It MAY continue to report ECN feedback via ACK_ECN frames, as the peer may not have disabled congestion control. </ins> When the protocol running over UDP that is being proxied uses loss recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. <ins> 9.1. CONNECT-UDP does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in CONNECT-UDP tunnels. Note that CONNECT-UDP clients do not have the ability in this specification to control the ECN codepoints on UDP packets the proxy sends to the server, nor can proxies communicate the markings of each UDP packet from server to proxy. A CONNECT-UDP proxy MUST ignore ECN bits in the IP header of UDP packets received from the server, and MUST set the ECN bits to Not- ECT on UDP packets it sends to the server.  These do not relate to the ECN markings of packets sent between client and proxy in any way. </ins> 10. There are significant risks in allowing arbitrary clients to