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

Christian Huitema <notifications@github.com> Mon, 03 September 2018 00:55 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 2FB92130DFE for <quic-issues@ietfa.amsl.com>; Sun, 2 Sep 2018 17:55:31 -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 yJORRDnjeDUd for <quic-issues@ietfa.amsl.com>; Sun, 2 Sep 2018 17:55:29 -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 9168E1286E3 for <quic-issues@ietf.org>; Sun, 2 Sep 2018 17:55:29 -0700 (PDT)
Date: Sun, 02 Sep 2018 17:55:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1535936128; bh=/qJNJgjYbzzOeZgdgPH+FuH5lFQmprT6yYWKH59NIMg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=G3b+eVhti4ZZ66VfwoI1KZ9GCrZWQMJYjK34UNYAFkWjEtqnqfpFlHgjCRa38mryc ZHMzmGOtDpRFypLT1Fc9L6WjCXdWskrXNh6dWUaVV1gHKq7ePnVQWlj+CyQ/LQgcdT dZbLJjQkI2INkizWFmN1WEqZyovTOxPAZyvn+eco=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb9776b1059c92e1550210c668850c48c7bedaf7392cf0000000117a4488092a169ce1427404b@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/417973506@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_5b8c8680b46b6_5a03fa845ad45bc38238"; 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/kZgjKneEpvqJyC_GhF2gH6cHu-M>
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: Mon, 03 Sep 2018 00:55:31 -0000

@ekr You write that "_After EOED is sent, the TLS stack tells the transport stack that further non-TLS data should be sent with the 1-RTT keys at this point_." I don't know for other stacks, but there is no such signal with Picotls. That API provides signals such as "expecting data from epoch X", "Here is data to send on epoch Y", "here is the write (or read) key for epoch X" and "all done". The signal "here is the write key for epoch 3" does not double as "and please stop sending on epoch 1". It cannot, because the epoch 1 crypto stream still has to be transmitted and acknowledged.

We could also have an interesting discussion about stream frames carried in the same 0-RTT packet as crypto frames. Should we have a different treatment depending on whether the stream frame is carried before or after the crypt frame in the packet?

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