[quicwg/base-drafts] SETTINGS synchronization (#75)
Mike Bishop <notifications@github.com> Mon, 05 December 2016 21:50 UTC
Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 8EB98129DDB for <quic-issues@ietfa.amsl.com>; Mon, 5 Dec 2016 13:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.579
X-Spam-Level:
X-Spam-Status: No, score=-5.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 nXkRyDGBwu1x for <quic-issues@ietfa.amsl.com>; Mon, 5 Dec 2016 13:50:30 -0800 (PST)
Received: from o4.sgmail.github.com (o4.sgmail.github.com [192.254.112.99]) (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 EF0EF1295AA for <quic-issues@ietf.org>; Mon, 5 Dec 2016 13:50:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=github.com; h=from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=5xrG3Oolrj0wAzCbcWH4+ts9z1c=; b=nbWnsSve+n7Daod7 aHTRLy585zt9P1NIpejCgPgHprVI5d9AcgzUN4jvrL8oAEAhNE9OaGs3EQPz1AiG ldof/kiwOQMcJAKMa/5c3N6DD3PRJAu9lWtTJSJXKqMcaRkFkAPT4u6RY1bDi6RN 8An72gn9oORVORC8J2dWaXNGHRc=
Received: by filter0910p1mdw1.sendgrid.net with SMTP id filter0910p1mdw1-16859-5845E113-61 2016-12-05 21:50:11.94821823 +0000 UTC
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id LQyxlAO_RY6KBpNo2PBiaA for <quic-issues@ietf.org>; Mon, 05 Dec 2016 21:50:11.975 +0000 (UTC)
Date: Mon, 05 Dec 2016 13:50:11 -0800
From: Mike Bishop <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/75@github.com>
Subject: [quicwg/base-drafts] SETTINGS synchronization (#75)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5845e113d32ea_2a773fc169d2f130689473"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3bG3rPpNbk5/sDf03RA+vgmwGuJRkPRQIt/O Y6d12gaQtjjjIqCwznMS6I1UBg3rViWJ/zy0Vp6+X6OJ4uFLV5z4nDwLiWLWpDPVsEAO28DU/FOQED Waw3QnYLPypPAzRr2frn7b8EIiRsE5I3RW1udDptoI9kmkgsfRYKJ2rFUXg6Unch+XBbcAts2eMLao w=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/GXZQ9rS1cnJ22I0VE8alNGdVoTg>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quicwg/base-drafts <reply+0166e4ab22813ecbfad62cd539d6f4319ba6958607c7bb4192cf00000001145da31392a169ce0b8a677a@reply.github.com>
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, 05 Dec 2016 21:50:31 -0000
In HTTP/2, SETTINGS provokes an empty SETTINGS frame with the ACK flag sent. In the EXTENDED_SETTINGS proposal, there's a separately-defined SETTINGS_ACK frame. Either way, there's a way to know when changes have been applied. If we need this in QUIC, with no defined ordering between bytes on different streams, we would need to ACK on every still-open stream. (Ick.) But of course, we also can't know which streams were already closed or not yet open at the time the SETTINGS frame was received, so we can't *enforce* that on the receiver. Do we need a SETTINGS epoch in every HTTP frame? (Ick.) Or simplify and say that SETTINGS just aren't ACKed over QUIC? -- 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/75
- [quicwg/base-drafts] SETTINGS synchronization (#7… Mike Bishop
- Re: [quicwg/base-drafts] SETTINGS synchronization… Mike Bishop
- Re: [quicwg/base-drafts] SETTINGS synchronization… Mike Bishop
- Re: [quicwg/base-drafts] SETTINGS synchronization… Mike Bishop
- Re: [quicwg/base-drafts] SETTINGS synchronization… Mark Nottingham