The more I think about it, a draft to describe best practices in this area per Gorry's suggestion may be worthwhile, but it'd be tsvwg work I think?
I think the use of QUIC transport parameters for this is concerning and I would not want to adopt it. On Thu, Oct 29, 2020 at 10:34 AM Kuhn Nicolas <[email protected]> wrote: > Hi all, > > > > Thank you very much for the discussions on the list. > > There is a consensus to write down how endpoints can reuse information > from previous connections when reconnecting. To improve ramp up with 0-RTT > on the server, the client and the server need to exchange and remember > additional parameters. Minimal standardization is needed to allow exchanges > of parameters during 0-RTT reconnection. > > > > We will present results on the 0-RTT-BDP at IETF109 at the QUIC WG (if > time permits). Currently, there are two different implementations (the one > of Matt and ours in picoquic). During this slot, a discussion is needed to > move towards a single specification, e.g. using either BDP_TOKEN vs > NEW_TOKEN, fully aligned with the last version of the QUIC transport draft. > > > > We have implemented the 0-RTT-BDP approach to compare the advantages of > each of the 0-RTT and the 0-RTT-BDP approach. The link with the > implementation of the current version of the draft : > https://github.com/private-octopus/picoquic/pull/1073 > > In our implementation, the client retransmits transport parameters to the > server which considers them in its ramp up algorithm. > > > > Kind regards, > > > > Nicolas and Emile > > >
