[quicwg/base-drafts] 124536: Ack Delay and TLP
ianswett <ianswett@users.noreply.github.com> Tue, 25 September 2018 14:23 UTC
Return-Path: <bounce+565321.40f-quic-issues=ietf.org@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 D8ED81312D1 for <quic-issues@ietfa.amsl.com>; Tue, 25 Sep 2018 07:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.356
X-Spam-Level:
X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 Tehb3zVXgzxL for <quic-issues@ietfa.amsl.com>; Tue, 25 Sep 2018 07:23:05 -0700 (PDT)
Received: from m71-131.mailgun.net (m71-131.mailgun.net [166.78.71.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C85120072 for <quic-issues@ietf.org>; Tue, 25 Sep 2018 07:23:05 -0700 (PDT)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1537885384; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=QqtsOoueRqsg8Nc042dT8aocgqSldLilyu9K8sYg8qI=; b=fpB6m3+bszYbfPmrIcT3nWpPkeGqjqpuNUnCcj9aKpJRrP7dF177DU3ybmv4bF34/fmCc55J 2VenU8udj7+63jLfUfwfohdozSiWVoBX54/YqKKswlS/Ne2Ve23r+rRNFqjbdEsjWXOS5pwa xQ5ACdvKPzg0kolHIxHtJ6PPXpc=
X-Mailgun-Sending-Ip: 166.78.71.131
X-Mailgun-Sid: WyJhNzYyYiIsICJxdWljLWlzc3Vlc0BpZXRmLm9yZyIsICI0MGYiXQ==
Sender: ianswett=users.noreply.github.com@github.com
Received: from github.com (Unknown [192.30.252.45]) by mxa.mailgun.org with ESMTP id 5baa44c8.7f1efc543e40-smtp-out-n02; Tue, 25 Sep 2018 14:23:04 -0000 (UTC)
Date: Tue, 25 Sep 2018 07:23:04 -0700
From: ianswett <ianswett@users.noreply.github.com>
Reply-To: ianswett <ianswett@users.noreply.github.com>
To: quic-issues@ietf.org
Message-ID: <5baa44c85ddee_2ac52ad05d672ed0946f6@hookshot-fe-5a11256.cp1-iad.github.net.mail>
Subject: [quicwg/base-drafts] 124536: Ack Delay and TLP
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="--==_mimepart_5baa44c85da37_2ac52ad05d672ed094517"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/faJM2pGDS6LC-4ThQm1LDrlG92o>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 25 Sep 2018 14:23:08 -0000
Branch: refs/heads/ianswett-ack-delay-tlp Home: https://github.com/quicwg/base-drafts Commit: 1245368fbc90cd5c3a873693c82a8e20ec29811d https://github.com/quicwg/base-drafts/commit/1245368fbc90cd5c3a873693c82a8e20ec29811d Author: ianswett <ianswett@users.noreply.github.com> Date: 2018-09-25 (Tue, 25 Sep 2018) Changed paths: M draft-ietf-quic-recovery.md Log Message: ----------- Ack Delay and TLP Fixes some remaining issues now that QUIC recommends sending an ACK every two packets, mostly involving reverting to the TCP style TLP calculation. I wrote this based on 'two full-sized packets' equalling a fixed 2400 bytes. QUIC could send immediate acks for non-full-sized packets, but that's not what TCP does. I could base it on the connection's packet size, but that requires the receiver to monitor the sender's max packet size, which made me a bit concerned? Advice on how to ensure sender and receiver agree on packet size would be appreciated. **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019.