tree aaa71b135f2b02acdf0f1f9f266f9cf6735ffd71
parent edf934d71e960173dcb1f257b8d228ff6c4f9607
author danzh <danzh@google.com> 1599067588 -0700
committer Copybara-Service <copybara-worker@google.com> 1599067626 -0700

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