IETF Logo Mail Archive

Re: [quicwg/base-drafts] RESET_STREAM.final_offset is ambiguous (#2262)

Kazuho Oku <notifications@github.com> Thu, 03 January 2019 05:17 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 D0FA71310E3 for <quic-issues@ietfa.amsl.com>; Wed, 2 Jan 2019 21:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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] 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 Ipu-qOBktaz2 for <quic-issues@ietfa.amsl.com>; Wed, 2 Jan 2019 21:17:28 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A76124D68 for <quic-issues@ietf.org>; Wed, 2 Jan 2019 21:17:28 -0800 (PST)
Date: Wed, 02 Jan 2019 21:17:27 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546492647; bh=o5zRu/vX1mQ91kAIIm4oYvSbkolmwSxqUph469NqIs4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gUgS+IuzaU9G0qJ3y0mcqn7+/aDCwzng5KKXTkJhaBYHxTFcYaZXDmeo10pgz730Q c6omjSZ8N1FBhhzim19qSFYGMDlcQPE0B6X79OsHno4HZm3XgVyG3VrkEtu6DpHpBo 1cU4FO57SQAuEpAdZ76Im4D5ouEOp87fpv5U1qig=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab36d1596ff9c0b7c06af9797933aa6d58de758ad192cf0000000118455ce792a169ce17801464@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2262/451057671@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2262@github.com>
References: <quicwg/base-drafts/issues/2262@github.com>
Subject: Re: [quicwg/base-drafts] RESET_STREAM.final_offset is ambiguous (#2262)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c2d9ae73409b_50973facaccd45b819945c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/ZCYEaBmo4v091xcCZ4h7PN5upKc>
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: Thu, 03 Jan 2019 05:17:30 -0000

> Looks like this has nothing to do with retransmissions at all, but just with the definition of "offset".

Correct. That's why I stated "excluding overlaps (due to retransmissions)"; maybe that was confusing though.

> Maybe we can define the stream offset as the offset of the next byte that would be sent on the stream would have.

We can do that. However the downside would be that the difference from the terms we define MAX_DATA and MAX_STREAM_DATA becomes bigger. While MAX_STREAM_DATA can be adjusted that way, I am not sure if we can have a similar definition for MAX_DATA. It should also be noted that MAX_STREAMS uses "stream count"; using "byte count" in the definition of flow control credit is in align of that better than using "offset".

-- 
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/2262#issuecomment-451057671

v2.23.0 | Report a Bug | By Email