2020年10月27日(火) 8:24 Christian Huitema <[email protected]>: > > 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. >
I tend to agree with the high order design, and it is my understanding that use of NEW_TOKEN tokens is fine for the purpose. The transport draft has a paragraph stating that a server might send new NEW_TOKEN tokens as the state of the connection changes, and that it makes sense for the client to use the most recently received NEW_TOKEN token. https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1.3-9 > > > > 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 > > > > > -- Kazuho Oku
