Return-Path: 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 73126120041 for ; Wed, 12 Feb 2020 15:54:39 -0800 (PST) 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_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 s7EYsu_DlGqq for ; Wed, 12 Feb 2020 15:54:37 -0800 (PST) Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A44512002F for ; Wed, 12 Feb 2020 15:54:37 -0800 (PST) Received: from github-lowworker-5fb2734.va3-iad.github.net (github-lowworker-5fb2734.va3-iad.github.net [10.48.19.27]) by smtp.github.com (Postfix) with ESMTP id 8D64352002D for ; Wed, 12 Feb 2020 15:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581551676; bh=aTf/XTdQUo+ycRoHWKkJf629VvGLRHbA4RlKlSDBpRY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=x8vJtLZY2RYrCpbJoUnHdrd85QnmKs3hxQ8ySKF46hVHwBlS4QhFQ0jucXwHYXtSg ebCJdXFf3ZErC+5KxIDjusU+3dQWkqwlxnlGSZg+KWY5DVGdL1mi4OMi2ZZg3j11tb W4SHHGiOKuz4VSUnoGkHsMcASVoHBnxBXOMq6jxE= Date: Wed, 12 Feb 2020 15:54:36 -0800 From: Jana Iyengar Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Should we allow ACK-only packets to be declared lost? (#3451) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5e44903c7d8b4_552d3faf188cd960767e6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: janaiyengar X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 23:54:39 -0000 ----==_mimepart_5e44903c7d8b4_552d3faf188cd960767e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thank you, @kazuho, for raising a point that I had completely forgotten! I remember now why I had not wanted ACK loss to drive the congestion controller. I think @kazuho and @ianswett are saying similar things, but the short of it is this: the congestion controller assumes that cwnd amount of data is in flight when it reacts to loss, reducing the cwnd. However, the cwnd has nothing to do with the amount of ACKs that are in flight, and as a result, the reduction of the cwnd in response makes no sense in this case. (It does make an increasing amount of sense to use as the traffic in this direction is increasingly dominated by ack-eliciting data, but that also makes it increasingly likely that a congestive loss will be of an ack-eliciting packet.) We should not change the design here. I'm fine with @ianswett's proposed addition, but I don't think we should use the loss of ACKs as a congestion signal that affects the congestion window. -- 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/3451#issuecomment-585478025 ----==_mimepart_5e44903c7d8b4_552d3faf188cd960767e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you, @kazuho, for raising a point that I had completely forgo= tten! I remember now why I had not wanted ACK loss to drive the congestio= n controller. I think @kazuho and @ianswett are saying similar = things, but the short of it is this: the congestion controller assumes th= at cwnd amount of data is in flight when it reacts to loss, reducing the = cwnd. However, the cwnd has nothing to do with the amount of ACKs that ar= e in flight, and as a result, the reduction of the cwnd in response makes= no sense in this case.

(It does make an increasing amount of sense to use as the traffic in t= his direction is increasingly dominated by ack-eliciting data, but that a= lso makes it increasingly likely that a congestive loss will be of an ack= -eliciting packet.)

We should not change the design here. I'm fine with @ianswett's= proposed addition, but I don't think we should use the loss of ACKs as a= congestion signal that affects the congestion window.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on= GitHub, or unsubscribe.3D""

= ----==_mimepart_5e44903c7d8b4_552d3faf188cd960767e6--