Thank you for reporting the issue. It looks that it was a poor connectivity problem. E.g., there was a 17 second delay between a sent and received packet.

t= 80003 [st=    1]  QUIC_SESSION_PACKET_SENT
                     --> packet_number = "32"
                     --> sent_time_us = "62317475067"
                     --> size = 117
                     --> transmission_type = 0
t= 97542 [st=17540]  QUIC_SESSION_PACKET_RECEIVED
                     --> peer_address = "216.58.195.68:443"
                     --> self_address = "10.7.0.2:52249"
                     --> size = 1350

There were plenty of re-transmissions and eventually the session timed-out:

t=105604 [st=25602]  QUIC_SESSION_PACKET_RETRANSMITTED
                     --> new_packet_number = "35"
                     --> old_packet_number = "30"
t=134605 [st=54603]  QUIC_SESSION_CLOSED
                     --> from_peer = false
                     --> quic_error = 25 (QUIC_NETWORK_IDLE_TIMEOUT)

It is also possible that there was a temporary problem on the server side.

Are you still experiencing this issue? If yes, would it be possible for you to try to connect from a different network?

Thank you!

This is the only network I have available. And, yes I am still experiencing the issue. TCP connections don’t suffer anything like that delay — 10s of milliseconds on average.

So, there seem to be two issues. I’ll try to figure out why UDP packets are delayed. Why didn’t Chrome fallback to TCP?

Unable to reproduce the issue on reported chrome version 63.0.3239.132 and on the latest canary 66.0.3327.0 using Mac 10.13.1 with the URLs Provided in comment#0. We are able to navigate to both of the web pages. As per comment#2 by reporter adding label Needs-Feedback.

Thanks!

Closing because of inactivity. Please reopen if you can provide the requested information.