QUIC fallback to TCP scenario

[Sevket Arisu]

Hi everyone

i have installed proto-quic server and it can serve a simple website locally on my computer. 

For testing the server i'm starting chrome web browser with commands below:

chrome \
  --user-data-dir=/tmp/chrome-profile \
  --no-proxy-server \
  --enable-quic \
  --origin-to-force-quic-on=www.example.org:443 \
  --host-resolver-rules='MAP www.example.org:443 127.0.0.1:6121' \
  https://www.example.org




My first question is how can i make the quic server fallback to tcp?

I want to see behavior of the proto-quic server when quic ports are blocked while browsing the web site.

My second question: Can i browse the website which served on proto-quic server with a non-quic enabled chrome browser?

I tried commands below but it didn't worked.

chrome \
  --user-data-dir=/tmp/chrome-profile \
  --no-proxy-server \
  --disable-quic \
  --host-resolver-rules='MAP www.example.org:80 127.0.0.1:6121' \
  http://www.example.org




Thanks for your help!

[Robbie Shade]

Hey Sevket,

Answers inline below.

My first question is how can i make the quic server fallback to tcp?

 

I think there is a misunderstanding here: there is no fallback to TCP at the *server* with QUIC, it is up to the *client* to detect that QUIC/UDP is being blocked and fallback to an alternative protocol. The toy client provided in the proto-quic repository doesn't include the TCP fallback mechanism, it simply tries to talk QUIC and will fail if QUIC is blocked.

 

I want to see behavior of the proto-quic server when quic ports are blocked while browsing the web site.

 

If QUIC (i.e. UDP on port 443) is blocked then no QUIC packets will reach the server, so the server will never know that a client is trying to talk to it.

 

My second question: Can i browse the website which served on proto-quic server with a non-quic enabled chrome browser?

No, the server only listens for and responds to QUIC. If Chrome has QUIC disabled then it will attempt to connect using TCP, but the proto-quic server does not listen for incoming TCP connections and so will not respond.

Hope that helps!

Robbie

[Dan Wing]

> On May 9, 2017, at 9:20 AM, 'Robbie Shade' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:
>
> Hey Sevket,
>
> Answers inline below.
>
> My first question is how can i make the quic server fallback to tcp?
>
> I think there is a misunderstanding here: there is no fallback to TCP at the *server* with QUIC, it is up to the *client* to detect that QUIC/UDP is being blocked and fallback to an alternative protocol. The toy client provided in the proto-quic repository doesn't include the TCP fallback mechanism, it simply tries to talk QUIC and will fail if QUIC is blocked.
>
> I want to see behavior of the proto-quic server when quic ports are blocked while browsing the web site.
>
> If QUIC (i.e. UDP on port 443) is blocked then no QUIC packets will reach the server, so the server will never know that a client is trying to talk to it.

UDP might be blocked incoming, outgoing, or both. That is, the QUIC server might see those incoming UDP packets, but the responses are blocked by the firewall configuration. That occurs when the firewall is allow outbound UDP for traceroute (and thus allowing ICMPs to come back) and configured to block incoming UDP to block UDP-based attacks.

-d

>
> My second question: Can i browse the website which served on proto-quic server with a non-quic enabled chrome browser?
>
> No, the server only listens for and responds to QUIC. If Chrome has QUIC disabled then it will attempt to connect using TCP, but the proto-quic server does not listen for incoming TCP connections and so will not respond.
>
> Hope that helps!
>
> Robbie
>

> --
> 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.

[Robbie Shade]

Ok sure - in any of those situations the client needs to be the one doing the detection (and recovery from) UDP blockage. From the client's perspective the QUIC packets it sends are going into a blackhole, and the server has no way to communicate to the client.

When attempting to use QUIC, Chrome will race a TCP and a QUIC connection in parallel. If the QUIC handshake fails (due to e.g. UDP blockage), then Chrome will transparently use the TCP connection instead. The proto-quic client doesn't have this behavior (but it could of course be added).

To run experiments with a client that does fallback to TCP, I'd strongly recommend using Chrome. If this is not possible, you'd have to add fallback functionality to the proto-quic client. If that's of interest, then someone from the Chrome team can give some pointers to where the fallback implementation exists in the Chromium codebase.

> To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Dan Wing]

> On May 9, 2017, at 10:43 AM, 'Robbie Shade' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:
>
> Ok sure - in any of those situations the client needs to be the one doing the detection (and recovery from) UDP blockage.

Agreed that client needs to recover; any of those blocks look exactly the same from client's perspective. However, it looks different from server's perspective, which was the earlier question ("I want to see behavior of the proto-quic server when quic ports are blocked"). If the returning UDP is blocked, the server will see the incoming QUIC traffic, but will never see it being acknowledged. With 0-RTT, the server's responses might be large (tripping MTU), and with 0-RTT -- as much as we hate to admit and warn applications against it -- the server might change state with each of the client's QUIC retransmits.

-d

> From the client's perspective the QUIC packets it sends are going into a blackhole, and the server has no way to communicate to the client.
>
> When attempting to use QUIC, Chrome will race a TCP and a QUIC connection in parallel. If the QUIC handshake fails (due to e.g. UDP blockage), then Chrome will transparently use the TCP connection instead. The proto-quic client doesn't have this behavior (but it could of course be added).
>
> To run experiments with a client that does fallback to TCP, I'd strongly recommend using Chrome. If this is not possible, you'd have to add fallback functionality to the proto-quic client. If that's of interest, then someone from the Chrome team can give some pointers to where the fallback implementation exists in the Chromium codebase.
>
> On Tue, May 9, 2017 at 12:35 PM, Dan Wing <dan...@gmail.com> wrote:
>
> > On May 9, 2017, at 9:20 AM, 'Robbie Shade' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:
> >
> > Hey Sevket,
> >
> > Answers inline below.
> >
> > My first question is how can i make the quic server fallback to tcp?
> >
> > I think there is a misunderstanding here: there is no fallback to TCP at the *server* with QUIC, it is up to the *client* to detect that QUIC/UDP is being blocked and fallback to an alternative protocol. The toy client provided in the proto-quic repository doesn't include the TCP fallback mechanism, it simply tries to talk QUIC and will fail if QUIC is blocked.
> >
> > I want to see behavior of the proto-quic server when quic ports are blocked while browsing the web site.
> >
> > If QUIC (i.e. UDP on port 443) is blocked then no QUIC packets will reach the server, so the server will never know that a client is trying to talk to it.
>
> UDP might be blocked incoming, outgoing, or both. That is, the QUIC server might see those incoming UDP packets, but the responses are blocked by the firewall configuration. That occurs when the firewall is allow outbound UDP for traceroute (and thus allowing ICMPs to come back) and configured to block incoming UDP to block UDP-based attacks.
>
> -d
>
> >
> > My second question: Can i browse the website which served on proto-quic server with a non-quic enabled chrome browser?
> >
> > No, the server only listens for and responds to QUIC. If Chrome has QUIC disabled then it will attempt to connect using TCP, but the proto-quic server does not listen for incoming TCP connections and so will not respond.
> >
> > Hope that helps!
> >
> > Robbie
> >
> > --
> > 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.
>
> --
> 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.
>
>
> --
> 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.