Closed sourad closed 1 year ago
You only need one address:port to do the match. If there is no CID, then everything matching that tuple matches the connection.
Can you please clarify the confusion I have below - Say there are 2 local IPs - Local_IP1 and Local_IP2 associated with an interface and 2 connections are established one from Local_IP1:Port_x and other from Local_IP2:Port_x to the same destination dest_IP:Port_y. Judging by the doc, I think the NDIS_QUIC_CONNECTION will contain dest_IP and Port_y in its address field and port field respectively. How would that disambiguate the 2 connections being offloaded here?
I think the source of confusion is "destination" then. It's in the perspective of the packet. For a TX packet, that will be the remote tuple. For an RX packet, that will be the local tuple. Does that help?
I see. Yes, that does clear a part of my confusion. But I have one more:
Again, consider the scenario I outlined above: For Rx, that makes sense - we'll have 2 entries one per local tuple. For Tx we'll have 1 entry (since the remote tuple is same) which will be shared between the 2 connections? Is that okay? Is it guaranteed that the encryption parameters would be same for the 2 connections (even though they go to the same destination IP/port).
Similarly say the same local IP:Port is used to connect to 2 different destinations. Will we have just 1 entry (with local tuple) for the Rx offload for both connections?
You can't practically have two QUIC connections without CID on the same port, because there's no way to demultiplex them. So, there shouldn't ever be a case where you'd want to add two null-CID connections to the same tuple.
I've renamed this to narrow in on the question of "What part of the local address:port should be involved in QUIC packet routing?"
Made it clear in the psuedocode I just merged. The local address and port are used.
There are UdpPort and address fields, but only for destination. We probably need the 4-tuple to match against in absence of connection ID?