Subject: Questions about QUIC server reset issues

From: fish fish <[email-masked]>
Date: Wed, 22 Nov 2017 15:26:52 +0800

Respected, 
	I am Siyu Yang from Tsinghua University in Beijing, China. I am a master candidate student interested in the transportation layer of satellite networks ( LEO/MEO/GEO ) using QUIC.
	Previously I have done an experiment building QUIC server and clients in a simulated satellite network environment. It turns out that QUIC/UDP performs much better than TCP/IP structure because of the reduced handshake RTTs and congestion control strategies.

	After reading Google’s paper on QUIC in sigcomm 2017, would you please tell me more about updates of quic’s server stateless reset strategies? Any solution if possible to solve?

	And I am also interested in QUIC cooperation with CDN in such a working case: mobile clients may apply for another CDN server when they are browsing using QUIC, if it is possible that a connection between CDN server A and the next CDN server B,  the server A would send the related users’ authentication info in service   (users’ public key and A’s public key so that B would not reject the clients’ requests though it is probably the first time that these clients seek for connection to B so that one-RTT saved in this “new” connection) to the server B if A knows that B would take over A to serve the clients ?

I might not be a very common phenomenon in terrestrial networks … I could think out one that:  a CDN incremental deployment that the newly established CDN server might “inherit” users’ authentication from its neighbor servers. 

But it could be a common phenomenon happening every few hours/days in satellite networks if we deploy a set of CDN servers for example in a MEO satellite networks which could cover the whole world with a couple of satellites. Some MEO-constellations has a good properties that the relative locations within these satellites does not change, just like constellations we observe in sky. In this time, the CDN servers serve one client in order and the next server coming to serve could be calculated easily. If QUIC could SUPPORT servers' authentication transport, it would help a lot in enhancement of the network flow in satellite networks!

And I am also interested that will authentication transport work in QUIC using TLS 1.3.

Maybe it would also help a lot in terrestrial networks if mobile users feel good to use their geolocation information …

Thanks in advance and looking forward to your reply.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 27 Nov 2017 19:22:21 +0000

I think what you're describing is a handoff from one server instance to another.  The intent with the Connection ID is that packets can be routed back to the server instance that already has the correct state to deal with them; if two server instances wanted to hand off that state between them to reduce their routing load, that seems like an internal decision that would be transparent to QUIC.  If the servers have different IP:port endpoints, however, that would look to the client like a server-side connection migration.  I don't know whether that has been explicitly deemed in or out of scope at this point.

For the Stateless Reset question, you'll need to be more specific:  what are you trying to solve?

From: QUIC [mailto:[email-masked]] On Behalf Of fish fish
Sent: Tuesday, November 21, 2017 11:27 PM
To: [email-masked]
Subject: Questions about QUIC server reset issues

Respected,

     After reading Google's paper on QUIC in sigcomm 2017, would you please tell me more about updates of quic's server stateless reset strategies? Any solution if possible to solve?

     And I am also interested in QUIC cooperation with CDN in such a working case: mobile clients may apply for another CDN server when they are browsing using QUIC, if it is possible that a connection between CDN server A and the next CDN server B,  the server A would send the related users' authentication info in service   (users' public key and A's public key so that B would not reject the clients' requests though it is probably the first time that these clients seek for connection to B so that one-RTT saved in this "new" connection) to the server B if A knows that B would take over A to serve the clients ?

I might not be a very common phenomenon in terrestrial networks ... I could think out one that:  a CDN incremental deployment that the newly established CDN server might "inherit" users' authentication from its neighbor servers.

Maybe it would also help a lot in terrestrial networks if mobile users feel good to use their geolocation information ...