You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should the first SYN retransmission and next connection attempt happen at the same time?
i.e. If we attempt to connect to address A, should retransmitting to address A happen at the same time as attempting to connect to address B (the next address in the list)?
If we have packet loss in the network, that would probably exacerbate the problem. Maybe we should use packet pacing or some kind of delay between them?
The text was updated successfully, but these errors were encountered:
The rationale behind that choice was that both of them are sent when we believe the first SYN (or the corresponding SYN-ACK) to have been lost. We could tweak that logic to avoid having the new SYN and old SYN retransmission to go out to close to one another, but then we have to pick which goes first and an amount to delay the second one. I think sending the old SYN retransmission first makes the most sense, but I'm not sure how to come up with the delay.
I was testing our implementation currently, and I see that we send out the happy eyeballs race attempt well ahead of the SYN retransmission currently — so it's the opposite of the delay that @DavidSchinazi mentioned here. Something to look deeper into.
Should the first SYN retransmission and next connection attempt happen at the same time?
i.e. If we attempt to connect to address A, should retransmitting to address A happen at the same time as attempting to connect to address B (the next address in the list)?
If we have packet loss in the network, that would probably exacerbate the problem. Maybe we should use packet pacing or some kind of delay between them?
The text was updated successfully, but these errors were encountered: