Subject: RE: Updates on the "Transport parameters for 0-RTT connections" draft

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 9 Jul 2019 17:42:32 +0000

Nico, thanks for caring about clients behind high-latency links.

> The NewSessionTicket carries an additional field named 'early_data'
> that indicates to the client the maximum size of application data to
> insert in the 0-RTT message.

I see that draft-ietf-quic-tls requires use of initial_max_data instead and required "early_data" to carry no information.  See section 4.5 "Enabling 0-RTT".  Is there an advantage to use one vs the other? 

> BDP_metadata

All these parameters the client can calculate itself. You mention that the clients may actually reject BDP_metadata, if its contents seem suspect to it. So is this structure useful because some clients will be able to make use of these fields on a subsequent 0-RTT connection but would not care to implement the needed measurements themselves? Or is there some other reason?

Best wishes,

- Igor

-----------------------

From: Kuhn Nicolas <[email-masked]> 
Sent: Tuesday, May 21, 2019 9:47 AM
Subject: Updates on the "Transport parameters for 0-RTT connections" draft

Dear all, 

Following the different feedbacks on this draft, we have proposed an updated version on the "Transport parameters for 0-RTT connections". 
https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/

The draft proposes a solution where path characteristics are shared between the peers to improve the ingress traffic for 0-RTT connections.

The difference with version 01 are mainly based on the received feedback.
In short, we now a BDP_metadata structure so that various path parameters can be exposed to the client (MTU, RTT, bandwidth, loss-rate).
We have also added a section to discuss what happens when BDP is used incorrectly.

Let us know if we have any views or interest in this proposal. 

Cheers,

Nico for the authors