Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)

Kazuho Oku <notifications@github.com> Tue, 14 January 2020 01:18 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 65D4F12001B for <quic-issues@ietfa.amsl.com>; Mon, 13 Jan 2020 17:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.595
X-Spam-Level:
X-Spam-Status: No, score=-6.595 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 wYUtNBo2392T for <quic-issues@ietfa.amsl.com>; Mon, 13 Jan 2020 17:18:11 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8342F120020 for <quic-issues@ietf.org>; Mon, 13 Jan 2020 17:18:11 -0800 (PST)
Received: from github-lowworker-a6a2749.va3-iad.github.net (github-lowworker-a6a2749.va3-iad.github.net [10.48.16.62]) by smtp.github.com (Postfix) with ESMTP id A162BC602D3 for <quic-issues@ietf.org>; Mon, 13 Jan 2020 17:18:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578964690; bh=JiqkcyaodxWlr6QHLr4nDCzcqNHnOjZB5Rd/EksWBiI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=RcTSb9ApjFB8Zu9g/p+JogsUMjPk+mQeTAxFr5vWyKaMZ+7mFY8aEo0nEFwh2EeMG L+dPGBH/2ykr50thpFPHzfvhDtLYmuw68d81Vrn1fHSxC96SrPbZ/S4JwZ9d/Q1rbi /J09eYbvdCRELwKx6Tz6DgGhSGaR0ydaTNIUISgw=
Date: Mon, 13 Jan 2020 17:18:10 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7AASB2FEK75AXGOY54FJEVFEVBNHHCBMO65M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3333/573952468@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3333@github.com>
References: <quicwg/base-drafts/issues/3333@github.com>
Subject: Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1d16d2921d2_30a03f7ed04cd964550e"; 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/MJbsx6LbzaYic4HbKmSE0RzKHm4>
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, 14 Jan 2020 01:18:13 -0000

This behavior should continue to be allowed. We allow endpoints to send a QUIC packet (as part of a coalesced packet) knowing that the peer would de unable to decrypt it (see [section 14.3.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-14.3.1)). The issue being discussed here is a variant of that.

That said, I am not sure if we want to suggest padding outside of a QUIC packet, because such a design might have wired implications to the CC logic. IIUC, current congestion logic is based on the following principles:
* an ack-eliciting packet consumes bytes-in-flight
* an ack-only packet does not consume bytes-in-flight
* we allow ack-eliciting packets and ack-only packets to be coalesced, because that does not change the load on the network

I am not sure how we can adjust these principles so that padding outside QUIC packets can be taken into consideration (when necessary), or if making such adjustment is worth the additional complexity.

-- 
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/3333#issuecomment-573952468