Re: [EToSat] Transport in 0-RTT connections for high BDP

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 07 March 2019 12:03 UTC

Return-Path: <mikkelfj@gmail.com>
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 CD4891313A9; Thu, 7 Mar 2019 04:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XuJX6donvRZf; Thu, 7 Mar 2019 04:03:49 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A33012785F; Thu, 7 Mar 2019 04:03:49 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id p196so13222993iod.9; Thu, 07 Mar 2019 04:03:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=lnJ5sPcSb4dga6Znrw8Ms+bpFbRcE3L0NsM/3BU/R5Q=; b=t5wNFR5c36ql1eE4LAC6gQyCr0dDevzthhtAktxMaABd+DFBiVP5MNWKecYlpWONiF VaI3vXzd9lJvQ5LZ1xjiOSx3W4RrvPvJRB20TBnIMdzK+PLwOj6l4QqQfAkgRW+rjxyu WCNJwPZSEqfEBVO5zDkzI1MFZhGDgt6enJMa2skyo6Sv/oYcPKQ+b5qAduhqoN7ow+4z C/GUZrbUtuWtLdCdl9bEgx/FaPy9w9gXiQ4887a+MqKg2n2iY2H4JGblmvtx2bERVGN4 5vkQW5ELBlJmxHo1cGV2BvKyYm3HDgT03LSfnGIjBT3AAxEwiVhbx6iZWV7wIDIYwvJ6 O8GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=lnJ5sPcSb4dga6Znrw8Ms+bpFbRcE3L0NsM/3BU/R5Q=; b=D8dqfUbrVvQ7lb8lAtUcanWdc4ksiEMaHmQi73D4/+tu2zz9Fjp8p4ZKM6H7rp0NNp 2CEMZmIh2tCkVUDwe5XwvZ9NM41OVPFDVhp1nQHC0yEVdNKVsYVw6v1p0KWiQZ1dFszt c9/nvmBSdkcZLnj+7xqt7TCZ4RcYZP+2k+3J/7Bwqw5FS6UKnCFnvc8IOmp0S6wyQMZb CSqPDEVL5LpL92c/hqkdzDfFi1XLrTTOVgbymZzjBU4bqkCL4ayv+WPfqfazDNbyk4jA PlMhDvDDkGyA55CNV96CHYp8TS8a+F1uMTxSJAvT5nH19vTFxMV+urNvfz8r4I71JRFF /0Ww==
X-Gm-Message-State: APjAAAUMIqViMGrJhqVKsDr+FNLXTlfcMKIQSrmiCm0DUsOdJ6M8IG6F W5o5jA3Ee4k2um3HrVSpokpRjEjJyruCj+D6hMNx5g==
X-Google-Smtp-Source: APXvYqyXxVaCWeO6J/mlidNz0g3hQ8PHQzOo4578yMjTFzstTu5PUklIs9zsPOtATs1II8/YkJXGSDyeYyQjTLY9//0=
X-Received: by 2002:a6b:c889:: with SMTP id y131mr6355849iof.106.1551960228253; Thu, 07 Mar 2019 04:03:48 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 7 Mar 2019 13:03:47 +0100
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <F3B0A07CFD358240926B78A680E166FF1EBABEF8@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <F3B0A07CFD358240926B78A680E166FF1EBABEF8@TW-MBX-P03.cnesnet.ad.cnes.fr>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 07 Mar 2019 13:03:47 +0100
Message-ID: <CAN1APde09k5rw678dSjvCofr_syeBNGdGpLm7AfBsHtk6ag=Ww@mail.gmail.com>
To: "quic@ietf.org" <quic@ietf.org>, Kuhn Nicolas <nicolas.kuhn@cnes.fr>
Cc: "etosat@ietf.org" <etosat@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c51d905837fe665"
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/aK1Oqqf2drjQyTbT5DNfFCqGEZk>
X-Mailman-Approved-At: Thu, 07 Mar 2019 07:21:02 -0800
Subject: Re: [EToSat] Transport in 0-RTT connections for high BDP
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, 07 Mar 2019 12:03:52 -0000

I find BDP_value as bits per second confusing because BDP means bandwidth
delay product so I would expect it to be multiplied by RTT.
The text could use some practical examples and implementation guidelines.

That said, I think the bandwidth, the connection RTT, the ticket timestamp,
and perhaps the PMTU are all good things to have available to an 0-RTT
session, and perhaps should be made mandatory either in the ticket or in
the stored transport parameters to the extend this is not already the case.
This avoids having an extension. An accompanying document could explain how
to handle high BDP connections based on the available values.

On the other hand, a client could be caching these data along with a
session ticket based on knowledge gained from a previous connection, so
perhaps it it is not really an issue other than explaining best practices?

On 7 March 2019 at 11.36.49, Kuhn Nicolas (nicolas.kuhn@cnes.fr) wrote:

Hi,



We have uploaded a draft that describes a solution to improve QUIC’s
performance during 0-RTT establishment in a high BDP context.

https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-00



Abstract



   0-RTT is designed to accelerate the throughput at the establishment

   of a connection.  There are cases where 0-RTT alone does not improve

   the time-to-service.



   This memo discusses a solution where a fundamental characteristic of

   the path is learned during the 1-RTT phase and shared with the 0-RTT

   phase to accelerate the initial throughput during subsequent 0-RTT

   connections.



Would it be possible to have a small slot to present it during the next
IETF meeting?



Kind regards,



Nico & Emile