Question 1:
Cstratton describes fport usage well in this forum post: What is fport used for when rx and tx
Question 2:
uplink_f_cnt_retransmission:
With every message a device should increment the fcount value it sends along with the message by 1. This is used to prevent replay attacks, so Chirpstack discards any message that has an fcount smaller than or equal to the last fcount it received from that device, assuming it to be an attacker retransmitting a message (such as a join request to attempt to have the server send the attacker new session keys so it can impersonate the device).
As for this error it means your device is sending fcount that are equal or less than the previous uplinks fcount.
What device are you using? If it is something “homebrew” that doesn’t increment fcounts you can disable the fcount verification in the “configuration” tab of the devices page.
If the device does increment fcount (as all retail LoRaWAN devices should) then you could try disabling the fcount verification, let the device uplink once so Chirpstack recognizes the current fcount, and then enable it again. Essentially letting Chirpstack sync fcounts with the device again.
If neither of these are the case then it is likely something wrong with the device, as Chirpstack is just doing its job preventing attackers.
Downlink Gateway Too Early:
This is a common error when using the UDP packet forwarder on a gateway. Brocaar explains it well in this forum post: Lora Server to GW MQTT ACK: "TOO EARLY" - #3 by brocaar
Although if it only happens rarely it can be ignored with little issue.