search

martinthomson / train-protocol

Choo Choo!
Other
0 stars 0 forks source link

Move more to a single new version #7

Closed martinthomson closed 3 months ago

martinthomson commented 4 months ago

Expand the algorithms for setting and reading signals as well.

kazuho commented 3 months ago

I think I'm missing something, but I do not quite follow. Specifically, I do not see how the client decodes the server's first flight (e.g., QUIC v1 Initial).

Consider the following example:

Now, the problem is that the client cannot tell if the server's packet was encrypted (i.e., checksummed) using v1 or v4. So it cannot do anything.

Is the intent to let the server at first send a v1 or v4 depending on the QUIC version it chooses, and then, after there is an acknowledge from the client indicating that the version negotiation is complete, send a vTBDTRAIN packet using the packet protection scheme of the selected version?

While that is possible, I'm not sure if it's very simple. I think the design would be simpler if we just let the endpoints send and receive the QUIC version that they chose, and also let them send vTBDTRAIN packets that do not carry any information of the end-to-end connection (as stated in #8).

huitema commented 3 months ago

I think that @kazuho's comment is related to issue #8. My reasoning is the the server should not send VERSION_TRAIN before the client does. That means, let the packets carrying the full handshake carry the negotiated version number. After that, I think we could send "train probes" in handshake packets, but sending them as coalesced long header packets in front of 1RTT packets should also works.

kazuho commented 3 months ago

@huitema

I think that @kazuho's comment is related to issue https://github.com/martinthomson/train-protocol/issues/8.

Yes.

My reasoning is the the server should not send VERSION_TRAIN before the client does. That means, let the packets carrying the full handshake carry the negotiated version number. After that, I think we could send "train probes" in handshake packets, but sending them as coalesced long header packets in front of 1RTT packets should also works.

I'm not fully certain if relying on Handshake packets is a good idea.

That is because, as the handshake concludes, QUIC v1 discards the Initial and Handshake keys. Therefore, assuming we want to retrieve bandwidth information after the handshake or when the client migrates to a new path, we have to validate the UDP datagram carrying the bandwidth either by: a) checking the CID-pair (which would be non-zero length in practice) of the vTBDTRAIN packet, or by b) validating the short header QUIC packet that follows the vTBDTRAIN packet.

Either ways, if vTBDTRAIN packets are to carry only the bandwidth (with potentially having a short header packet coalesced to the same UDP datagram), handshake of any version of QUIC will work. In other words, we achieve QUIC version neutrality, so that would be good.

huitema commented 3 months ago

I am a bit concerned that we have 2 pending PRs and a big design question #8. If we believe the argument in #8 calling for the design to be version neutral, then we cannot really use version negotiation. That would move us back to negotiating a transport parameter for "support of TRAIN", after which parties can emit packets starting with a long header with "version = TRAIN" and CID per path, coalesced with regular "version=negotiated" packets. The peer would then echo the bandwidth value found in the overwritten TRAIN headers in a TRAIN frame.

I could rewrite PR #3 to match that design, but I am a bit concerned that rewriting both PR #3 and this PR (#7) will lead to merge conflict. I would propose that we merge at least one of these 2 PRs first, and then rewrite towards the desired solution in a rewritten PR.

martinthomson commented 3 months ago

Yeah, perhaps we can organize a call to go over the details. There are a couple of core questions here that might be easier to resolve that way. My sense is that we have some questions about versions and how they are used.

@kazuho, you know I'm going to ask you to co-author if you keep providing excellent contributions. :)