Re: [quicwg/base-drafts] PTO probes are sent too frequently (#3546)

Tatsuhiro Tsujikawa <notifications@github.com> Fri, 27 March 2020 13:09 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 5DFFC3A0883 for <quic-issues@ietfa.amsl.com>; Fri, 27 Mar 2020 06:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 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_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 RFeroH7MYVbr for <quic-issues@ietfa.amsl.com>; Fri, 27 Mar 2020 06:09:05 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FD63A0875 for <quic-issues@ietf.org>; Fri, 27 Mar 2020 06:09:04 -0700 (PDT)
Received: from github-lowworker-2ef7ba1.ac4-iad.github.net (github-lowworker-2ef7ba1.ac4-iad.github.net [10.52.16.66]) by smtp.github.com (Postfix) with ESMTP id 2AA4F1C0A0A for <quic-issues@ietf.org>; Fri, 27 Mar 2020 06:09:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585314544; bh=Vdat4hnLOPVWuMZ4ausp2LoQmGSBhf4upqxfsWpnOWc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rdF2KY7Tas6713AH26+yVkf1iweFSy1Wyv2PIm6sMB+qbMArhU0cMhmYHVMxc2VNs ReMM+WrpRuBVI+WHZuw02Tn+KxR0JZAzsTzVCpTLV3nHg9+TWNcjVhXWAiYiVm6KU6 KIW8/gPKDNFJnw/zCAL9kptzN/CGehRvru2+PvNo=
Date: Fri, 27 Mar 2020 06:09:04 -0700
From: Tatsuhiro Tsujikawa <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7I4RV6OPB55FCEDTN4RHN7BEVBNHHCGDM7NY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3546/604991033@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3546@github.com>
References: <quicwg/base-drafts/issues/3546@github.com>
Subject: Re: [quicwg/base-drafts] PTO probes are sent too frequently (#3546)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7dfaf019789_6d5b3faf112cd9682303c1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tatsuhiro-t
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/76RzcIU2h97QX_yWkb-iyyS9o2g>
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: Fri, 27 Mar 2020 13:09:07 -0000

Does it make simpler if we reset pto_count only when ack-eliciting not pure probe packet (which includes lost data or new data, not just PING) is received without special casing for anti-deadlock packet?   This ensures that pto_count is reset only when endpoint has made a progress and delaying consecutive PTO if it only receives ACK for pure probe packet.  Server might be in the same situation if client somehow only sends ACK frame in Initial and server keeps sending Initial packet in PTO


-- 
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/3546#issuecomment-604991033