Re: [quicwg/base-drafts] missing description of what happens when receiving an ACK for an unsent packet (#2298)

MikkelFJ <notifications@github.com> Sun, 06 January 2019 19:32 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 2E830130DC9 for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 11:32:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 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_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 QuymgBJ077Qa for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 11:32:38 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDB8130934 for <quic-issues@ietf.org>; Sun, 6 Jan 2019 11:32:38 -0800 (PST)
Date: Sun, 06 Jan 2019 11:32:37 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546803157; bh=iEizwGlJfGcEKzU/Yg7a0OPSJOQBNK11Uc3bwL9vgH0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=J5SmkpDD18WwcDkvFSwTENok1tkuarAj1chdDaXJQuqjKdi3Bkci9DjrdFpfR3VVU +BacaDn4ng78vIMJP8euefMnzeiPfIB/NvgtDUX7JfDp9sxyo6rcN2Fd6khkefte8M 6taTd4G5fcWIHMDLRQEp3qMqML8dydmlQnLlM7ME=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab75583bec061180a7d5da94f250d417c7fde5386c92cf00000001184a19d592a169ce179e2ba1@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2298/451767976@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2298@github.com>
References: <quicwg/base-drafts/issues/2298@github.com>
Subject: Re: [quicwg/base-drafts] missing description of what happens when receiving an ACK for an unsent packet (#2298)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c3257d58b749_41da3fbe02cd45c49058a1"; 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/q-S2VUEcH7-oPKeyarca2ZKNs0M>
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: Sun, 06 Jan 2019 19:32:40 -0000

@kazuho 
> I assume that endpoints would typically just drop packets carrying a PN that is deemed too old.

If an endpoint cannot prove it didn't send the packet, it should just ignore the ACK for that particular packet. The congestion controller should not be sensitive to packets that old, so the Optimistic ACK attack is harmless in this case. Dropping the entire packet containing an ACK with an old packet is likely too strong - ignoring the ACK for the packet is sufficient. If a peer continually sends ACK's for very old packets, that might go under weird behaviour similar to sending too many gaps, and an implementation could decide the peer is being too confused and close the connection with an error.

-- 
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/2298#issuecomment-451767976