Re: [nwcrg] TR: New Version Notification for draft-kuhn-quic-0rtt-bdp-03.txt - implications for COINRG and NWCRG

[Marie-Jose Montpetit <[e-mail]>]

Me the dual hat person again:

Hi the draft below could have interest to both the nwcrg and the coinrg as:
1. nwcrg: there is already work on QUIC and NC that wants to be adaptive
and negotiated; this is very much in line with the protocol part of the work
2. coinrg: as we deal with the impacts of encryption on computing in the
network and the potential use of QUIC proxies negations will also be
important. We have a milestone on how to link coin

I did not send this message to the QUIC mailing list but if you think it’s
useful I can :)

mjm


-----Message d'origine-----
De : QUIC <[e-mail]> De la part de Kuhn Nicolas
Envoyé : lundi 8 juillet 2019 10:05
À : IETF QUIC WG <[e-mail]>
Cc : Gorry Fairhurst <[e-mail]>; [e-mail]
Objet : TR: New Version Notification for draft-kuhn-quic-0rtt-bdp-03.txt

Hi,

We have updated our draft on "Transport parameters for 0-RTT connections".
In short, the proposal of the draft is the following:
While each client and server can have its
dedicated solution to store path parameters, having a standard way of
exchanging this information helps in providing symmetrical control of
the optimisation and reducing protocol ossification. [...]

This memo discusses a solution where the client is informed about
path parameters: both the client and the server can contribute to the
reduction of the time-to-service for subsequent connections. This
would improve symmetrical transmission of data and reduce
ossification of the protocol.

Please let us know if you have any views on this proposal.

Cheers,

Nico


-----Message d'origine-----
De : [e-mail] <[e-mail]> Envoyé : lundi 8
juillet 2019 09:59 À : Stephan Emile <[e-mail]>; Emile
Stephan <[e-mail]>; Kuhn Nicolas <[e-mail]>;
Gorry Fairhurst <[e-mail]> Objet : New Version Notification for
draft-kuhn-quic-0rtt-bdp-03.txt


A new version of I-D, draft-kuhn-quic-0rtt-bdp-03.txt has been successfully
submitted by Nicolas Kuhn and posted to the IETF repository.

Name: draft-kuhn-quic-0rtt-bdp
Revision: 03
Title: Transport parameters for 0-RTT connections
Document date: 2019-07-08
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/internet-drafts/draft-kuhn-quic-0rtt-bdp-03.txt
Status: https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/
Htmlized: https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-03
Htmlized: https://datatracker.ietf.org/doc/html/draft-kuhn-quic-0rtt-bdp
Diff: https://www.ietf.org/rfcdiff?url2=draft-kuhn-quic-0rtt-bdp-03

Abstract:
The time-to-service duration depends on both peers and the peer
initiating the connection may not be the peer actually sending data.
Moreover, clients may be resource-limited, behind a low bandwidth or
a long-RTT network and may need adaptations to improve data
transmission or reception. While each client and server can have its
dedicated solution to store path parameters, having a standard way of
exchanging this information helps in providing symmetrical control of
the optimisation and reducing protocol ossification. QUIC may not be
limited to HTTP3: it can be used as a substrate for proxying and
tunneling.

This memo discusses a solution where the client is informed about
path parameters: both the client and the server can contribute to the
reduction of the time-to-service for subsequent connections. This
would improve symmetrical transmission of data and reduce
ossification of the protocol. To improve the time-to-service of
subsequent 0-RTT reconnection the server currently sets in the
early_data extension the maximum volume of egress data the client is
allowed to send when reconnecting. This memo proposes BDP_metadata,
an additional extension, to also inform the client about path
parameters.




Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat