Re: [quicwg/base-drafts] are flow control frames really idempotent? (#1612)

MikkelFJ <notifications@github.com> Tue, 31 July 2018 09:22 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 96C25130E1A for <quic-issues@ietfa.amsl.com>; Tue, 31 Jul 2018 02:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level:
X-Spam-Status: No, score=-3.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_NONE=-0.0001, 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 OJ5Rm2e-P3Sm for <quic-issues@ietfa.amsl.com>; Tue, 31 Jul 2018 02:22:37 -0700 (PDT)
Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (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 A4F6F130E08 for <quic-issues@ietf.org>; Tue, 31 Jul 2018 02:22:37 -0700 (PDT)
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=umbchjO7A7mg55XnPgbEt+of+vY=; b=mtJJFpYjY6s6y93l 1GOqky7ybmqW4PpQOgI/HZWsabaVHjLR3wSe5vXTAWgxIThcRH/tk8AmE95xmPSW jnaHe9qP1NTj8x5b6jDjH2KAx3/bs2HDTC8VXzeproMk4TCx4z6kvO/DknYyTdfD eTH6PX4yq7cIOZihoixhzmFPg0I=
Received: by filter1120p1las1.sendgrid.net with SMTP id filter1120p1las1-18735-5B602A5C-5 2018-07-31 09:22:36.135068812 +0000 UTC m=+471903.353275358
Received: from github-lowworker-d2dd71d.cp1-iad.github.net (unknown [192.30.252.33]) by ismtpd0003p1iad2.sendgrid.net (SG) with ESMTP id 3z5mGzZnSfGApOvuysx6xg for <quic-issues@ietf.org>; Tue, 31 Jul 2018 09:22:36.001 +0000 (UTC)
Received: from github.com (localhost [127.0.0.1]) by github-lowworker-d2dd71d.cp1-iad.github.net (Postfix) with ESMTP id 0768A881D4F for <quic-issues@ietf.org>; Tue, 31 Jul 2018 02:22:36 -0700 (PDT)
Date: Tue, 31 Jul 2018 09:22:36 +0000
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe086b640df87be8a4b235335a4e5eb39aa78ade392cf000000011777ec5b92a169ce149fd7cc@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1612/409155257@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1612@github.com>
References: <quicwg/base-drafts/issues/1612@github.com>
Subject: Re: [quicwg/base-drafts] are flow control frames really idempotent? (#1612)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b602a5c5548_3bba3fcd5debe618153112"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak0g1e2voqp051gg16Cq0jyq87aClD0GjQe63W lwziytW0FlBn74GeiWRyfP/zpAa759kiGB24FeXM4MJ4ntnUGsb2NPL5DWMguLneeu6NQ9qHcKn2kf 28Tgul8gDEUyahsP3Sqgt2Qm1E37YmUFUdEqcy0FvOjU6RU2ONKYPSFdsQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/J4T6I0-WvZJiz21Vm67mPTZGGWg>
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: Tue, 31 Jul 2018 09:22:40 -0000

I think it is pretty clear that later recieved lower numbered limits should be ignored or result in a protocol error - or ignore if the reciever cannot be bothered to check.

If it is explicitly required that limits are increased monotonically, it is protocol error, otherwise it is a ignore.

>From a quick read over the spec, I can't see that there are rules thay enforce that limits cannot be reduced sender size?

While it makes sense to transmit the largest limit on retransmission there are cases where this is not ideal because it can require synchronization. The same applies to packet numbers which must increase, but the more values that must be in sync, the harder it becomes to do parallel processing or to have separate responsibilities.

As to being helpful - I don't think the receiver should fix sender bugs - the most helpful thing is a hard protocol error, log output and a friendly email to the responsible dev team. If bugs starts to get worked around, ossificiation will ensue at scale. In this particular case it may not even be a bug, but a deliberate synchronizatin artefact.


-- 
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/1612#issuecomment-409155257