Re: [quicwg/base-drafts] only require RESET_STREAM on STOP_SENDING in Ready and Sent state (#2268)

Kazuho Oku <notifications@github.com> Tue, 01 January 2019 06:42 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 B1960127598 for <quic-issues@ietfa.amsl.com>; Mon, 31 Dec 2018 22:42:10 -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 GChqQSL6VOrJ for <quic-issues@ietfa.amsl.com>; Mon, 31 Dec 2018 22:42:08 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E341276D0 for <quic-issues@ietf.org>; Mon, 31 Dec 2018 22:42:08 -0800 (PST)
Date: Mon, 31 Dec 2018 22:42:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546324927; bh=kGL2d9ewiNZnYZ6SigWBTbFswJyhaj5ioXXpNrjZwKk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f01kljTfrA7BYF5f/RMbeP+8APkWqBW9fedjQPNDzt+fuj/uF/IsWSmpBzX8579Nu i8gLrm7ZcY34BgNwYWps7yiZRia7PTZkzBEkA8BpPdskTM7eIEZilNU9U/e43vz4zv 0I4YUzc1GWFVR6SbQyKrVtYkDPlGwMBeOpUQdonw=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab010c21960a613badeaa5d7c7eb2b317a4bbef58392cf000000011842cdbf92a169ce17856d43@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2268/c450712796@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2268@github.com>
References: <quicwg/base-drafts/pull/2268@github.com>
Subject: Re: [quicwg/base-drafts] only require RESET_STREAM on STOP_SENDING in Ready and Sent state (#2268)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c2b0bbf3fb7d_7ea33fadcd0d45c062890"; 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/JijdWCIlUZiCJYjl8B35xewbcik>
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: Tue, 01 Jan 2019 06:42:11 -0000

@martinthomson 
> I could go as far as "MAY defer action and send either a RESET_STREAM or all remaining stream data until unacknowledged data is declared lost." I think that allows for what you say.

I think that we need to at least state that.

Our consensus is that endpoints can simply retransmit the entire payload of a lost packet (see #1612, #2082). That means that theoretically, an endpoint can receive an awfully outdated STOP_SENDING frame. However, we do not want endpoints to perpetually remember the final offsets of all the streams it has ever used. Therefore, we need to allow an endpoint to ignore STOP_SENDING when it knows that the peer has already seen either a RESET_STREAM or a FIN for the stream the STOP_SENDING frame designates.

-- 
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/2268#issuecomment-450712796