Re: [quicwg/base-drafts] Congestion feedback for rejected 0-RTT (#762)

mirjak <notifications@github.com> Wed, 13 September 2017 13:12 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 753EF133038 for <quic-issues@ietfa.amsl.com>; Wed, 13 Sep 2017 06:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.798
X-Spam-Level:
X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, 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 BeeE6uA1kCWt for <quic-issues@ietfa.amsl.com>; Wed, 13 Sep 2017 06:12:41 -0700 (PDT)
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [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 A9E4D133039 for <quic-issues@ietf.org>; Wed, 13 Sep 2017 06:12:40 -0700 (PDT)
Date: Wed, 13 Sep 2017 06:12:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1505308359; bh=ng5sJZ1oJb1CAFSVJfXOEfcAPGfC7dwKxMeGbh8darQ=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NbsM31EjkjLZP1NwO+e4HtSfruefPi4LoQuN7vFlgfk9ZMXwXJEHeatutpIwtivmI gWE85kvCNx1DI4ouZvBb7XoYjiQZwV/8dQEkjzxUQ9DzWJxINKwATL+PKLs44NOuD5 Be2u9+ryaxdEzDNI68dey0oWaipY45wDlksEap0M=
From: mirjak <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab689d6b13fff8c77b1dec334558365a8ebdcdfbbc92cf0000000115d0f0c792a169ce0f39df90@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/762/329163257@github.com>
In-Reply-To: <quicwg/base-drafts/issues/762@github.com>
References: <quicwg/base-drafts/issues/762@github.com>
Subject: Re: [quicwg/base-drafts] Congestion feedback for rejected 0-RTT (#762)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59b92ec7ca343_288c53fbad2f41c2c269c4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
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/UusMMutoHhuHmT7X6irahasGlII>
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, 13 Sep 2017 13:12:42 -0000

So even if the rejected packets where not ack'ed, the server could still indicate to the client in the TLS handshake that the 0-RTT data was rejected and potentially even tell the client how many packets where rejected. That might be all you need to know for congestion control purposes because if some or all of the 0-RTT packets were lost you might want to reduce the congestion window even below the initial window (assuming the initial window was larger than the minimum window).

However, just resending the 1-RTT with the initial window is probably easier and should be fine in most cases, or in the worse case just delay your congestion control reaction by one RTT.

-- 
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/762#issuecomment-329163257