Dear group, We have recently pushed an updated version of the 0RTT-BDP draft. https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/
In short, we have added a paragraph on the need for this draft : " [RFC9000] mentions that "Generally, implementations are advised to be cautious when using previous values on a new path." This draft proposes a discussion on how using previous values can be achieved in a interoperable manner and how it can be done safely. " Following the implementation in PICOQUIC, the draft now integrates some implementation recommendations for BBR, NewReno and CUBIC. We also include a discussion on the need for an equivalent to tcp_no_save_metrics in QUIC " This solution does not allow the client to refuse the exploitation of the BDP parameters. If the server does not want to store the metrics from previous connections, an equivalent of the tcp_no_metrics_save for QUIC may be necessary. This option could be negociable so that a client can refuse the exploitation of previous sessions. " As a reminder, we have presented deployment results of the 0RTTBDP on satellite systems at IETF111 : https://datatracker.ietf.org/meeting/111/materials/slides-111-maprg-feedback-from-using-quics-0-rtt-bdp-extension-over-satcom-public-access-00.pdf Do you have any comments ? Kind regards, Nico - on the behalf of the co-authors
