This topic is shrouded in mystery and not much documentation unless you spend hours trawling the web. Many years ago I did my own lab testing to see what the impact would be of enabling these features - see this link - I observed the packets caught by tcpdump on the PSN node.
As you would have seen in a tcpdump, EAP-TLS/EAP-PEAP methods establish a TLS tunnel.
Session Resume is an efficiency mechanism that reduces the amount of work done during the TLS establishment.
Session Resume has a session lifespan - once that session expires, a full TLS establishment is performed.
Stateless Session Resume is another method that can be used, but which uses a tag of sorts in the TLS packet exchange instead of maintaining a session table in the RADIUS server - for large scale systems this would help to scale the solution.
I don't think load balancer requires any consideration here - the LB would simply see a reduction in packets that it needs to forward onto the PSN - but the job of the LB remains unchanged - and yes, session persistence is very important. I have seen documentation somewhere that says that the RADIUS Session-Timeout should always be less than the LB persistence time - the idea is that the NAD would expire the session while the LB persistence was still valid - if and when the client re-auths, then the LB would send the RADIUS to the same PSN, since the persistence is still there. This would achieve long-term stickiness. Which might also be a bad thing if you want to achieve load balancing I have never come to a happy conclusion either way. What I do know though, is that the LB must NEVER switch to another PSN during the EAP establishment. But once EAP is complete, then it doesn't matter if the LB sends the next EAP conversation to another PSN. But LB session persistence is not that clever - AFAIK it works on a strict time-based policy.
PEAP has another little tweak called "Fast Reconnect". This one adds even more efficiency by not checking the auth status of the client - if you enable Session Resume and Fast Reconnect, then you're saving time by doing less TLS checking, and no auth checking. The danger of Fast Reconnect is that you could allow a device on the network whose credentials have been disabled (e.g. disabled AD account). But in some cases it might just give you the efficiency boost you require.
