On 10/26/2020 4:42 PM, Kazuho Oku wrote: > > > 2020年10月27日(火) 8:24 Christian Huitema <[email protected] > <mailto:[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 > Yes, you are probably right. It is simpler to use a "new token" than to try create yet another mechanism, and that's much cleaner than trying to change the value of the TLS resume ticket.
> > > > > 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. > Reading the draft again, I am concerned with statements such as "for 0-RTT data to be sent, the server must remember [various congestion control parameters]". In QUIC, servers do not send 0-RTT data, only the clients do. Servers MAY start sending data in response to a 0-RTT packet sent by the client, but at that point the server has received the new values of the client's transport parameters, so it can just use the correct values, no remembering needed. Is the current text a typo, writing "server" where "client" was meant? There is also some ambiguity in the draft regarding the status of the "bdp parameters". Why do we have identifiers associated with these parameters? Is the intent to send these as unencrypted transport parameters? That's certainly doable, although I do not understand well the "max packet number" parameter. That seems redundant with the "initial_max_data" and "initial_max_stream_data" parameters. Of course, if these are clear text parameters, we have to be concerned with issues of privacy and security. Can the value of the parameters be used to track clients? Can the client send creative values and affect server behavior? -- Christian Huitema
