IETF Logo Mail Archive

Re: [quicwg/base-drafts] MUST ACK each ack-eliciting packet once (#3092)

MikkelFJ <notifications@github.com> Sun, 20 October 2019 10:24 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 7B526120086 for <quic-issues@ietfa.amsl.com>; Sun, 20 Oct 2019 03:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 jd_vsk5Y4ynT for <quic-issues@ietfa.amsl.com>; Sun, 20 Oct 2019 03:24:51 -0700 (PDT)
Received: from out-9.smtp.github.com (out-9.smtp.github.com [192.30.254.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424CD12003E for <quic-issues@ietf.org>; Sun, 20 Oct 2019 03:24:51 -0700 (PDT)
Date: Sun, 20 Oct 2019 03:24:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571567090; bh=Df2D6HeppB0jjhR6p2DQ1RmBJbNkOTkXWtHitkJTNZY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1pXYA5rIwV4WDgWOlB4whtqm9m6GT2zkcc8VdbOfGJyQjbIeksgejC2HeZwhNGOOi OKoa421pNPu1Nm0Xg7zfUJF39PdbpZRJ4R8hVDOZRLt8b79FZzLi6ZPpJ6sL/DtXsC pzyZuzph5Ry/KabXsIie3rjW7ERn3pf0svBXrHx4=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7SFCB4Y2PAST7C5JN3XF3IFEVBNHHB4ODZTE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3092/c544239492@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3092@github.com>
References: <quicwg/base-drafts/pull/3092@github.com>
Subject: Re: [quicwg/base-drafts] MUST ACK each ack-eliciting packet once (#3092)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dac35f27bafe_3b4a3fa2d54cd968144647"; 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/tKQeZvDS1JR3t7uBq1aR3wI6Pzw>
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, 20 Oct 2019 10:24:53 -0000

I'm a bit worried this misses the point. Ack-eliciting packets should be acknowledged yes, but so should non-ack-eliciting packets. By stating that ack-eliciting packets should be ACK'ed at least once, it is implied that this is not the case for other packets. This may be correct but not necessarily clear. For example for long transmissions where the peer does nothing but sending ACKs, not all of those ACKs will necessarily have to be ACK'ed. But what is the guiding principle for that? And, since you in this case are sending lots of ACK eliciting packets, you can easily ACK all the peers ACK's. So when would you not want to do that? A special case that could deadlock - e.g. too many ACKs to fit in a packet?

-- 
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/3092#issuecomment-544239492

v2.26.15 | Report a Bug | By Email | System Status