Notfiy NQE of QUIC RTT

net/quic/quic_connection.cc

Index: net/quic/quic_connection.cc
diff --git a/net/quic/quic_connection.cc b/net/quic/quic_connection.cc
index ac0bc7b7a3caa7bcf96c50fd2527bce102b8056b..22835b00abbd3572972fc5a5be9eabdd72f12575 100644
--- a/net/quic/quic_connection.cc
+++ b/net/quic/quic_connection.cc
@@ -1828,6 +1828,8 @@ void QuicConnection::OnRttChange() {
     rtt = QuicTime::Delta::FromMicroseconds(
         sent_packet_manager_.GetRttStats()->initial_rtt_us());
   }
+  if (debug_visitor_ != nullptr)

[Ryan Sleevi, 2015/09/18 17:36:45]

if (debug_visitor_)

It's cleaner that way, plus works across all pointer and smart pointer types :)

[tbansal1, 2015/09/18 17:59:59]

Done.

+    debug_visitor_->OnRttChanged(rtt);

[Ryan Sleevi, 2015/09/18 17:36:45]

It doesn't seem like it really makes sense to couple this with the the debug
visitor - this isn't necessarily a debug event. Shouldn't this have a proper
interface from the Quicconnection?

[tbansal1, 2015/09/18 17:59:59]

Not sure what is the right design here. Initially, I had the plumbing in
QuicConnection. rch@ mentioned it is discouraged to have Chromium specific code
in QuicConnection because it needs to be synced with the backend implementation.
wdyt?

[Ryan Hamilton, 2015/09/18 22:01:26]

I think this current approach is correct. The "real" visitor is used to
implement the core QUIC protocol, i.e. things which the QuicSession needs to
implement. The debug visitor is for pulling various metrics out of the
Connection. Some of these metrics may end up having "real" effects, but I'm fine
with this being tied to the debug visitor.

   packet_generator_.OnRttChange(rtt);
 }