IETF Logo Mail Archive

Re: [quicwg/base-drafts] Make EOED transmission optional in QUIC, please (#1518)

Kazuho Oku <notifications@github.com> Thu, 12 July 2018 00:05 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67C130E73 for <quic-issues@ietfa.amsl.com>; Wed, 11 Jul 2018 17:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 HE65lLn1k_8s for <quic-issues@ietfa.amsl.com>; Wed, 11 Jul 2018 17:05:27 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283C5124BE5 for <quic-issues@ietf.org>; Wed, 11 Jul 2018 17:05:27 -0700 (PDT)
Date: Wed, 11 Jul 2018 17:05:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1531353926; bh=+mkmYF2MPTyiLacV0ue81bMEQR2Wp2zA6EhXZie3fKA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XPlqfdNSLg0d2gTu8Eus++1WJzeqWryiXH9UJ1jV6LYGGIrUxkayWmwFu+1b9nTTm b34/aTkK4KeyM70TKxrID2SKLBCz3oe1PxNci3G7AZnp0pd0wHGUQdPMVBJ/otonLI tN4jU+W1E6whniEOaisg+X7UIDSzyOq6icW5KuIY=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab9e06dd9a536e947aec2c3b85745d63785db7421692cf00000001175e5d4692a169ce1427404b@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1518/404347844@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1518@github.com>
References: <quicwg/base-drafts/issues/1518@github.com>
Subject: Re: [quicwg/base-drafts] Make EOED transmission optional in QUIC, please (#1518)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b469b462c277_67bc3fa29c972f88585d8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/A8JA2JjzYOvLHZz2o9-sgzyQ-q8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 00:05:30 -0000

I do not think that the requirement to send EOED using a 0-RTT packet is complex enough to justify the changes to the TLS handshake transcript.

My understanding is that TLS stacks emits EOED when 1-RTT write key becomes available (otherwise in TLS over TCP a client will have a moment when it cannot send any data, which is silly). 1-RTT read key will be available at that moment, so you can always be certain that you can receive an ACK for EOED.

In other words, retransmission is not an issue.

Note also that clients have the freedom to continue retransmitting 0-RTT packets with application data even after receiving the 1-RTT write key. That is what TLS over TCP exactly does.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1518#issuecomment-404347844

v2.40.3 | Report a Bug | By Email | System Status