On 10/26/2020 2:36 PM, Kazuho Oku wrote: > Hello, > > Thank you for the draft. I just had the opportunity to read it, and > therefore am leaving comments. > > First of all, I think it is a good idea to write down how endpoints > can reuse information from previous connections when reconnecting. > Many people have been talking about the idea, it seems that there are > pitfalls, and having a compilation of good practices could help. > > At the same time, I was puzzled with the following two aspects of the > draft: > > 1. The draft requires the characteristics of paths be communicated via > session tickets. IIUC, QUIC resumes the properties of the *endpoint* > using TLS session tickets, while the properties of a path (e.g., > peer's IP address) is to be remembered by a NEW_TOKEN token. The > draft's use of session ticket goes against that principle.
I also think that forcing the information in the session ticket is a bad idea. As Kazuho says, the session ticket is used to resume sessions, not necessarily from the same network location at which the session ticket was acquired. Using a "token" is better from that point of view. It also has the advantage that tokens are fully managed within the QUIC layer, without any dependency on the TLS stack, which makes the implementation significantly simpler. However, there is still an issue because New Tokens are normally sent just once at the beginning of the connection, and are used to manage the "stateless retry" process. If the server sends several New Tokens, the client is expected to remember all of them, and use them only once. It might be simpler to create a new frame, very similar to the "New Token" frame, maybe calling it "BDP_TOKEN", and a "bdp_token" transport parameter. The frame carries a binary blob that encode server defined data. The server sends the client whatever blob it wants. It may send it several time, in which case the client only remembers the last one. The client puts the blob in the bdp_token TP, or if no token is available sends an empty blob to signal its support for the process. The server may reply with an empty token if it does support the process. > > 2. The draft suggests that the server's properties (e.g., server's > BDP) be shared with the client. Is there any reason why they have to > be shared? I tend to think that each endpoint unilaterally remembering > what they prefer provides the most agility without the need to > standardize something. I think that "the endpoint remembers" should be the starting point. For one thing, we should also care of the scenario in which the client pushes data to the server, in which case the client needs to remember the BDP and RTT of the previous connection to the server. The server could do the same thing, just keep an LRU list of recent client connection addresses and the associated BDP and RTT. The whole business of sending blobs is just an optimization on top of the "endpoint remembers" strategy. We may be concerned that servers have to remember data for too many clients, that local server storage would not scale, or maybe that the same client hits a different server in the farm each time its reconnect. Hence the idea of storing these parameters in a blob, sending the blob to the client during the previous connection, and have the client provide the blob back during the new connection. Also, we seem concerned that the server does not trust the client, because otherwise the client could just add a couple of TP such as "previous RTT" and "previous Bandwidth", based on what the client observed before. Managing blobs has some complexity, so the tradeoffs should be explored. -- Christian Huitema
