Recommended conntrack QUIC UDP timeouts

1,117 views
Skip to first unread message

Javier Ruiz Jiménez

unread,
Aug 31, 2015, 10:02:47 AM8/31/15
to QUIC Prototype Protocol Discussion group
Hi all:

I had to disable QUIC in Chrome in our environment, as we were having a lot of failures with Google Apps (i.e. non responsive Gmail, Hangout messages that could not be delivered, sites and search not loading...). Opening the same pages in Firefox works, so it is a problem with Chrome using QUIC in our environment. Failures are aleatory, hangouts using android devices always work.

Environment:
  • Location: Madrid, Spain 
  • LAN PCs using Chrome as default browser, O.S: mostly Ubuntu 14.04.
  • CISCO switches
  • Everything connected at gigabit Ethernet
  • Internet routers:
    • Ubiquiti EdgeRouter ER-8  doing NAT --> to ER-8
    • CISCO 3945E doing routing --> To Internet
    • Connection to Internet using and enterprise symmetrical fiber optic with a 400/400 Mbps speed and 2ms ping.
I believe the problem is the timeout configuration for our NAT router (ER-8). I have played with the settings but it affects the VoIP UDP traffic and since issues are aleatory I have not been able to find a working configuration.

Current UDP conntrack timeouts for ER-8:

udp {
  other 120
  stream 300
}

Do you have any recommendations for timeout configuration or any suggestions about how to debug and fix the problem.

Thanks,
Javier Ruiz Jiménez
Tecsisa

Ian Swett

unread,
Aug 31, 2015, 10:42:36 AM8/31/15
to proto...@chromium.org
Thanks for telling us about this Javier.

QUIC uses a relatively conservative NAT timeout of 30 seconds, so 120 seconds should be more than enough.  That being said, we're actively working on handling port and IP migrations smoothly in QUIC, so even that wouldn't be as large a problem in the close future.

The best way for us to debug these issues is if you can capture a net-internals from Chrome(https://dev.chromium.org/for-testers/providing-network-details) when these issues are occurring and send it to me and the team can work to try to better diagnose this issue.  Usually net-internals gives us enough information to confirm or deny a diagnosis(like NAT unbinding), even if we can't exactly determine what network device is causing that issue.

Thanks, Ian

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

Martin S

unread,
Sep 24, 2015, 4:45:56 PM9/24/15
to QUIC Prototype Protocol Discussion group
Hello Javier, Ian,

Could you please share if a root cause could be indentified for the issue reported by Javier?

Starting yesterday we have seen similar symptoms (e.g. non responsive gmail) in our enviroment without having changed anything on any of our equipment at all. The UDP timeout on the firewall is 30 seconds for quic and we have not seen any issues until yesterday. The only solution disable quic by denying the protocol on the Internet firewall and force Chrome to fall back to TCP. At the same time we have found reports from users on the nanog mailing list reporting similar things for the last couple of days. Please see http://seclists.org/nanog/2015/Sep/621.

After some research we found that several firewall vendors, including Fortigate, seem to struggle with quic and generally recommend to disable quic to avoid issues.

I would appreciate any useful information you might have on this.

Kind regards, Martin

Ryan Hamilton

unread,
Sep 24, 2015, 5:23:35 PM9/24/15
to proto...@chromium.org
I think Ian posted an update to nanog earlier today:


Cheers,

Ryan

Martin S

unread,
Sep 25, 2015, 1:55:48 AM9/25/15
to proto...@chromium.org

Thanks a lot for sharing this link.

Cheers, Martin

Reply all
Reply to author
Forward
0 new messages