UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/604.5.6 (KHTML, like Gecko) Version/11.0.3 Safari/604.5.6

Example URL:

Steps to reproduce the problem:
While I was investigating the higher ratio of failed handshakes due to idle timeouts, I've noticed the following problem:

1. Connection 1 tries to write and the writer becomes write blocked
2. Connection 2 tries to write: some packets (handshake, TLP, RTO) are serialized even if the writer is write blocked. They are queued, but OnWriteBlocked() is not called.
3. When writer becomes writable again,  connection 2 is not notified and it does not write queued packets.
4. All subsequent write attempts for connection 2 are not realized, packets are queued (not sent).

The problem may disappear in some situations, for example, if the connection processes some packet.

The following patch (against chromium) shows a possible fix for the problem and  the unittest. The test would fail without the change in quic_connection.cc.
It's worth considering other ways to fix this problem: a better way could be to call OnWriteBlocked() from SendOrQueuePacket() if some packet is queued.
I think that if some connection has queued packets, than it must be added to the list of write blocked connections.

diff --git a/net/third_party/quic/core/quic_connection.cc b/net/third_party/quic/core/quic_connection.cc
index c3b1ccc..2672b0f 100644
--- a/net/third_party/quic/core/quic_connection.cc
+++ b/net/third_party/quic/core/quic_connection.cc
@@ -1987,6 +1987,7 @@ bool QuicConnection::WritePacket(SerializedPacket* packet) {
   // Termination packets are encrypted and saved, so don't exit early.
   const bool is_termination_packet = IsTerminationPacket(*packet);
   if (writer_->IsWriteBlocked() && !is_termination_packet) {
+    visitor_->OnWriteBlocked();
     return false;
   }

diff --git a/net/third_party/quic/core/quic_connection_test.cc b/net/third_party/quic/core/quic_connection_test.cc
index 1cabcb4..7954fb4 100644
--- a/net/third_party/quic/core/quic_connection_test.cc
+++ b/net/third_party/quic/core/quic_connection_test.cc
@@ -363,6 +363,8 @@ class TestPacketWriter : public QuicPacketWriter {

   void SetWritable() override { write_blocked_ = false; }

+  void SetWritable(bool writable) { write_blocked_ = !writable; }
+
   void SetShouldWriteFail() { write_should_fail_ = true; }

   QuicByteCount GetMaxPacketSize(
@@ -6827,6 +6829,30 @@ TEST_P(QuicConnectionTest, ValidStatelessResetToken) {
   EXPECT_TRUE(connection_.IsValidStatelessResetToken(kTestToken));
 }

+TEST_P(QuicConnectionTest, TLPWhenWriteBlocked) {
+  if (!connection_.session_decides_what_to_write()) {
+    return;
+  }
+
+  SendStreamDataToPeer(3, "foo", 0, NO_FIN, nullptr);
+  EXPECT_EQ(1u, stop_waiting()->least_unacked);
+  QuicTime retransmission_time =
+      connection_.GetRetransmissionAlarm()->deadline();
+
+  EXPECT_CALL(*send_algorithm_, OnPacketSent(_, _, _, _, _)).Times(0);
+  EXPECT_EQ(0u, connection_.NumQueuedPackets());
+
+  // Simulate the retransmission alarm firing and sending a tlp,
+  // so send algorithm's OnRetransmissionTimeout is not called.
+  clock_.AdvanceTime(retransmission_time - clock_.Now());
+  EXPECT_CALL(visitor_, OnWriteBlocked()).Times(AtLeast(1));
+  writer_->SetWritable(false);
+  connection_.GetRetransmissionAlarm()->Fire();
+  EXPECT_TRUE(writer_->IsWriteBlocked());
+  EXPECT_EQ(1u, connection_.NumQueuedPackets());
+  EXPECT_TRUE(connection_.HasQueuedData());
+}
+
 }  // namespace
 }  // namespace test
 }  // namespace net

What is the expected behavior?

What went wrong?
See steps to reproduce the problem.

Did this work before? N/A 

Chrome version: trunk  Channel: n/a
OS Version: OS X 10.13.3
Flash Version: