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 B23BD130E2D for ; Sat, 1 Sep 2018 11:14:44 -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 GFSmjkTNrVYH for ; Sat, 1 Sep 2018 11:14:43 -0700 (PDT) Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558A4130E25 for ; Sat, 1 Sep 2018 11:14:43 -0700 (PDT) Date: Sat, 01 Sep 2018 11:14:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1535825682; bh=qndNbURn4zTF1yedhAw458Zh38LJmTIddB84vpd8sug=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GJ7dpZPCo15Tm/cUIyvV5ht4LKt8pcqysixYlnJgKmq87dlI80LQ8yqYFpeoArWRt I3uh+laeZ3Pjqz9WwsBbuxlQ/u27wXDBBEsgI913O437MT6UfU8WEg5h7zfxSPjAXG JkaltjkCfxI7RkCjMLOV3VhYNaDjbbFjo9RSxn1U= From: Christian Huitema Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Add psuedocode for ACK sending logic in recovery (#1716) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5b8ad712b0493_64c23fadc82d45b4197945"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: huitema 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: Sat, 01 Sep 2018 18:14:45 -0000 ----==_mimepart_5b8ad712b0493_64c23fadc82d45b4197945 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Maybe that's just me, but when I am implementing QUIC I treat the recovery spec as mostly informational, something you follow if you don't know better. I do expect that researchers will keep coming up with better congestion control schemes, and that we will keep improving the retransmission mechanisms, or the ACK sending mechanism. Of course, things work better if the receiver is aware of the congestion control algorithm used by the sender. For example, if the sender is using basic RENO and relies on ACK clocking, receivers should send frequent ACKs to try reduce the risk of packet bunching. On the other hand, if the sender is using some form of rate control or pacing, then the receiver should then ACK as infrequently as practical, in order to minimize the cost of ACK processing. And if the sender relies on delay-based congestion control algorithms, the receivers should try send several ACK per RTT, to provide good estimate of RTT evolution. So if we are bound to create new transport options, maybe we should let senders signal which congestion controller they are using. If the receiver understands the algorithm they can optimize. If not, they can fall back to some safe default. -- 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/1716#issuecomment-417877754 ----==_mimepart_5b8ad712b0493_64c23fadc82d45b4197945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Maybe that's just me, but when I am implementing QUIC I treat the reco= very spec as mostly informational, something you follow if you don't know= better. I do expect that researchers will keep coming up with better con= gestion control schemes, and that we will keep improving the retransmissi= on mechanisms, or the ACK sending mechanism.

Of course, things work better if the receiver is aware of the congesti= on control algorithm used by the sender. For example, if the sender is us= ing basic RENO and relies on ACK clocking, receivers should send frequent= ACKs to try reduce the risk of packet bunching. On the other hand, if th= e sender is using some form of rate control or pacing, then the receiver = should then ACK as infrequently as practical, in order to minimize the co= st of ACK processing. And if the sender relies on delay-based congestion = control algorithms, the receivers should try send several ACK per RTT, to= provide good estimate of RTT evolution.

So if we are bound to create new transport options, maybe we should le= t senders signal which congestion controller they are using. If the recei= ver understands the algorithm they can optimize. If not, they can fall ba= ck to some safe default.

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

= ----==_mimepart_5b8ad712b0493_64c23fadc82d45b4197945--