Re: [quicwg/base-drafts] Lost Server Initial Takes Too Long to be Retransmitted (#3078)

Kazuho Oku <> Mon, 07 October 2019 02:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 415881207FC for <>; Sun, 6 Oct 2019 19:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q4dIMrcgEKKP for <>; Sun, 6 Oct 2019 19:03:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77F3912001E for <>; Sun, 6 Oct 2019 19:03:38 -0700 (PDT)
Date: Sun, 06 Oct 2019 19:03:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1570413817; bh=YLY1bu1JqpXPiGc/UlqaImJuuasaaKbI8a8hfF3z094=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JmAek9x1JFvnejAKCSHpJ5JPmWOuiIaExyM+BAR3epP+1fOeU7JXVu+/N/M0cjxTK c8wkBMks4Mq6xdmRvW8VtwZl2FaExzSdgCT1JCwGtifvcU/oVCq+Kn6B0ea1Z2iZJ8 pTIvXSXa4Y/sYivaSBNLS9ujhULnQeFQ3PeiDI7A=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3078/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Lost Server Initial Takes Too Long to be Retransmitted (#3078)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d9a9cf995937_15443fddaf8cd968211979"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Oct 2019 02:03:40 -0000

I think the problems here are:
* Receiving a retransmit client Initial does not necessarily indicate a loss. It could simply be the case that the actual RTT is greater than the client's initial RTT. Do we want the server to retransmit packets in that case? Note that a client might use a small initial RTT when it is connecting to a server that it has previously connected to.
* How the server detects a retransmission will become complicated if we adopt #3045.

Considering these aspects, I might be weakly inclined to addressing the issue using an explicit signal, defined either within v1 or an extension.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: