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
diff --git a/quic/core/http/quic_spdy_session_test.cc b/quic/core/http/quic_spdy_session_test.cc
index fa6aec9..32fc3f1 100644
--- a/quic/core/http/quic_spdy_session_test.cc
+++ b/quic/core/http/quic_spdy_session_test.cc
@@ -1138,6 +1138,7 @@
// Test that server session will send a connectivity probe in response to a
// connectivity probe on the same path.
TEST_P(QuicSpdySessionTestServer, ServerReplyToConnecitivityProbe) {
+ connection_->SetDefaultEncryptionLevel(ENCRYPTION_FORWARD_SECURE);
QuicSocketAddress old_peer_address =
QuicSocketAddress(QuicIpAddress::Loopback4(), kTestPort);
EXPECT_EQ(old_peer_address, session_.peer_address());
@@ -1145,8 +1146,14 @@
QuicSocketAddress new_peer_address =
QuicSocketAddress(QuicIpAddress::Loopback4(), kTestPort + 1);
- EXPECT_CALL(*connection_,
- SendConnectivityProbingResponsePacket(new_peer_address));
+ if (connection_->send_path_response()) {
+ EXPECT_CALL(*connection_,
+ SendConnectivityProbingPacket(nullptr, new_peer_address));
+ } else {
+ EXPECT_CALL(*connection_,
+ SendConnectivityProbingResponsePacket(new_peer_address));
+ }
+
if (VersionHasIetfQuicFrames(transport_version())) {
// Need to explicitly do this to emulate the reception of a PathChallenge,
// which stores its payload for use in generating the response.
