Re: [quicwg/base-drafts] Add max_bytes_before_ack to transport (#1715)

Christian Huitema <notifications@github.com> Wed, 12 September 2018 18:06 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 3FDA7130E5E for <quic-issues@ietfa.amsl.com>; Wed, 12 Sep 2018 11:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 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] 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 z4ALhA3errnG for <quic-issues@ietfa.amsl.com>; Wed, 12 Sep 2018 11:06:25 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CA8128CF3 for <quic-issues@ietf.org>; Wed, 12 Sep 2018 11:06:25 -0700 (PDT)
Date: Wed, 12 Sep 2018 11:06:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1536775584; bh=bF+Ew3Floxv1g0+VjA8LqHyo0Fh1G1bbxv+d5DCwuME=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=M+GCwL60u/3vDD0HsYrfj+1QzQcqF+YhAMK/5rByTJCXMybMG182osoIZllIiKEki lTJteqJ0RLb4SNvCUt4s8+cpgLl2TkoHecPyKEhva1If0+tuYvNFOcebMfI7wJuW9C aB8QVCg7XMm0m2LRjCaBIkpx0gn8YHSctDvqU8hQ=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abfe9d31294a172d4a92077151977b92fe40970d5192cf0000000117b117a092a169ce152ea636@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1715/c420743987@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1715@github.com>
References: <quicwg/base-drafts/pull/1715@github.com>
Subject: Re: [quicwg/base-drafts] Add max_bytes_before_ack to transport (#1715)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b9955a080e15_25953fac37ad45bc355650"; 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: <https://mailarchive.ietf.org/arch/msg/quic-issues/pKPcITcuaGcxFUIAvzbINPdQUSw>
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: Wed, 12 Sep 2018 18:06:27 -0000

@ianswett I agree that receivers could hamper senders' performance if they delay ACK too much. We should say that explicitly in the recovery draft. But sending ACKs too frequently also affects the senders' performance, and we should say that too. Bottom line, it is a balance.

We probably want to set default requirements for the number of packets before ACK and for the max ACK delay -- your arbitrary choices of 10 packets and 10 ms look as good as any, or maybe the min of that and 1/4th of the congestion window (for bytes/packets) or the RTT (for ACK delay), with something like at least two packets and 1ms as safe minimum. It would set a reasonable default. Anything else is dependent of the congestion control implementation at the sender, and probably requires cooperation between sender and receiver. That's what extensions are for.

But I do not think that adding this "byte limit" concept is useful, especially if there is no way to change it during the course of the connection.

-- 
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#issuecomment-420743987