IETF Logo Mail Archive

Re: [quicwg/base-drafts] Reduce restrictions on valid RTT samples (#2568)

MikkelFJ <notifications@github.com> Tue, 09 April 2019 05:15 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 75C27120048 for <quic-issues@ietfa.amsl.com>; Mon, 8 Apr 2019 22:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Level:
X-Spam-Status: No, score=-8.002 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 mcrqsADvQ8MP for <quic-issues@ietfa.amsl.com>; Mon, 8 Apr 2019 22:15:34 -0700 (PDT)
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 7D7FD12017D for <quic-issues@ietf.org>; Mon, 8 Apr 2019 22:15:33 -0700 (PDT)
Date: Mon, 08 Apr 2019 22:15:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1554786932; bh=6C4VnP5cf6oWyp5SaWF7hCeeajmnDox0m0MpMal7VXc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PLLPhOIl9xEF2S8dVDaiEDVfG/8mC9E63t2WGM+V8jo8XNjReLhllRA4+Hs8yq9jJ cAsizimEO+X/hSrEQH12ptOqsrrD/SoJa6zDTH7sr93sawRUUI9Vp7Uxg8MvcLfRiq GUlaf6dMC2GTo71qweQd/k3VLgyLpqxMAuQnWbAg=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abdcd7f303b40d7bb492040aa3afc464091d40213192cf0000000118c3ec7492a169ce19787a10@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2568/481105223@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2568@github.com>
References: <quicwg/base-drafts/issues/2568@github.com>
Subject: Re: [quicwg/base-drafts] Reduce restrictions on valid RTT samples (#2568)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cac2a74330a2_3d0b3fc7d5cd45c41527e8"; 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/4KcCsRyYjX7nbtO2GPVoAvuvXGA>
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, 09 Apr 2019 05:15:36 -0000

> The problem here is that a peer might decide to piggyback an ACK frame with some other stuff it is about to send (MAX_STREAM_DATA perhaps). That could result in an ACK frame that acks only non-ack-eliciting packets. It seems unnecessary to put the burden on a peer to not send this ack. It's just as easy to ignore such acks when received.

There is the interesting derived effect that if you do not ACK non-ack-eliciting packets, this could be used as optimistic ack attack mitigation. This means that you can avoid gaps in the packet number space. You could periodically coalesce non-ack-eliciting packets with other packets as necessary.

The problem is of course that the receiver needs to track those gaps, but I'm not sure that is much different than what it already needs to track.

-- 
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/2568#issuecomment-481105223

v2.23.0 | Report a Bug | By Email