[quicwg/base-drafts] PADDING frames consume congestion window (#4415)

kixelated <notifications@github.com> Mon, 30 November 2020 23:12 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 16F3D3A074E for <quic-issues@ietfa.amsl.com>; Mon, 30 Nov 2020 15:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Level:
X-Spam-Status: No, score=-1.482 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, URIBL_BLOCKED=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 s51c9OKnCx8i for <quic-issues@ietfa.amsl.com>; Mon, 30 Nov 2020 15:12:55 -0800 (PST)
Received: from smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524AA3A0763 for <quic-issues@ietf.org>; Mon, 30 Nov 2020 15:12:48 -0800 (PST)
Received: from github.com (hubbernetes-node-ea5bcd6.va3-iad.github.net [10.48.112.69]) by smtp.github.com (Postfix) with ESMTPA id 7E219340D57 for <quic-issues@ietf.org>; Mon, 30 Nov 2020 15:12:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1606777967; bh=0HZvbV8K2UpN1e/+zOa/n1RRo4Mrn+W6XGfwl/qlrgw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=o//FhDPMHlE2RIgR6hFEEfrXKr5GVxiNT3ihTee0JmQfeWaQo0IRHwHXtShZNaVcv GSA2AXloDmLsEquG5WMjR1ef9dwYBK7HHI/wKY8NKygUV05aV9v2RR3W+1f7NGt+aw +McJ8avVEJ2sP8VdrX+u41qxGqde5MX0vFOEVxAU=
Date: Mon, 30 Nov 2020 15:12:47 -0800
From: kixelated <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZVVZBUZ4IIH7M4OLV52FOW7EVBNHHCZ3ZIFU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4415@github.com>
Subject: [quicwg/base-drafts] PADDING frames consume congestion window (#4415)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5fc57c6f79fb0_5219b4347aa"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kixelated
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/Nhk10XO1zHChvpVfO-VYidZ0MVw>
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: Mon, 30 Nov 2020 23:12:57 -0000

See [this section](https://www.ietf.org/archive/id/draft-ietf-quic-transport-32.html#section-13.2.7).

I may be missing some context, but I can only think of a single use-case involving PADDING only packets. 

A congestion control algorithm could use PADDING-only packets to fill the congestion control window when application-limited to probe for higher window values. The idea is to use PADDING packets instead of PING packets to reduce spurious ACKs, but this is flawed:

1. The aforementioned deadlock is possible.
To avoid this deadlock, PING packets need to be sent after PADDING packets, although they are susceptible to packet loss. The RFC vaguely recommends sending regular PING frames to compensate, which partially defeats the purpose of using PADDING frames.

2. This only tests the network in one direction. 
The goal is to test the network capacity before utilizing it, but the additional ACK load will not be tested. This is a problem for asymmetric links that may have capacity for PADDING packets, but do not have capacity for STREAM+ACK packets.

3. This probing only works for loss-based algorithms.
Delay-based congestion control algorithms like BBR will need explicit ACKs to measure RTT. They would use PING instead of PADDING.

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