0-RTT connection: how to use `zero_rtt_accepted` future on client side

[KirillLykov]

Firstly, my understanding is that if I want to have benefits of 0rtt I shall not wait for zero_rtt_accepted, instead I should send transactions right after getting connection.

Secondly, as far as I understand when on client side we are using into_0rtt, returned zero_rtt_accepted might be used for the case when this future returns false to retry sending streams that I've tried sending before this future finished. That might be implemented with some channel which will hold all the data I've sent before this future resolved.

In this issue I'm trying to understand in what situation handling this case worth the added complexity to the code. I should say that in my application, loosing some streams is acceptable.

In my practice, I haven't ever had zero_rtt_accepted returning false: in all the cases I end up in the into_0rtt returning Err so I just follow normal connection path. I tried scenarios like not configured early data on server/client, server forgets all the session data, etc.

So I wonder when zero_rtt_accepted will return false and, hence, handling this case will give me much value. This is for me to understand some pitfalls and making a more informed decision about whether I should handle this event or not.

The client code in nutshell looks like the follows:

let connecting = endpoint.connect(target, &server_name)?;
let connection = connecting.await?;
// Wait for NEW_SESSION_TICKET, maybe there is a better way(?)
tokio::time::sleep(Duration::from_millis(100)).await;
connection.close(0u32.into(), b"done");
let connecting = endpoint.connect(target, &server_name)?;

let (connection, zero_rtt_accepted) = match connecting.into_0rtt() {
    Ok((connection, zero_rtt_accepted)) => {
        info!("trying 0rtt");
        (connection, Some(zero_rtt_accepted))
    }
    Err(connecting) => {
        info!("Failed to make 0rtt connection.");
        (connecting.await?, None)
    }
};

if let Some(zero_rtt_accepted) = zero_rtt_accepted {
    tokio::spawn(async move {
       if zero_rtt_accepted.await {
            info!("0rtt connection succeeded");
        } else {
            info!("0rtt rejected");
        }
    });
}

let mut transaction_id = 0;
let mut tx_buffer = [0u8; PACKET_DATA_SIZE];
generate_dummy_data(&mut tx_buffer, transaction_id, timestamp(), tx_size);
let res = send_data_over_stream(&connection, &tx_buffer[0..tx_size as usize]).await;

[djc]

0-RTT must be (usually explicitly) supported on the server, and will only work in resumed connections; that is, the server must have some context for your client that allows it to reuse old keys. Does that help?

Are you running against your own server?

[KirillLykov]

0-RTT must be (usually explicitly) supported on the server, and will only work in resumed connections; that is, the server must have some context for your client that allows it to reuse old keys. Does that help?

Are you running against your own server?

Yes, I'm using my own client/server both written using quinn. Everything works as designed.
I don't quite understand when I need to care about zero_rtt_accepted future returning false. Firstly, when this might happen.

[djc]

TLS servers can decline to allow early data (0-RTT). Quinn enables this in the server TLS configs that it provides (like via ServerConfig::with_single_cert()).

[KirillLykov]

TLS servers can decline to allow early data (0-RTT). Quinn enables this in the server TLS configs that it provides (like via ServerConfig::with_single_cert()).

I tried server_tls_config.max_early_data_size = 0; to trigger zero_rtt_accepted.await == false but instead this leads to the Err(connecting) branch for into_0rtt as in the code above.

To be clear here, I'm just trying to understand what are the risks that I'm taking when ignoring zero_rtt_accepted on client side. I myself haven't managed to trigger it to false.

[djc]

Right. It looks like the ZeroRttAccepted future return value is actually wired up to Event::Connected, so it doesn't really have anything to do with 0-RTT? Maybe @Ralith remembers how/why we put it together like this? Or you can do some git blame on the relevant Quinn code to see how we arrived at this setup and whether/how we need to update the docs.