IETF Logo Mail Archive

Re: [quicwg/base-drafts] Rename "retransmittable" frames and packets (#1595)

Christian Huitema <notifications@github.com> Wed, 01 August 2018 06:14 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 83329130F73 for <quic-issues@ietfa.amsl.com>; Tue, 31 Jul 2018 23:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.109
X-Spam-Level:
X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[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, T_DKIMWL_WL_HIGH=-0.01, 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 O2xc9h_ZqNQA for <quic-issues@ietfa.amsl.com>; Tue, 31 Jul 2018 23:14:11 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC446130DDA for <quic-issues@ietf.org>; Tue, 31 Jul 2018 23:14:11 -0700 (PDT)
Date: Tue, 31 Jul 2018 23:14:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1533104051; bh=XyImX4cg4KEFbs/dV70TF8HtpXL4H4tBgTjzVEDpxsU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gFP3TwlhkpWnjY5HIFieLj1aOACEPv37dl6CdSJaqVUsx6mL2P8rf/NLK+ohMslPU JZlkyYO8Q3shtuQJVhj1ddisx2IxPU4HV72WkiCnCm3cwkDYcM1ri7A9wf05R0jPL3 ZmqcKXAbU104pXakJKHMRxsOO+AhTj4pSM8eBMRU=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba94f20fd29813ea42742a0862e286e272fe8f3df92cf00000001177911b392a169ce147c6344@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1595/409461160@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1595@github.com>
References: <quicwg/base-drafts/issues/1595@github.com>
Subject: Re: [quicwg/base-drafts] Rename "retransmittable" frames and packets (#1595)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b614fb321b33_37cd3f9118cbe628298032"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/eO4NLJFNZRoORrxiXefiyDLrt6w>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
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, 01 Aug 2018 06:14:14 -0000

Interesting to look back at this after the discussion of flow control. Take the MAX DATA frame. It does elicit an advertisement. It may be retransmitted, but really should not. Instead, if the packet carrying the frame is lost, the "receiver" (sender of MAX DATA) should check whether it already sent a MAX DATA frame carrying a higher limit, in which case there is no need for retransmission. If the frame is the newest, it should probably still not be retransmitted as is -- there may be a need to check create a new frame containing the latest MAX DATA value. So the MAX DATA frame elicits ACKS, its loss should be detected, but how retransmission proceeds depends on the state of the connection...

-- 
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/1595#issuecomment-409461160

v2.23.0 | Report a Bug | By Email