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. 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. Cheers. 2020年5月18日(月) 17:17 Kuhn Nicolas <[email protected]>: > Hi, > > We have been working on an updated version of the 0-RTT draft. > > In short, the document describes a generic method to exchange path > parameters > relating to transport. The additional transport parameters can help > a connection that continues after an interruption or restarts by > sharing connection properties. They can be used to increase the > performance for a path with large RTT. > > The motivation is described in the document, but here is an extract : > "Currently each side has a proprietary solution to measure and to > store path characteristics. Recalling the parameters of a previous > connection would allow: > o Server and client to re-initialise the state from previously > established parameters (i.e., minRTT, MTU, bottleneck capacity, > etc.) > o The client to prepare the right resources > o The server to adapt to non-default path characteristics" > > Please let us know if you have any questions/comments. > > Kind regards, > > Nico on the behalf of the authors > > > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : lundi 18 mai 2020 10:12 > À : Emile Stephan <[email protected]>; Kuhn Nicolas < > [email protected]>; Gorry Fairhurst <[email protected]>; Stephan > Emile <[email protected]>; Tom Jones <[email protected]> > Objet : New Version Notification for draft-kuhn-quic-0rtt-bdp-07.txt > > > A new version of I-D, draft-kuhn-quic-0rtt-bdp-07.txt has been > successfully submitted by Nicolas Kuhn and posted to the IETF repository. > > Name: draft-kuhn-quic-0rtt-bdp > Revision: 07 > Title: Transport parameters for 0-RTT connections > Document date: 2020-05-18 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/internet-drafts/draft-kuhn-quic-0rtt-bdp-07.txt > Status: https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/ > Htmlized: https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-07 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kuhn-quic-0rtt-bdp > Diff: > https://www.ietf.org/rfcdiff?url2=draft-kuhn-quic-0rtt-bdp-07 > > Abstract: > 0-RTT mechanisms reduce the time it takes for the first bytes of > application data to be processed in a transport connection and can > greatly reduce connection latency during setup. The 0-RTT transport > features described by quic-transport help clients establish secure > connections with a minimal number of round-trips. > > This document describes a generic method to exchange path parameters > relating to transport. The additional transport parameters can help > a connection that continues after an interruption or restarts by > sharing connection properties. They can be used to increase the > performance for a path with large RTT. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > -- Kazuho Oku
