Re: [quicwg/base-drafts] Recovery: when PTO expires and no data to send (#3286)

ianswett <notifications@github.com> Fri, 06 December 2019 14: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 38A7E120041 for <quic-issues@ietfa.amsl.com>; Fri, 6 Dec 2019 06:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_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 V7_bgqOWnrQ0 for <quic-issues@ietfa.amsl.com>; Fri, 6 Dec 2019 06:09:24 -0800 (PST)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888BC12080A for <quic-issues@ietf.org>; Fri, 6 Dec 2019 06:09:24 -0800 (PST)
Date: Fri, 06 Dec 2019 06:09:23 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1575641363; bh=YNGq5LuY6gHJgmLto6SeKFiR36X+ajHVZ0Ea3WZ/VzY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=y0gROpqQbeLv0cV5JgBvEjYKrWLVGYA0Ea70fdo9NV/gp6ZRK7UQ4WSEJntamjaa2 RWpwTBH9vDhP3yAUU4/8xrYMDTp7wDiqlz3hOtOTeZiokRZ3rxWXm80u6lPy+MNotI zvDa2MQfdH05sy8IQOZrvTUibGVgcfVEKnCRDuF8=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2IYFVVTK2WZKQA6KN366JZHEVBNHHB7TTTBI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3286/562585251@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3286@github.com>
References: <quicwg/base-drafts/issues/3286@github.com>
Subject: Re: [quicwg/base-drafts] Recovery: when PTO expires and no data to send (#3286)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dea611377ec5_58123fbb458cd9682016c4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/sKIChAx_quQX2Bn4oSb1HFv5InE>
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, 06 Dec 2019 14:09:27 -0000

> > This exponential backoff of PING packets is less wasteful than a TCP RTO
> 
> Do you mean TCP PTO, not RTO?

TCP does't have PTO, but the exponential backoff of RTO is most similar to PTO.
> 
> > In order to detect persistent congestion correctly, you'll likely need to send multiple PINGs in this case.
> 
> I agree the use case of persistent congestion, but if we detect persistent congestion (collapsing cwnd) by consecutive PINGs, is it over-reacting to cwnd because there is no real data sent?

In QUIC, a PING packet and a packet containing data are equivalently useful from loss detection  and congestion control perspectives, so I don't think it matters whether data is sent.


The text in Section 5.3.1 of recovery says:
  "Alternatively, instead of sending an ack-eliciting packet, the sender
   MAY mark any packets still in flight as lost.  Doing so avoids
   sending an additional packet, but increases the risk that loss is
   declared too aggressively, resulting in an unnecessary rate reduction
   by the congestion controller."

So the suggestion you're describing is permitted, but it's not the recommended behavior.

-- 
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/3286#issuecomment-562585251