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

Nick Banks <notifications@github.com> Mon, 08 April 2019 14:57 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 88687120154 for <quic-issues@ietfa.amsl.com>; Mon, 8 Apr 2019 07:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 s6on1slA4khV for <quic-issues@ietfa.amsl.com>; Mon, 8 Apr 2019 07:56:58 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89186120026 for <quic-issues@ietf.org>; Mon, 8 Apr 2019 07:56:58 -0700 (PDT)
Date: Mon, 08 Apr 2019 07:56:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1554735417; bh=NTWO+0G/ivV7vF3Rt0fRFWl+yoeoW6d7tPFkiDtEtxM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=U+EgyJRlF2hZ7bVlm0XQ1xsWeYcricpBQjdpyUxaqBqeCbsyZ8xeY7oNLpzXapmAv q2ylXj6tPx0FyO4bZQJxkQcjBWpyop3lVgTjD2In2v2pqa0LYM8rQ5ATR+xF3PDf5i Z12H1U9UOQajEEFl2l/TD59qOg6Tip/7V05DRv7I=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe0dc5944a395af75197ff5b2048a78ff97292dfc92cf0000000118c3233992a169ce19787a10@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/480867509@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_5cab6139ec44_4d03fb5d4ad45c03273d3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/x2TaBfBmTDU94lNggMIWoMFsFi0>
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, 08 Apr 2019 14:57:01 -0000

I disagree that we shouldn't be acknowledging non-ack-eliciting packets as the largest_ack. We should always be sending the most up to date information available? @marten-seemann why don't you track the non-ack-eliciting packets? They shouldn't be very high in number or really structurally different from other packets? It seems like an unnecessary optimization that would just cause you more problems in this scenario.

-- 
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-480867509