De : Ian Swett <[email protected]> Envoyé : lundi 9 novembre 2020 08:02 À : Kuhn Nicolas <[email protected]> Cc : IETF QUIC WG <[email protected]> Objet : Re: [0-RTT-BDP] Preparing IETF109 Discussion
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? [NK] I would tend to agree that the way QUIC would use such information is more of the TSVWG scope. The intention is to share such information in a standard way between peers – not standardizing the reaction that is done by each implementers even if recommendations could be envisioned. 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]<mailto:[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
