ExoPlayer clarification on DASH Byte-Range request against Player Buffer params' adjustments

Hi,
we're running with ExoPlayer 2.13.2 version and noticed that at peak live events encountering with an increase of 206 http response code status and service impact, such as outage in live channel / black screen at that moment.
the player log reporting on "Player Error Unable to connect" at that time and checking CDN Cache and verify that player reported this error is getting 206 response from CDN where zero bytes streamed from CDN to the player on 2 consecutive requests for the same video chunk.
on another Exoplayer at that time log reporting "Player Error java.net.SocketTimeoutException: timeout" checking CDN logs and again responded to player with 206 status code where there were 3 consecutive requests for the same video chunk answered in 206: the 2 first ones were with zero bytes returned where the 3rd one responded with none-zero bytes to the DASH Exoplayer.
what's strange here is that same video chunk was existing in CDN Cache and some of the exoplayers have received it with 200 ok, but others were answered in 206 and those are the ones that reported with those errors.
so few questions please:

1. ExoPlayer by default is managed to handle well the 206 partial request status code in DASH Byte-Range ?
2. Any further adjustment need to be done to improve the handling of exoplayer with 206 partial request ?
3. ExoPlayer 2.13.2 support the 'Content-Range' header response from server side / CDN ?
4. Can we avoid or decrease somehow the chance for the player to use a byte-range request (and instead asking full fragment length and get 200 ok in response) ? could it be achieved by a Buffer configuration ?
   buffer parameters in exoplayer on my side are the following ones:
   DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS = 2000
   DEFAULT_BUFFER_FOR_PLAYBACK_MS = 1500
   DEFAULT_MAX_BUFFER_MS = 50000
   DEFAULT_MIN_BUFFER_MS = 15000

could be that we need to increase DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS = 2000 in order for player to have more buffer before playing so that won't need to use byte range request to fill 2 sec of segments in order to play after rebuffer ?
for Live, the minBufferTime coming from the manifest MPD is 15sec - preferred to increase it a bit ? as exoplayer is reading this property for Live (open manifest)
5. those errors from ExoPlayer: "Player Error Unable to connect", "Player Error java.net.SocketTimeoutException: timeout" Are necessarily because of lack of Buffer in the player ?

I'd appreciate your advice and if there's such a correlation of 206 and Players' errors with Buffer parameters' values that I can improve
thanks a lot.