Re: [quicwg/base-drafts] Optimistic ACK in early handshake (#2192)

MikkelFJ <notifications@github.com> Wed, 19 December 2018 11:07 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 AE9B0130DEF for <quic-issues@ietfa.amsl.com>; Wed, 19 Dec 2018 03:07:22 -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 6iDXq0JhdqCB for <quic-issues@ietfa.amsl.com>; Wed, 19 Dec 2018 03:07:19 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [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 78C6F1277D2 for <quic-issues@ietf.org>; Wed, 19 Dec 2018 03:07:19 -0800 (PST)
Date: Wed, 19 Dec 2018 03:07:18 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545217638; bh=qciIRWBPTyMRH0odn3ljgKGV/6Wl18zjOr9E1XhV7ss=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jGlEKeOHWCwz8XsfnBKjjB5e0+hRf6wuQAGM8NHSiKuLeDiaerwe+rivhsbY7S+sC Eb65MykMb9N4wjgbRc00tB64/CjWtdAfUl+clAVs/JoL7/GfD2Sz2KXOUjX9n+VwUd WkYnzw3vUXuuXzH5WwdGzUQqNFLjnrl29AIK5YJo=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb81cd1323f3de7b97ddf47d1f8948c2756cecb4192cf000000011831e86692a169ce1753c928@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2192/448556712@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2192@github.com>
References: <quicwg/base-drafts/issues/2192@github.com>
Subject: Re: [quicwg/base-drafts] Optimistic ACK in early handshake (#2192)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c1a26667315e_7283fdd620d45c43956e6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/i_3exX31jlKkPwr7VszhZL-1zHE>
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: Wed, 19 Dec 2018 11:07:23 -0000

@gloinul 
> Thus, if you actually have a packet loss, the whole connection will be screwed as you can't get retransmission of the lost data.

I don't think (hope not) that there is text preventing acknowledging a packet multiple times, but it SHOULD not be acknowledge again once an endpoint knows that the peer received the acknowledgment.

As to renege in the current text:

section 19.3.: 
> QUIC acknowledgements are irrevocable. Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK frame. This is unlike TCP SACKs ([RFC2018]).

section 21.3.:
> An endpoint that acknowledges packets it has not received might cause a congestion controller to permit sending at rates beyond what the network supports. An endpoint MAY skip packet numbers when sending packets to detect this behavior. An endpoint can then immediately close the connection with a connection error of type PROTOCOL_VIOLATION (see Section 10.3).


-- 
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/2192#issuecomment-448556712