Make QUIC connections send PATH_RESPONSE upon receiving PATH_CHALLENGE according to IETF QUIC draft v29.
Switch to use peer_address in the packet creator to write packet instead of the connection's peer address for both gQUIC and iQUIC.
In iQUIC, change the peer_address in packet creator temporarily to send PATH_RESPONSE to the source address of the current incoming packet.
Diff with old IETF impl:
The old behavior is that only server responds to PATH_CHALLENGE. V29 path validation section says both sides should be able to send and respond to PATH_CHALLENGE.
The old behavior sends PATH_RESPONSE after parsing the whole packet via a callback to QuicSession::OnPacketReceived() which is the same behavior as gQUIC response padded PING. IETF path validation doesn't need to notify session about receiving PATH_CHALLENGE. Connection itself is able to respond right away at OnPathChallenge().
The old behavior sends PATH_RESPONSE in a different code path which doesn't retry if socket is blocked. This CL changes to send PATH_RESPONSE on normal packet writing logic and buffer it if the write attempt fails.
The old behavior sample RTT from probing packets, but as they are sent on different path, they shouldn't contribute to RTT measurement on current path.
Code cleanup:
Since QuicConnection::SendConnectivityProbingResponsePacket() no longer sends PATH_RESPONSE, but only padded PING. Deprecate it with calling SendConnectivityProbingPacket() at the call sites. And update GFE stats accordingly.
Protected by FLAGS_quic_reloadable_flag_quic_send_path_response and existing flag --quic_reloadable_flag_quic_start_peer_migration_earlier.
PiperOrigin-RevId: 329738854
Change-Id: I45345611ff31011f76c72c406a9431cde031db96
11 files changed
