Re: [quicwg/base-drafts] Encoding of blocksize in ACK frames. (#679)
Igor Lubashev <notifications@github.com> Wed, 04 October 2017 09:16 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 1699613300C for <quic-issues@ietfa.amsl.com>; Wed, 4 Oct 2017 02:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.399
X-Spam-Level:
X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, 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 r9MgNgrAx1Cn for <quic-issues@ietfa.amsl.com>; Wed, 4 Oct 2017 02:16:44 -0700 (PDT)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [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 95311132D67 for <quic-issues@ietf.org>; Wed, 4 Oct 2017 02:16:44 -0700 (PDT)
Date: Wed, 04 Oct 2017 02:16:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507108603; bh=GwJ3J0hF0pQXC0ZCbRP7VB8KCzDq3anc3aE7WQNMmu0=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZkXY8b5MtYI/clhhg0DajY3Q4b2tnP/GfrSlNWBCw/p/eYrumOfBZQrEMFcazaHNL M4cg84jze9y9VTmfAL6jrSXLJD/s5c2t1TIIIRaS0K6UVSpYh7ZOdWsyMAu0oRNmkk ngF0hBM12j1ApTzYWy0V7i7KDIokUsTgCLif4Exg=
From: Igor Lubashev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab4b3aa2d68444a7cef7abcce952bcba33ca0b8cc992cf0000000115ec68fb92a169ce0e55eb1c@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/679/334097327@github.com>
In-Reply-To: <quicwg/base-drafts/issues/679@github.com>
References: <quicwg/base-drafts/issues/679@github.com>
Subject: Re: [quicwg/base-drafts] Encoding of blocksize in ACK frames. (#679)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59d4a6fbbd4e7_1363fd2e9f46f2c31129"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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/Lzr3cS5lh546C2dghmcd-aZ41jk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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, 04 Oct 2017 09:16:46 -0000
Does Gap = 0 ever make sense? I do not think so.
We could do one of two things:
1. Define the actual gap to be Gap+1 (and keep the semantics of "ACK Block Length" unchanged), or
2. If Gap=0, the following `(("ACK Block Length" << 8) | "Following Gap")` actually defines the length of the gap. In this case, the semantics of the regular "ACK Block Length" can be made to match "First ACK Block Length", and chances are excellent that multiple ACK frames will not be needed.
Option 2 has a few special cases in it: (a) If "ACK Block Length" is 64 bit, `(("ACK Block Length" << 8) | "Following Gap")` is too large; (b) the last Gap=0 still does not make sense (unless someone is willing to assign semantics to it).
--
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/679#issuecomment-334097327
- [quicwg/base-drafts] Encoding of blocksize in ACK… Christian Huitema
- Re: [quicwg/base-drafts] Encoding of blocksize in… Mike Bishop
- Re: [quicwg/base-drafts] Encoding of blocksize in… Martin Thomson
- Re: [quicwg/base-drafts] Encoding of blocksize in… Lars Eggert
- Re: [quicwg/base-drafts] Encoding of blocksize in… Igor Lubashev
- Re: [quicwg/base-drafts] Encoding of blocksize in… ianswett
- Re: [quicwg/base-drafts] Encoding of blocksize in… ianswett