TCP fallback after UDP flooding prevention

186 views
Skip to first unread message

Lennart Kindermann

unread,
Sep 4, 2018, 8:08:44 AM9/4/18
to proto...@chromium.org
I recently had problems at home with all google services, with most impacts on Maps and YouTube.

The outcome was that my Juniper SRX300 firewall had turned on a security screen with udp flooding detection/prevention enabled [1].
This screen drops packets in the second of occurence and the following second to the same ip/port-pair if it exceeds a configured max. packets-per-second threshold.
After I disabled the feature all Google services went back to normal behaviour.

I am completely not involved in QUIC development and integration, but it seems that there should be a more conservative fallback mechanism to prevent such firewall configurations killing the entire traffic to this host.

Regards
Lennart Kindermann

Ian Swett

unread,
Sep 4, 2018, 8:48:24 AM9/4/18
to proto...@chromium.org
Thanks for reporting this, I wasn't aware of this issue on Juniper routers.  It looks like the end result would be low bandwidth connections experience low to no packet loss, and higher bandwidth connections like Maps and YouTube experience much higher loss?

Chrome has mechanisms to fallback to TCP if UDP is blocked or blackholed, but not if it's severely rate-limited.  We attempted to create some heuristics earlier in the project, but no approach worked well.  For example, there are networks with packet policers like you described installed for all traffic, and in those cases, falling back to TCP turns out to be the wrong choice from a user-experience perspective.

Now that QUIC is an IETF working group(https://datatracker.ietf.org/wg/quic/about/) close to adoption of a first draft, I'd like to work on preventing differential treatment between QUIC and TCP, since detecting it correctly is extremely difficult.

Previously, I was under the belief that the type of settings you encountered are now rare, or when they are enabled, UDP 443 is also blocked?  Do you know if this was the default on the Juniper?

Thanks, Ian

On Tue, Sep 4, 2018 at 8:08 AM Lennart Kindermann <lennart.k...@gmail.com> wrote:
I recently had problems at home with all google services, with most impacts on Maps and YouTube.

The outcome was that my Juniper SRX300 firewall had turned on a security screen with udp flooding detection/prevention enabled [1].
This screen drops packets in the second of occurence and the following second to the same ip/port-pair if it exceeds a configured max. packets-per-second threshold.
After I disabled the feature, all Google services went back to normal beahviour.

I am completely not involved in QUIC development and integration, but it seems that there should be a more conservative fallback mechanism to prevent such firewall configurations killing the entire traffic to this host.

Regards
Lennart Kindermann

--
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.
Reply all
Reply to author
Forward
0 new messages