Re: [quicwg/base-drafts] PLPMTUD section claims that PADDING frames generate ACKs (#1827)
MikkelFJ <notifications@github.com> Tue, 02 October 2018 20:58 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 5A806131113 for <quic-issues@ietfa.amsl.com>; Tue, 2 Oct 2018 13:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.435
X-Spam-Level:
X-Spam-Status: No, score=-8.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=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 1cyXrRcs2lxx for <quic-issues@ietfa.amsl.com>; Tue, 2 Oct 2018 13:58:28 -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 36C4F1310E3 for <quic-issues@ietf.org>; Tue, 2 Oct 2018 13:58:28 -0700 (PDT)
Date: Tue, 02 Oct 2018 13:58:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538513907; bh=9A+qQP3Ad9j60oEdjKGoy+JJxEQ4ZhYfraCakzuIkbk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=k+95n2ekZtY/FQrdFtOwp3qIBWVIGVS/5wZVv2iI1mXak+oEfDq4aV+VijPawoW8t 7PIkBTGAf/yEAmXq+e8UfGvk9s7IKjnAl0bpH/7Kp8BEYIlcHRlA6HluuAcV5Kkdj3 Zqs0m6k7i1na0fYhtmiDnS9czn6T6Z4tbG2KkoBY=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab9d9400b0443859aeaaa7e1bae8568f418747f94c92cf0000000117cb9df392a169ce15d1d968@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1827/426427801@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1827@github.com>
References: <quicwg/base-drafts/issues/1827@github.com>
Subject: Re: [quicwg/base-drafts] PLPMTUD section claims that PADDING frames generate ACKs (#1827)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb3dbf311936_57ff3fe309ad45b82881a3"; 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/oTcruYWurVmEmuQCOjAc9V0A-jA>
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: Tue, 02 Oct 2018 20:58:30 -0000
I think the 8.1 section is reasonably clear > To avoid creating an indefinite feedback loop, an endpoint MUST NOT send an ACK frame in response to a packet containing only ACK or PADDING frames, even if there are packet gaps which precede the received packet. The endpoint MUST acknowledge packets containing only ACK or PADDING frames in the next ACK frame that it sends. but the next paragraph could be misread even if it is correct: > While PADDING frames do not elicit an ACK frame from a receiver, indeed it does not elicit ACK's, meaning that receiving PADDING does not trigger the peers urge to ACK incoming packets. Only when non-ACK, non-PADDING packets are received, will an ACK be transmitted (and possible during tail loss probe - not sure about 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/1827#issuecomment-426427801
- [quicwg/base-drafts] PLPMTUD section claims that … Andrew Macedonia
- Re: [quicwg/base-drafts] PLPMTUD section claims t… MikkelFJ
- Re: [quicwg/base-drafts] PLPMTUD section claims t… Martin Thomson