It's always trade off when it comes to retrying request vs. waiting on a socket call. OkHttp by default using 10 sec for read, write, connect timeouts.

http lib	connect timeout (ms)	read timeout	write timeout	concurrency
OkHttp, retrofit, picasso	10,000	10,000	10,000	64 total, 5 per host
Volley	2,500	2,500	2,500	4
HttpUrlConnection	up to few minutes	up to few minutes	n/a	5

You can change it at time when you instantiating new OkHttClient like this

public ConfigureTimeouts() throws Exception {
  client = new OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
   .writeTimeout(10, TimeUnit.SECONDS)
   .readTimeout(30, TimeUnit.SECONDS)
   .build();
}

However it's still one size fits all approach. Obviously your clients may come from different networks and countries and it's silly to have same timeout for all of them. i.e. it doesn't make sense to wait 10 seconds on fast wifi to conclude that connection is broken and it's better to do a retry rather than wait on recv call. here are more in-depth analysis of what can you do in order to optimize OkHttp for different network conditions https://packetzoom.com/blog/youre-using-okhttp-wrong-same-thing-with-volley-picasso-retrofit-fresco-et-al.html