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 A42EF130ED6 for ; Wed, 29 Aug 2018 18:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.009 X-Spam-Level: X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 dpERh-eIZ554 for ; Wed, 29 Aug 2018 18:17:56 -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 4B9FD12426A for ; Wed, 29 Aug 2018 18:17:56 -0700 (PDT) Date: Wed, 29 Aug 2018 18:17:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1535591875; bh=ylmmdom03rrBgGZwNqgZIvFqSgzjuqe4D97w6IIpYrw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1IeDFVSj5z1epySZuFtama3BIjGa6zdtapIZGaXlvg98BEh8E6HnF7s32nh6O74wE RloNQBebVZQMMTZ4D4HNuoNRI08/FgIaW49yPGaZBKnN66mwdJt1gg8b8b18jsHc4w ze58RfnO6l3gga25hFb4p+DH8v7Dxoyh7M6yI3KA= From: Martin Thomson Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Add max_bytes_before_ack to transport (#1715) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5b8745c370550_47fd3fc80f4d45c41207b5"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: martinthomson 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.27 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: Thu, 30 Aug 2018 01:17:58 -0000 ----==_mimepart_5b8745c370550_47fd3fc80f4d45c41207b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit martinthomson commented on this pull request. > @@ -3425,6 +3433,10 @@ immediately or when a delayed ack timer expires. The delayed ack timer MUST NOT delay an ACK for longer than an RTT, which ensures an ACK frame is sent at least once per RTT if new packets needing acknowledgement were received. +If the max_bytes_before_ack transport parameter has been received, the +receiver SHOULD send an ACK frame immediately once that many octets of packets +containing frames besides ACK or PADDING have been received. What is the logic you are looking for? Count the total size of received packets, unless they are ACK-only, then send an ACK when count>max_bytes_before_ack? I would reframe this slightly in that case. "The max_bytes_before_ack transport parameter can be used to request more frequent acknowledgments. After sending a packet containing an ACK frame, a receiver counts the size of all packets it receives, omitting packets that only contain ACK or PADDING frames. Once this count exceeds the value of the max_bytes_before_ack transport parameter it has received from a peer, the receiver MUST send an ACK frame immediately." -- 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/pull/1715#pullrequestreview-150808903 ----==_mimepart_5b8745c370550_47fd3fc80f4d45c41207b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@martinthomson commented on this pull request.

In draft-ietf-quic-transport.md:

> @@ -3425,6 +3433,10 @@ immediately or when a delayed ack timer expires. The delayed ack timer MUST
 NOT delay an ACK for longer than an RTT, which ensures an ACK frame is sent
 at least once per RTT if new packets needing acknowledgement were received.
 
+If the max_bytes_before_ack transport parameter has been received, the
+receiver SHOULD send an ACK frame immediately once that many octets of packets
+containing frames besides ACK or PADDING have been received.

What is the logic you are looking for? Count the total size of received packets, unless they are ACK-only, then send an ACK when count>max_bytes_before_ack?

I would reframe this slightly in that case. "The max_bytes_before_ack transport parameter can be used to request more frequent acknowledgments. After sending a packet containing an ACK frame, a receiver counts the size of all packets it receives, omitting packets that only contain ACK or PADDING frames. Once this count exceeds the value of the max_bytes_before_ack transport parameter it has received from a peer, the receiver MUST send an ACK frame immediately."

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5b8745c370550_47fd3fc80f4d45c41207b5--