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

Kazuho Oku <kazuhooku@gmail.com> Thu, 07 March 2019 21:03 UTC

Return-Path: <kazuhooku@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 D7F2C128701; Thu, 7 Mar 2019 13:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 bYZH_0HaG1Ij; Thu, 7 Mar 2019 13:03:56 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 541E512AF7F; Thu, 7 Mar 2019 13:03:56 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id w6so15525966ljd.7; Thu, 07 Mar 2019 13:03:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eDmylE9mlYtohSL96X7LxL82biOdafGDK7agUe00Bi4=; b=rK+a8E18L8wSDBsMPO8Bmn8Xr0tGu6SM485sP83mNnWgvyDuf48B5mX2+OsCfZJuNv rvMcDV6ApPZ2e37g9FfnT/7kHWPSSVOMXWjy0IOJOlzKv5T9FiJ+9pqx+Kxl6kRS0xs6 u7bZsQkKL3FTJl138bF89sl6IMDRx7FKL6RwLF0QX8q968gSlaJslZ2Z4GlSX7KxPR2s av86hJxnQyrmQFFro/eyOUuKUmjSieUh7riIbFfsM2oFbCSj1YEoQljs09N92VzFPAof KKVsapRzrcfNw6t8NBqbcSGSo9/KlgmFifPooP+a2VlR4I4lK3Al3aTxJvIZibNWJJ+v lWSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eDmylE9mlYtohSL96X7LxL82biOdafGDK7agUe00Bi4=; b=J8l27sUA1Afncuccf9GKQsM5BGrAOZqyKaj1g5xoG61i5+IKxRksE7XTB43SQRwz8S KHhr+CMX4E5iTQYbkuQYUawtaaRV5ua6eeK5WS11x/q3P/hnLBxcOAUNdBI4wkCZxjsg 8t3ADLrGrgDDy8KC1wkGKwOme0QvYNB8qzpOMSifJbyzhVM0vG1w4zvEvrjlQ8SHrgFF y4sTewCkKkIgZ/XiPNbLpEmOSPHeVhnAySQqcdDxo1z050AlYELvHFqfdNdpVLD9l2tq WH8D0Y78Guy+FEg5lnqUMOON/Ch/fUOkLFEw0QCZcu6XzfQ9vuZafFeh5C7qnTZwZIVt dCNw==
X-Gm-Message-State: APjAAAWi4sSsVT5VfjAqA1jEXo+ojaK+84cKu4gdB0S7+Uq/EJXj2HiE L6WmtowKQ/fap0URcANqNZcQJrpCKykBy44zRPM=
X-Google-Smtp-Source: APXvYqyLEtp8cW6FChbBXDAuCoMAg3z5vGK0EMddWmCdLS7PBQSnsCrk8OVAenMXuuEIzG3arYbqA7CiCwp8cO7+Wmo=
X-Received: by 2002:a2e:9dda:: with SMTP id x26mr6905556ljj.53.1551992634408; Thu, 07 Mar 2019 13:03:54 -0800 (PST)
MIME-Version: 1.0
References: <F3B0A07CFD358240926B78A680E166FF1EBABEF8@TW-MBX-P03.cnesnet.ad.cnes.fr>
In-Reply-To: <F3B0A07CFD358240926B78A680E166FF1EBABEF8@TW-MBX-P03.cnesnet.ad.cnes.fr>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 08 Mar 2019 06:03:43 +0900
Message-ID: <CANatvzzskCSCgZT7wZVF88eL8yHyZdZuW-WSAgXCcHaVxE77Fw@mail.gmail.com>
To: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
Cc: "quic@ietf.org" <quic@ietf.org>, "etosat@ietf.org" <etosat@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/mU_6CKlBWg_NUyWqHHHnzoAaQy0>
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 21:03:59 -0000

Thank you for writing the draft.

I think the approach is fine, though I wonder if we need to a
specification for this.

The server has the freedom to store whatever it wants in a session
ticket. Therefore, I do not see why we need to define an extension.

Also, it has been my understanding that token (sent by NEW_TOKEN
frame) is a better place for storing the RTT observed in last
connection. This is because token is a per-path information that is
updated per each path, compared to session tickets that are expected
to rarely be updated mid-connection.

2019年3月7日(木) 19:36 Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>:
>
> 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
>
>



-- 
Kazuho Oku