IETF Logo Mail Archive

Re: [quicwg/base-drafts] Why ignore MAX_STREAM_DATA or MAX_DATA that don't increase the flow control limits (#2082)

Kazuho Oku <notifications@github.com> Mon, 03 December 2018 21:40 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 BA392129BBF for <quic-issues@ietfa.amsl.com>; Mon, 3 Dec 2018 13:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.46
X-Spam-Level:
X-Spam-Status: No, score=-4.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 IikOgticre2S for <quic-issues@ietfa.amsl.com>; Mon, 3 Dec 2018 13:40:50 -0800 (PST)
Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (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 B72E9126CC7 for <quic-issues@ietf.org>; Mon, 3 Dec 2018 13:40:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=lAr3U/yhyB9SrSCkbfppdB494d4=; b=Hh7ZQcovZLjXlIad kIiglW2vbXTZh3TkwO5xouhodc/Qkeh+e97n/0NLRP4btmuvCaDARqT7C11ww5Ax oY6VNJc6tUVltIHMU7OPQ4gEFPho6vXRTVtyM1ui52X3hB9mJvUAz7aePNALVYtf ViqhaAALmfzCwegYhI+NvV7xl5I=
Received: by filter0437p1iad2.sendgrid.net with SMTP id filter0437p1iad2-4773-5C05A2E0-C 2018-12-03 21:40:48.397907051 +0000 UTC m=+1545472.126323299
Received: from github-lowworker-c7d2ff2.cp1-iad.github.net (unknown [192.30.252.32]) by ismtpd0014p1iad1.sendgrid.net (SG) with ESMTP id Z_LosGNtTRyoIXviB-musg for <quic-issues@ietf.org>; Mon, 03 Dec 2018 21:40:48.258 +0000 (UTC)
Received: from github.com (localhost [127.0.0.1]) by github-lowworker-c7d2ff2.cp1-iad.github.net (Postfix) with ESMTP id 3B1B34C0276 for <quic-issues@ietf.org>; Mon, 3 Dec 2018 13:40:48 -0800 (PST)
Date: Mon, 03 Dec 2018 21:40:48 +0000
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6ee7259180f7354744defb88cd72eeb4a08a90a792cf00000001181d64e092a169ce17082871@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2082/443880681@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2082@github.com>
References: <quicwg/base-drafts/issues/2082@github.com>
Subject: Re: [quicwg/base-drafts] Why ignore MAX_STREAM_DATA or MAX_DATA that don't increase the flow control limits (#2082)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c05a2e03973e_4b33f88cdcd45c0724a5"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1QeV/mSS24b5FUv87loidUIn8Ciimng1L9ZR JsBCt/g2owuUJqlYOmdo45FnTJcolIxVUmcmhHCW24GQqDgruhIaR7K4O6qDsfFKOt+rHI4UWmgPLG 6dc41JzUJCj/0JBxRmVBAn0Fd2HcEVwQHGXmdaETOCGF7dAyF1szuFjFUKzMiaObJgk3eSXh7ZvtLH Y=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/xBIfdqcEbR5dpOJH8PmeWuSFEa8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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 Dec 2018 21:40:52 -0000

> It's consistent with our decision elsewhere that frames which are valid when sent remain valid for the duration of the connection no matter how delayed (though they might get ignored as irrelevant).

FWIW, I am not sure if all the frames have such property; retransmitting an ACK frame is not a good idea because you would have an incorrect value in the ack delay field...

However I do agree that retransmission of MAX_* frames should be allowed. Or put it another way, I do not think that the endpoints should be mandated to detect rollback of max values in the succeeding frames and call that an error. It's something not easy to implement when reordering is involved.

-- 
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/2082#issuecomment-443880681

v2.23.0 | Report a Bug | By Email