Let me get deeper into the technicalities then so that you can see the problem clearly:
1 - A TCP/IP connection consists of 4 parts, an source IP Address and a Port, and a destination IP Address and a Port. e.g. 10.0.0.2:34223 -> gmail.com:80
2 - Then the linux box which is the default gateway receives the request and looks for an interface (ppp connection) through which to route to the destination.
3 - The linux box then grabs the ip address of that interface and changes the TCP/IP packet accordingly. e.g. 64.53.23.1:34223 -> gmail.com:80. This is called Network Address translation.
4 - The linux box then sends off the request down that interface as if it had sent it, and waits for the answer.
5 - gmail.com:80 gets the data, and processes it, and sends it back down to 64.53.23.1:34223.
6 - When the answer arrives, the linux box swaps the addresses back : gmail.com:80 -> 64.53.23.1:34223 becomes gmail.com:80 -> 10.0.0.2:34223.
7 - Your pc gets the data, unaware of the changes.
Now, what you're missing is that gmail.com has now authenticated you. But, it has authenticated you as having come from 64.53.23.1:34223. This is where your problems begin.
If you add round-robin to the picture, your next request to gmail.com may come from a different ip address. e.g. PPP2's ip address.
When gmail.com receives the request it's going to take one look at the request and say ... well, who the heck are you? And reject the request.
Do you follow this?
The problem of the changing source IP address causes problems with the receiving end not recognising the sender.
That is why round robin does not exist in a workable format.
Now, to make matters worse, hackers use a technique where they do exactly what round-robin does in an effort to pretend to be you (Called IP Spoofing). And, because of this, all loopholes where round-robin was able to work have been closed down.