Re: [quicwg/base-drafts] ACK of non-existent packet is illegal (#2302)

Kazuho Oku <notifications@github.com> Tue, 08 January 2019 01:16 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 974EB130E0C for <quic-issues@ietfa.amsl.com>; Mon, 7 Jan 2019 17:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.064
X-Spam-Level:
X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 TVH90ZtvcJwN for <quic-issues@ietfa.amsl.com>; Mon, 7 Jan 2019 17:16:13 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41558130E0E for <quic-issues@ietf.org>; Mon, 7 Jan 2019 17:16:10 -0800 (PST)
Date: Mon, 07 Jan 2019 17:16:09 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546910169; bh=DCdBveILew78jXrfRcGPWBKYHa1L0xcFMsk37Vv1RrE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XMRbdm7DiTbXI+gWmUqa4HK/mC1axA+MmDswf4Y+8/CIhLdpxF02XfmNDEvA5yo3X hbbJLQ4qWjZY3EVz2I4Qp1HBMxFfGHEFeczyVn1P7yW5gYYp4iyNCtgzW2PvF94L5L 8whl961I9rFNvM3ETaoE7HBtolE2wbnv6GqxUBwE=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abc538fe63208639f5d7cdbf2e1e6bc3dae5983e6d92cf00000001184bbbd992a169ce179f2fda@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2302/review/190060318@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2302@github.com>
References: <quicwg/base-drafts/pull/2302@github.com>
Subject: Re: [quicwg/base-drafts] ACK of non-existent packet is illegal (#2302)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c33f9d93884e_95e3fbdad6d45c01759673"; 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/xRta8TSBdJeu-JupMggsXmG98LY>
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, 08 Jan 2019 01:16:16 -0000

kazuho commented on this pull request.



>  acknowledgment of its ACK frames, with the knowledge this could cause the sender
 to unnecessarily retransmit some data.  Standard QUIC {{QUIC-RECOVERY}}
 algorithms declare packets lost after sufficiently newer packets are
 acknowledged.  Therefore, the receiver SHOULD repeatedly acknowledge newly
 received packets in preference to packets received in the past.
 
+An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not
+send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect

@marten-seemann Shouldn't we be using Reason Phrase for debugging? It provides the endpoint to decide how granular the error reports can be, without requiring all the stack handle the errors the same way.

-- 
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/pull/2302#discussion_r245851457