There is whole field of study called delay/disruption tolerant networking (https://tools.ietf.org/html/rfc4838 https://tools.ietf.org/html/rfc4838), which uses

There is whole field of study called delay/disruption tolerant networking (https://tools.ietf.org/html/rfc4838 https://tools.ietf.org/html/rfc4838), which uses data mules or physical mobility to overcome connectivity outages in constraint environment (http://en.wikipedia.org/wiki/Routing_in_delay-tolerant_networking http://en.wikipedia.org/wiki/Routing_in_delay-tolerant_netwo...). However, there is one thing that the delay (in the cited article) does not take into account is that the flights do not take-off all the time, so if you have data ready to be sent and no one to take it, then there is waiting delay before it can be sent. so if there is only one flight in a day then some data will have to wait between 24+10h to 0+10h before it can arrive. Since storage cost is very low, one could ship a lot of data but this data cannot be delay sensitive else. on the other hand, using TCP one can prioritize data and send more important data before the rest. Of course there may be intrinsic problems with TCP receiver window and one of the proposal is to increase the initial window but the research community and the IETF is a bit split on the real benefits of it. The fear is that it may cause a congestion collapse. Moreover, the current buffer-bloat in the routers and the increase in the window size may only aid in causing a congestion collapse (http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00 http://tools.ietf.org/html/draft-gettys-iw10-considered-harm...).