Include details about proxy connection ID mappings

[tfpauly]

From @DavidSchinazi

The issue about connection ID lengths should be addressed: since the end-server decides its own connection IDs, the client and proxy have no control over Server-Connection-Id. If the client sends non-tunneled short header packets, the server won't be able to figure out the connection ID length. The server could try all possible values, but either way I think this should be mentioned in the draft. In particular, the end of the Load Balancer seems to ignore this problem - the proxy's load balancer won't be collaborating with the end-server so I think this is broken

Beyond this, we can talk about how the proxy can try to re-use a socket between itself and the target, but that it needs to detect cases when a Connection ID cannot be distinguished (due to overlap in part, or insufficient length), and either create a new socket, or fail the request.

[DavidSchinazi]

I'm not sure I follow how using a new socket helps here. If the end-server decides to use a 1-byte server connection ID, and the client is using the non-tunneled mode, then the client will send a short header with that 1-byte CID to the main proxy address/port (probably port 443), it won't send to the proxy's ephemeral socket.

[tfpauly]

Also should cover: "the Connection ID MUST be unique across all other clients" - I think what you meant is: "Client connection ID mappings have to be unique to allow deterministic forwarding, and therefore servers MUST reject CONNECT-QUIC requests that contain a Client-Connection ID that is already in use" or something like that. That said, thinking about it more, I'm not sure what I just wrote is correct. Why do we need client connection IDs to be unique?

[DavidSchinazi]

I think that we can close this issue in favor of #21 and #22. I tried to explain my thoughts there better than I had in the email that led to opening this issue...

[tfpauly]

Sounds good to me!