Subject: [TLS] QUIC vs TLS1.3 initial_max_data (was RE: Updates on the "Transport parameters for 0-RTT connections" draft)

From: <[email-masked]>
Date: Tue, 9 Jul 2019 21:13:57 +0000

Hi Igor,

You are right, QUIC TLS spec maps TLS1.3  'early_data' field in the "initial_max_data" transport parameter.
I don't know the motivation. It sounds good to move transport parameters out of the TLS NewSessionTicket.

Regards
Emile

-----Message d'origine-----
De : Lubashev, Igor [mailto:[email-masked]] 
Envoyé : mardi 9 juillet 2019 19:43
À : Kuhn Nicolas; [email-masked]; IETF QUIC WG; [email-masked]'
Cc : [email-masked]'; STEPHAN Emile TGI/OLN
Objet : RE: Updates on the "Transport parameters for 0-RTT connections" draft

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.