[EToSat] TR: New Version Notification for draft-kuhn-quic-0rtt-bdp-03.txt

Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> Thu, 11 July 2019 15:25 UTC

Return-Path: <Nicolas.Kuhn@cnes.fr>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8025120134 for <etosat@ietfa.amsl.com>; Thu, 11 Jul 2019 08:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 819P_uLBV1Zc for <etosat@ietfa.amsl.com>; Thu, 11 Jul 2019 08:25:21 -0700 (PDT)
Received: from mx2.cnes.fr (mx2.cnes.fr [194.199.174.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAFF1200F9 for <etosat@ietf.org>; Thu, 11 Jul 2019 08:25:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.63,479,1557187200"; d="scan'208";a="27889400"
X-IPAS-Result: A2FXAACYUydd/wUBeAplHAEBAQQBAQcEAQGBUwcBAQsBgWcvWRFRMygKhBKIHKVJgXsJAQEBAQEBAQEBKwkBAgEBhEACF4I9IzQJDgEDAQEBBAEBAQEDAQECAmmFAzkBC4VMAgEDIxE6CQIQAgEFEA0CBiACAgIwFRACBA4FCBODCIIKD6wrgTIahBwCDkGFM4EMKAGBYowSgRFGgwqCYQEBAgEBFoEgERgFMQKCUDKCJgSOcYUhlkkHAoEyaYIfhDmBQowJc4E5bYY3g3kDijeNM4dEkX45gVgzGicrIYJsCYs9hT9CMAGBIAiMHIExAYEgAQE
X-URL-LookUp-ScanningError: 1
From: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
To: "etosat@ietf.org" <etosat@ietf.org>
CC: "'Gorry (erg)'" <gorry@erg.abdn.ac.uk>, "emile.stephan@orange.com" <emile.stephan@orange.com>
Thread-Topic: New Version Notification for draft-kuhn-quic-0rtt-bdp-03.txt
Thread-Index: AQHVNWMDloURlhfbSkWVVr34fg3j46bAW+/QgAUyViA=
Date: Thu, 11 Jul 2019 15:24:14 +0000
Deferred-Delivery: Thu, 11 Jul 2019 15:25:14 +0000
Message-ID: <F3B0A07CFD358240926B78A680E166FF1EC1ECE7@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <156257274331.734.4411179632617138188.idtracker@ietfa.amsl.com> <F3B0A07CFD358240926B78A680E166FF1EC1C3C1@TW-MBX-P03.cnesnet.ad.cnes.fr>
In-Reply-To: <F3B0A07CFD358240926B78A680E166FF1EC1C3C1@TW-MBX-P03.cnesnet.ad.cnes.fr>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-24754.000
x-tm-as-result: No--23.828600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/mH2N6ogOo7bSwunkwUUMHXoQkZM>
Subject: [EToSat] TR: New Version Notification for draft-kuhn-quic-0rtt-bdp-03.txt
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2019 15:25:24 -0000

Hi ETOSAT, 

We have updated our draft on how to improve client and server exchanges in 0-RTT QUIC connection establishment. 
Let us (+QUIC mailing list) know if you have any views on it !

Thanks, 

Nico

-----Message d'origine-----
De : QUIC <quic-bounces@ietf.org> De la part de Kuhn Nicolas
Envoyé : lundi 8 juillet 2019 10:05
À : IETF QUIC WG <quic@ietf.org>
Cc : Gorry Fairhurst <gorry@erg.abdn.ac.uk>; emile.stephan@orange.com
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 : internet-drafts@ietf.org <internet-drafts@ietf.org> Envoyé : lundi 8 juillet 2019 09:59 À : Stephan Emile <emile.stephan@orange.com>; Emile Stephan <emile.stephan@orange.com>; Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>; Gorry Fairhurst <gorry@erg.abdn.ac.uk> 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