Re: [quicwg/base-drafts] Reliable identification of the initial packet for a connection (#185)

[Igor Lubashev <[e-mail]>]

No, you _can_ know which server to direct traffic for existing connections to without maintaining state. All you need is something in each packet you are routing that identifies that server.  Hence a server-generated ConnectionID for QUIC.
For tcp, there is the sequence number that the server generated during SYC/ACK and which is carried in all TCP packets (and ICMP Error packets), except for TCP RST.  The "mostly stateless" for TCP is due to the nature of the always-mutating sequence number -- if the connection persists long enough, you may need to start keeping state.

The map you are suggesting would need to be a distributed map (it is not just one box that is doing all the load balancing).  While such a distributed map is possible within one pop, it would be a complex system that must keep nodes synced to a firehouse of changes and be resilient to packet #2 arriving on a different node, while the information about the routing decision has not yet propagated from the original node.
What's worse, for QUIC, this map would not work for Anycast-based CDNs, since when you are migrating from your WiFi network to a Mobile network, you are likely going to be taken to a geographically different Anycast pop. Reliably syncing a firehouse of connection establishment/teardown events across pops makes doing the same within a single pop seem easy.
- Igor 
P.S. Consistent Hash can help here but just a little. You can use consistent hash to pick a load balancer machine within a pop. That allows you to limit sharing of state with fewer than all load balancing nodes. But that cannot be used to route to the backend servers, since you need to consistently route to the correct backend nodes despite of the frequent changes in the set of backend nodes available to serve this particular traffic.

    On Friday, February 10, 2017 7:28 PM, janaiyengar <[e-mail]> wrote:
 
How was this issue resolved?I don't understand the premise of the problem here. If you want to build something completely stateless, the only way to do it is ECMP with a consistent hash. You can do that on any packet in the connection and it won't matter.But if you're doing anything smarter, you're going to be stateful. You cannot know which server to direct traffic for existing connections to without maintaining state. The state that you need it a table mapping 4-tuple to server for TCP, and you could do the same with connection ID to server for QUIC.Since you will have this map (this may be the "mostly stateless" part you mention earlier), any received packet that has a connection ID that's missing from the map can create a new entry. You can be smarter about it, but this is a fairly simple and largely effective algorithm that ought to work.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.  

   

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/185#issuecomment-279112257