[quicwg/base-drafts] 01098f: Ack Delay and TLP (#1796)

ianswett <ianswett@users.noreply.github.com> Tue, 02 October 2018 16:13 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 E0EB8130ECB for <quic-issues@ietfa.amsl.com>; Tue, 2 Oct 2018 09:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.457
X-Spam-Level:
X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_ADSP_NXDOMAIN=0.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 2f_WIctgDkmj for <quic-issues@ietfa.amsl.com>; Tue, 2 Oct 2018 09:13:21 -0700 (PDT)
Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.169]) (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 7B43A130DFA for <quic-issues@ietf.org>; Tue, 2 Oct 2018 09:13:21 -0700 (PDT)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1538496800; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=pvuf5QdXs6ALqLc/ssV/HO4bbZ+ugghfsYs1v7SrFQY=; b=W65Sr5B0+RFE5ddBRmH2SJPn0UHMeoUuCWPLnSA4YEOR0K3PHX7E8jAH4UMG8ZUE+Lsl/jV3 ITZwarWV0cGYuWg97GGooCkuDjxbpDR2RM9/xQcPVyheKr6wHnZMMO4UHroU9HmKAj058bpJ V026ekwDcbaxCmtj7K3H3aKeqK4=
X-Mailgun-Sending-Ip: 166.78.69.169
X-Mailgun-Sid: WyJhNzYyYiIsICJxdWljLWlzc3Vlc0BpZXRmLm9yZyIsICI0MGYiXQ==
Sender: ianswett=users.noreply.github.com@github.com
Received: from github.com (Unknown [192.30.252.37]) by mxa.mailgun.org with ESMTP id 5bb396c8.7fb9c0bd9cc0-smtp-out-n03; Tue, 02 Oct 2018 16:03:20 -0000 (UTC)
Date: Tue, 02 Oct 2018 09:03:19 -0700
From: ianswett <ianswett@users.noreply.github.com>
Reply-To: ianswett <ianswett@users.noreply.github.com>
To: quic-issues@ietf.org
Message-ID: <5bb396c7812a1_44f62abfc3ea6ebc82855@hookshot-fe-2cc8887.cp1-iad.github.net.mail>
Subject: [quicwg/base-drafts] 01098f: Ack Delay and TLP (#1796)
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="--==_mimepart_5bb396c780ccf_44f62abfc3ea6ebc827bd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/_wgw3xA9PNJ5PDFV2ql8oylgKI4>
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, 02 Oct 2018 16:13:23 -0000

  Branch: refs/heads/master
  Home:   https://github.com/quicwg/base-drafts
  Commit: 01098f72c28e008c257686d6415bb777f85d4bdd
      https://github.com/quicwg/base-drafts/commit/01098f72c28e008c257686d6415bb777f85d4bdd
  Author: ianswett <ianswett@users.noreply.github.com>
  Date:   2018-10-02 (Tue, 02 Oct 2018)

  Changed paths:
    M draft-ietf-quic-recovery.md

  Log Message:
  -----------
  Ack Delay and TLP (#1796)

* 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.

* Update draft-ietf-quic-recovery.md

* Use 2*kMaxDatagramSize

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Nits



      **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.