Subject: Questions about congestion control and version negotiation packet

From: Zhi Zhi2 Chang <[email-masked]>
Date: Thu, 30 Aug 2018 05:48:10 +0000

Hi, all

I have servel questions about QUIC congestion control and version negotiation packet.

Here[1] is my GQUIC packets which are already uploaded into cloudshark. My client IP address is 10.116.47.192 and the server's IP address is 10.121.222.230.

Question 1: In No.1 packet, client send ClientHello packet to server. No.2 packet, client send encrypted packet to server immediately ? Client doesn't have the server's certificate info right now, does it? The server send certificate info to client in No.3 packet.
What is the encrypted packet ( No.2 packet ) used for?

Question 2: QUIC has flexible congestion control. Does it mean every QUIC connection can own its congestion control method ? We can use 10 congestion control method to manage 10 apps, can't we?

Could someone give me some advice?

Thanks
Zhi Chang

[1]: https://www.cloudshark.org/captures/11a8c6a1a1eb

---

From: Ian Swett <[email-masked]>
Date: Thu, 30 Aug 2018 08:33:39 -0400

I can't access the cloudshark link without an account, but I suspect packet
number 2 is a 0RTT request if it's encrypted and the client hasn't received
anything from the server.
On Thu, Aug 30, 2018 at 1:49 AM Zhi Zhi2 Chang <[email-masked]> wrote:

> Here[1] is my GQUIC packets which are already uploaded into cloudshark. My
> client IP address is 10.116.47.192 and the server's IP address is
> 10.121.222.230.
>
>
>
> Question 1: In No.1 packet, client send ClientHello packet to server. No.2
> packet, client send encrypted packet to server immediately ? Client doesn't
> have the server's certificate info right now, does it? The server send
> certificate info to client in No.3 packet.
>
> Question 2: QUIC has flexible congestion control. Does it mean every QUIC
> connection can own its congestion control method ? We can use 10 congestion
> control method to manage 10 apps, can't we?
>

You could, but you could also do that for TCP in the Linux kernel by using
setsockopts.  However, that could become a very complex deployment to
manage and debug.

> [1]: https://www..cloudshark.org/captures/11a8c6a1a1eb
>

---

From: Zhi Zhi2 Chang <[email-masked]>
Date: Fri, 31 Aug 2018 02:10:21 +0000

Hi, Ian.

Thanks for your reply.

Yes, packet number 2 is a encrypted packet. In your opinion, this packet is a 0RTT request from client to server. But the question is the client doesn't know the server's certificate. Which certificate does client used for encrypting packets?

For the question 2, sorry, I don't know what you mean. Why do I use setsockopts for the TCP in Linux kernel? I want to QUIC which is based UDP. Is there any relationship between TCP in the Linux kernel and QUIC?

Hope for your reply.

Thanks
Zhi Chang

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Thursday, August 30, 2018 8:34 PM
To: Zhi Zhi2 Chang
Cc: [email-masked]
Subject: [External] Re: Questions about congestion control and version negotiation packet

I can't access the cloudshark link without an account, but I suspect packet number 2 is a 0RTT request if it's encrypted and the client hasn't received anything from the server.
On Thu, Aug 30, 2018 at 1:49 AM Zhi Zhi2 Chang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, all

You could, but you could also do that for TCP in the Linux kernel by using setsockopts.  However, that could become a very complex deployment to manage and debug.

Thanks
Zhi Chang

[1]: https://www..cloudshark.org/captures/11a8c6a1a1eb<http://cloudshark.org/captures/11a8c6a1a1eb>

---

From: Ian Swett <[email-masked]>
Date: Fri, 31 Aug 2018 08:53:49 -0400

On Thu, Aug 30, 2018 at 10:14 PM Zhi Zhi2 Chang <[email-masked]>
wrote:

> Hi, Ian.
>
>
>
> Thanks for your reply.
>
>
>
> Yes, packet number 2 is a encrypted packet. In your opinion, this packet
> is a 0RTT request from client to server. But the question is the client
> doesn't know the server's certificate. Which certificate does client used
> for encrypting packets?
>

The key is from the server config obtained in a previous QUIC connection.

>
>
> For the question 2, sorry, I don't know what you mean. Why do I use
> setsockopts for the TCP in Linux kernel? I want to QUIC which is based UDP.
> Is there any relationship between TCP in the Linux kernel and QUIC?
>

I was merely pointing out that both TCP and QUIC have the ability to change
congestion control algorithms based on the app or whatever other criteria
one wanted.

>
>
> Hope for your reply.
>
>
>
>
>
> Thanks
>
> Zhi Chang
>
>
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Ian Swett
> *Sent:* Thursday, August 30, 2018 8:34 PM
> *To:* Zhi Zhi2 Chang
> *Cc:* [email-masked]
> *Subject:* [External] Re: Questions about congestion control and version
> negotiation packet
>
>
>
> I can't access the cloudshark link without an account, but I suspect
> packet number 2 is a 0RTT request if it's encrypted and the client hasn't
> received anything from the server.
>

---

From: Roland Zink <[email-masked]>
Date: Fri, 31 Aug 2018 16:06:12 +0200

Am 31.08.2018 um 14:53 schrieb Ian Swett:
>
>
> On Thu, Aug 30, 2018 at 10:14 PM Zhi Zhi2 Chang <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     For the question 2, sorry, I don't know what you mean. Why do I
>     use setsockopts for the TCP in Linux kernel? I want to QUIC which
>     is based UDP. Is there any relationship between TCP in the Linux
>     kernel and QUIC?
>
>
> I was merely pointing out that both TCP and QUIC have the ability to 
> change congestion control algorithms based on the app or whatever 
> other criteria one wanted.

The difference is that for TCP the congestion control is in the kernel 
and setsockopt allows you to choose amongst the available ones. In QUIC 
this is in userspace code and each app developer may choose to implement 
their own. The choosen congestion control is not necessarily fair to 
others. This is already true for TCP where for example BBR is shown to 
be unfair to CUBIC, see for example 
https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf. The below 
graph from this presentation shows

Im Kreuzfeuer: Googles TCP-Flusskontrolle BBR

the effect of running a CUBIC connection at the same time as a BBR one. 
CUBIC is the standard Linux congestion control algorithm and kernels 
since version 4.9 also offer BBR. For TCP there are a limited number of 
congestion control algorithms implemented in the kernel and in the 
network some checks may be applied. In the QUIC world every app 
developer can deploy their own congestion control algorithm on the 
server and client side and the network has no clue about what is happening.

Regards,

Roland

>     Hope for your reply.
>
>     Thanks
>
>     Zhi Chang
>
>     *From:*QUIC [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Ian Swett
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [External] Re: Questions about congestion control and
>     version negotiation packet
>
>     I can't access the cloudshark link without an account, but I
>     suspect packet number 2 is a 0RTT request if it's encrypted and
>     the client hasn't received anything from the server.
>
>     On Thu, Aug 30, 2018 at 1:49 AM Zhi Zhi2 Chang
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi, all
>
>         Here[1] is my GQUIC packets which are already uploaded into
>         cloudshark. My client IP address is 10.116.47.192 and the
>         server's IP address is 10.121.222.230.
>
>         Question 1: In No.1 packet, client send ClientHello packet to
>         server. No.2 packet, client send encrypted packet to server
>         immediately ? Client doesn't have the server's certificate
>         info right now, does it? The server send certificate info to
>         client in No.3 packet..
>
>         Question 2: QUIC has flexible congestion control. Does it mean
>         every QUIC connection can own its congestion control method ?
>         We can use 10 congestion control method to manage 10 apps,
>         can't we?
>
>     You could, but you could also do that for TCP in the Linux kernel
>     by using setsockopts.  However, that could become a very complex
>     deployment to manage and debug.
>
>         <http://cloudshark.org/captures/11a8c6a1a1eb>
>