Subject: Re: [0-RTT-BDP] Preparing IETF109 Discussion

From: Ian Swett <[email-masked]>
Date: Mon, 9 Nov 2020 02:02:29 -0500

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-masked]> 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
>
>
>

---

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 9 Nov 2020 10:08:47 +0000

De : Ian Swett <[email-masked]>
Envoyé : lundi 9 novembre 2020 08:02
À : Kuhn Nicolas <[email-masked]>
Cc : IETF QUIC WG <[email-masked]>
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-masked]<mailto:[email-masked]>> 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