IETF Logo Mail Archive

[quicwg/base-drafts] Offload should not delay ACKs (#4001)

ianswett <notifications@github.com> Sun, 16 August 2020 19:53 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 07C483A10E3 for <quic-issues@ietfa.amsl.com>; Sun, 16 Aug 2020 12:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
X-Spam-Status: No, score=-1.483 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 9vI8RIJMbKJM for <quic-issues@ietfa.amsl.com>; Sun, 16 Aug 2020 12:53:53 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C483A10E2 for <quic-issues@ietf.org>; Sun, 16 Aug 2020 12:53:52 -0700 (PDT)
Received: from github-lowworker-cde56e0.va3-iad.github.net (github-lowworker-cde56e0.va3-iad.github.net [10.48.25.52]) by smtp.github.com (Postfix) with ESMTP id 249DC560094 for <quic-issues@ietf.org>; Sun, 16 Aug 2020 12:53:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1597607632; bh=aw1kLifNPyjXQ7fTLvCD4uzuPqbey0uJRcOZcsEnW9k=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=YsUPz37BY2cHBrGexoiOrcFWBkh+H4zAtMZjpK96eVBlid9ZoXyaeUvx4CtKHu9Fo h+JjHBewGLAPAaw71+vIVe3u7CMWVdvPCRG87OnY2jLXQXmBl5uG214ETLefyxkSDo xzfIxbKPsUytxvLO6QvhtPSuA1B6k79qvy0QxmxE=
Date: Sun, 16 Aug 2020 12:53:52 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2K7OUZVK2RL3UF2455IVX5BEVBNHHCRBJH34@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4001@github.com>
Subject: [quicwg/base-drafts] Offload should not delay ACKs (#4001)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f398ed014c93_11c419643518ce"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/LMAVJyNc2kPEaCnXPskEcafX1Ik>
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, 16 Aug 2020 19:53:55 -0000

The existing text mostly covers this, but I don't think it's always as clear as it could be.

If one is doing various offloads(pacing/crypto/etc) and those cause the sender to decide to send a batch of packets at once, the sender should not have to wait until all those packets are released to send an ACK.

The simple way to think about this is "ACK-only packets don't affect acknowledgement behavior", which matches with TCP and most of our existing text.

I think this will end up being editorial and I believe the only clarification necessary is #4000 but I'd appreciate other peoples thoughts on whether this is something worth thinking about and whether there are any other changes necessary.

-- 
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/4001

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