I also set the "receive ECN" option at the socket level, and then get the ECN value as part of overlapped recvmsg.
that code is wrong. In linux, the call would use IPV6_TCLASS to set the ECN byte in outgoing packets. There is no equivalent of setting TCLASS in Windows. Apparently, the msquic code uses a CMSG option in sendmsg with the same option code IP_ECN to set the ECN data on the specific packet. Just the symmetric of the CMSG option in recvmsg.
Instead, the code should be setting CMSG IP_ECN=ECT_1. It may also requires IP_PKTINFO, but picoquic uses that already. The part of the documentation that isn't really clear is that the control_buffer in WSAMSG length has to be sized to the actual number of CMSGs rather than the total size of the allocated buffer...
The code in picoquic in Picoquic by setting the ECN option at the socket level. Calls like:
I also set the "receive ECN" option at the socket level, and then get the ECN value as part of overlapped recvmsg. that code is wrong. In linux, the call would use IPV6_TCLASS to set the ECN byte in outgoing packets. There is no equivalent of setting TCLASS in Windows. Apparently, the msquic code uses a CMSG option in sendmsg with the same option code IP_ECN to set the ECN data on the specific packet. Just the symmetric of the CMSG option in recvmsg.
Instead, the code should be setting CMSG IP_ECN=ECT_1. It may also requires IP_PKTINFO, but picoquic uses that already. The part of the documentation that isn't really clear is that the control_buffer in WSAMSG length has to be sized to the actual number of CMSGs rather than the total size of the allocated buffer...