Closed boucadair closed 10 months ago
boucadair
commented
10 months ago The Destination CIDs are all that the network sees; the source CIDs are not even in the short-header packets
Then we need to figure out how the differentiated behavior will be triggered for short packets from the server as DCID of packets sent by a server belong to the CID space of the client, not the server!!
danwing
commented
10 months ago Then we need to figure out how the differentiated behavior will be triggered for short packets from the server as DCID of packets sent by a server belong to the CID space of the client, not the server!!
I do not see a problem.
After the initial handshake, today, QUIC client and QUIC server use short headers, which only contain a DCID.
Behavior for CIDFI is:
Client picks three DCIDs to use with CIDFI, numbered 123, 345, 567. Those will soon be used as Destination CIDs when the server sends packets towards the client. The client signals the server with those values (123, 345, 567) in both of these two ways:
After that signaling occurs, the application on the server continues telling its QUIC stack, via a new API (or extending existing API) the importance of each payload it hands to QUIC. The server's QUIC stack, now in possession of more DCIDs (the new 123, 345, 567) and knowing how the client's CIDFI Network Elements needs those CIDs mapped to their relative priority, transmits the payloads on the corresponding DCID.
We might optimize by removing the NEW_CONNECTION_ID from the above signaling, replacing it with a new QUIC message called CIDFI_NEW_CONNECTION_ID_AND_MAPPING. Would that make things clearer? Maybe it would.
boucadair
commented
10 months ago I do not see a problem.
Agree as well, but we need to call out the bebavior:
Client picks three DCIDs to use with CIDFI
It can pick up to a max that is communicated during handshake jointly with cidifi transport parameter. Let's call it: active_cidfi_connection_id_limit.
the application on the server continues telling its QUIC stack
Agree. We can say also that it is up to the app to decide which streams to include in a packet and the control of the priority level tagging. For example, when a high-priority stream is enclosed, the the high prio CID should be used whatever other streams are flying in the same packet.
called CIDFI_NEW_CONNECTION_ID_AND_MAPPING. Would that make things clearer? Maybe it would.
This is better, but I still think we need a better separation of CIDFI functionality and make use of a new STREAM frame.
danwing
commented
10 months ago Agree as well, but we need to call out the bebavior:
indicate which CID space is covered by a differentiated policy
In #77, I added a new QUIC CIDFI_NEW_CONNECTION_ID_MAPPING frame for the mapped CIDs. Other CIDs which didn't get signaled with that frame don't get CIDFI treatment.
That edit feels pretty clean.
indicate support for bidir differentiated or not
I want to punt that until later for bi-directional. It gets complicated, as existing text all over talks of 'client' and 'server' and would need to change to 'peer' (or some-such).
clarify the required signaling between peers to share the same binding of CID/policy
I made minor forward progress towards that in #77 -- if I understood that comment correctly, that is. The active_cidfi_connection_id_limit helps in that regard for network-to-host signaling, and similarly the CIDFI_NEW_CONNECTION_ID_MAPPING helps explain host-to-host signaling.
we may define a cidfi_role=rcv-only, snd-only, snd-rcv. The default should be snd-only to cover binding a policy to packets issued by the server.
I would prefer deferring bi-directional until we can tackle it fully. I think bi-directional will require a phone call for us to discuss it well.
Client picks three DCIDs to use with CIDFI
It can pick up to a max that is communicated during handshake jointly with cidifi transport parameter. Let's call it: active_cidfi_connection_id_limit.
Added in #77.
the application on the server continues telling its QUIC stack
Agree. We can say also that it is up to the app to decide which streams to include in a packet and the control of the priority level tagging. For example, when a high-priority stream is enclosed, the the high prio CID should be used whatever other streams are flying in the same packet.
Nyeah, maybe that's the right thing. Maybe the right thing is send the high-priority stream by itself in its own packet (that is, do not coalesce). Maybe heuristics like the size of the stream that wants to be sent has some bearing. For example imagine one high-priority stream containing VoIP (10 bytes payload) and one low-priority stream containing 1000s of bytes (a PDF that is being printed for example). On the wire, it's most efficient to send them together for sure. But that means the PDF earns the same treatment as the VoIP high-priority stream; that doesn't seem fair to the screen-sharing also happening which might be medium priority. My file transfer now clobbered my medium-priority stream.
To take a page from 3GPP, let's consider this decision For Future Study (3GPP seems to enjoy using that term).
called CIDFI_NEW_CONNECTION_ID_AND_MAPPING. Would that make things clearer? Maybe it would.
This is better, but I still think we need a better separation of CIDFI functionality and make use of a new STREAM frame.
Added in #77.
QUIC's design requires the receiver choose the (Destination) CIDs for traffic sent to the receiver, and communicate those to its peer. The Destination CIDs are all that the network sees; the source CIDs are not even in the short-header packets (neither encrypted nor un-encrypted). And we only care about short header packets for CIDFI! The packets containing source CID are only at the very beginning of a connection, and only last one round-trip.
We do need to figure out how all this works. It is not written down and we have not discussed. It seems reasonable that the client talk to the CIDFI Network Elements and gets told their capabilities -- how many DCIDs will they map for each UDP 4-tuple (0? 1? 10? 1000?), and what sort of treatment can they give those packets. With that, the client and server can figure out how to map, but we need to decide if it's best for the client to dictate to the server the mapping, or for the client to throw those 10 DCIDs at the server and the server chooses how to map the CNE capabilities to the 10 DCIDs.
In any event, there is no 'source CID' that is interesting. Perhaps we could say "if this is a non-short QUIC packet" it is interesting and something for CIDFI. But sending the Source CID(s) to the CNE(s) prior to initiating a QUIC connection could be done, should we need Source CID to get handled specially. I just don't see Long Header QUIC packets being interesting to the larger goals of CIDFI, which is to handle a stream after it has been set up with those Long Headers.
I'm thinking something like:
client talks to CIDFI Network Elements, learns their capabilities (2 or 3 or 5 slots of priority? can/cannot shorten bufferbloat depth? 5 DCIDs per UDP 4-tuple, whatever else is useful, etc.), and consolidates the capabilities of all its CNE's into some union set, and tells the CNE the mapping of their capabilities to soon-to-be-incoming DCIDs, sends the mapping to the server and sends QUIC NEW_CONNECTION_ID frames to the server, like: "your high priority packets will use DCID=1234, low priority DCID=9999)".