IETF Logo Mail Archive

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

Christian Huitema <notifications@github.com> Sun, 02 September 2018 21:40 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 EB546130DE6 for <quic-issues@ietfa.amsl.com>; Sun, 2 Sep 2018 14:40:21 -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 TyfZH5ZEP0Pw for <quic-issues@ietfa.amsl.com>; Sun, 2 Sep 2018 14:40:20 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD47130DD0 for <quic-issues@ietf.org>; Sun, 2 Sep 2018 14:40:20 -0700 (PDT)
Date: Sun, 02 Sep 2018 14:40:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1535924418; bh=KKbvxxV/5ckK9hT41jxshEO/FA3p67m/y8HEpEYPJow=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cwFeI1p9S9XTTNMElqaH+KlHjqYj8KPHWKl8mpXoy1v/n4ZENdcGzF0XMJWV4X71w TlehWSG5/8SM6eT2CPqQV87F0ezXRXkeG/5wRHMjm3b/JUr8sAsk9wPqfsp09Y/b+O s3vornG9nEuowOAQaI6NsCtIrMC/Hi5VCrbJ8WsM=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab8c8c5ed84f34991a01c1d328210dcf2aef95ea0d92cf0000000117a41ac292a169ce1427404b@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/417961689@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_5b8c58c2e545d_41423ff33bcd45c42617c9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/p1PkSHvvVv-3bCAtDmV88yYPQmA>
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: Sun, 02 Sep 2018 21:40:22 -0000

We do not have a rule in the transport draft that says that clients shall stop sending more 0-RTT packets after EOED has been sent. The separation between transport and TLS prevents that. The TLS stack at some points tells the client to "please forward these bytes on the epoch=1 crypto stream". The client does not know what the bytes mean. It has no concept of EOED.

Of course, we could introduce an extra synchronization between the transport and the TLS stack. The transport could tell the TLS stack that it has sent all the queued 0-RTT packets. Or the TLS stack could somehow signal to the transport that it should not send any more 0-RTT packets -- except of course for those 0-RTT packets required to send TLS messages, or to repeat them if no ACK arrives. I am definitely not suggesting that we do anything like that.

-- 
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-417961689

v2.23.0 | Report a Bug | By Email