This entirely depends on the chipset in your device, as not all of them have equal capabilities on Tx/Rx rates. I personally have found no better resources than wikidevi.com for looking up the capabilities of wireless network adapters.
To understand wireless that is 802.11n or newer, you need to understand the shorthand often used in their technical capabilities, namely AxB:C. A represents the number of Tx radio chains are available to the device, B represents the number of Rx radio chains, and C represents the number of spatial streams.
A device will need to have a number of antennas equal to the highest of either A or B to make use of its capabilities (i.e. I have seen a 3x3:3 adapter in a laptop with only two antennas and in such a case it will operate no better than a 2x2:2 device).
You can never have more spatial streams than you have either Tx or Rx radio chains (i.e. you need at least one radio chain to make use of a spatial stream). You can however have more radio chains than spatial streams, and in these cases they can provide other benefits (resistance to interference, extended range, etc).
To your specific question, I know of several Intel wireless chipsets that do not have equal capabilities on Tx and Rx. The Intel 5100 is an example of a 1x2:2 network adapter. This device can transmit up to 150Mbps and receive data up to 300Mbps.
(Edit: I was mistaken in the second device as I thought it was a 2x3:3, but when I looked at it again, it is a 2x3:2 so correcting that here.) The Intel 4965AGN is an example of a 2x3:2 device. While this device can transmit and receive up to 300Mbps, its actual Rx performance will tend to be better than the Tx due to the added capabilities the extra Rx radio chain provide.
I also believe I have seen other vendors with this type of lopsided Tx/Rx configuration as well, I just don't remember example chipsets off hand.
For your second question, the data rate used by Tx on the device and Tx on the AP can never exceed the capabilities of either device.
Responding to individual concerns in the post...
Regarding Path MTU Discovery
Ideally i would be relying on Path MTU discovery. But since the ethernet packets being generated are too large for any other machine to receive, there is no opportunity for IP Packet too big fragmentation messages to be returned
Based on your diagram, I agree that PMTUD cannot function between two different PCs in the same LAN segment; PCs do not generate ICMP Error messages required by PMTUD.
Jumbo frames
Some vendors (such as Cisco) have switch models which support ethernet payloads larger than 1500 bytes. Officially IEEE does not endorse this configuration, but the industry has valid needs to judiciously deviate from the original 1500 byte MTU. I have storage LAN / backup networks which leverage jumbo frame for good reason; however, I made sure that all MTUs matched inside the same vlan when I deployed jumbo frames.
Mismatched MTUs within a broadcast domain
The bottom line is that you should never have mismatched ethernet MTUs inside the same ethernet broadcast domain; if you do, it's a bug or configuration error. Regardless of bug or error, you have to solve these problems, sometimes manually.
All that discussion leads to the next question...
Why is there a spec that intentionally creates invalid ethernet frames?
I'm not sure that I agree... I don't see how the IEEE 802.3 series, or RFC 894 create invalid frames. Host implementations or host misconfigurations create invalid frames. To understand whether your implementation is following the spec, we need a lot more evidence...
This diagram is at least prima facie evidence that your MTUs are mismatched inside a broadcast domain...
+------------------+ +----------------+ +------------------+
| Realtek PCIe GBe | | NetGear 10/100 | | Realtek 10/100 |
| (on-board) | | Switch | | (on-board) |
| | +----------------+ | |
| Windows 7 | ^ ^ | |
| | | | | |
| 192.168.1.98/24 |-----------+ +------------| 192.168.1.10/24 |
| MTU = 1504 bytes | | MTU = 1500 bytes |
+------------------+ +------------------+
How should an 802.3-compliant implementation respond to MTU mismatches?
What was it they [the writers of 'the spec'] expected people to do with devices that generate these too large packets?
MTU 1504 and MTU 1500 within the same broadcast domain is simply a misconfiguration; it should never be expected to work any more than mismatched IP netmasks, or mismatched IP subnets can be expected to work. Your company will have to knuckle-down and fix the root-cause of the MTU mismatches... at this time it's hard to say whether the root cause is user error, an implementation bug, or some combination of the above.
If the affected Windows machines are successfully logging into to an Active Directory Domain, one could write Windows login scripts to automatically fix MTU issues based on some well-constructed tests inside the domain login scripts (assuming the Domain Controller isn't part of the MTU issues).
If the machines are not logging into a domain, manual labor is another option.
Other possibilities to contain the damage
Use a layer3 switchNote 1 to build a custom vlan for anything that has broken MTUs and set the layer3 switch's ethernet MTU to match the broken machines; this relies on PMTUD to resolve MTU issues at the IP layer. Layer3 switches generate the ICMP errors required by PMTUD.
This option works best if you can re-address the broken machines with DHCP; and you can identify the broken machines by mac-address.
... why did they bump it up to 1504 bytes, and create invalid packets, in the first place?
Hard to say at this point
802.1ad vs 802.1q
How is IEEE 802.1ad (aka VLAN Tagging, QinQ) valid, when the packets are too large?
I haven't seen evidence so far that you're using QinQ; from the limited evidence I have seen so far, you're using simple 802.1q encapsulation, which should work correctly in Windows, assuming the NIC driver supports 802.1q encap.
End Notes:
Note 1Any layer 3 switch should do... Cisco, Juniper, and Brocades all could perform this kind of function.
Best Answer
Ethernet (IEEE 802.3) and Wi-Fi (IEEE 802.11) are two completely separate layer-1/2 protocols, with different layer-2 frames. Each IEEE LAN type (ethernet, token-ring, FDDI, Wi-Fi, etc.) has it own frame format.
Since the packets are encapsulated by the frames, the packets can easily be transferred from one LAN type to another by discarding and building new frames. Routers do this as a matter of course; every frame coming into a router is stripped and discarded, the packet is switched to a new interface, and a new frame is built for the new interface.
With bridges, it is a little different. A bridge that has multiple LAN types needs to be a translating bridge to translate between the different frame types. Unlike transparent bridges, e.g. ethernet switches, translating bridges must strip the frames, but the frame information may need to be preserved in order to build a new new frame for the new LAN type. For instance, ethernet/token-ring bridges need to change the MAC addresses to/from ethernet and token-ring's canonical format. A WAP is really just a translating bridge.
Wi-Fi doesn't really have VLANs the way ethernet does. Normally, VLANs translate to SSIDs. There is/was a proposed standard to add VLANs to point-to-point Wi-Fi links in order to trunk wirelessly between two ethernet switches, but I have never seen it implemented, and I don't think there is much support for it.
802.11ad is just another Wi-Fi standard, the way ethernet has many different standards, e.g. 802.3z (gigabit ethernet).