IETF Logo Mail Archive

Re: [quicwg/base-drafts] Prioritize Handshake probe packet over Short packet (#3583)

ianswett <notifications@github.com> Fri, 24 April 2020 20:40 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 349D13A0AE3 for <quic-issues@ietfa.amsl.com>; Fri, 24 Apr 2020 13:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, 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 fDFqaHbXqA8b for <quic-issues@ietfa.amsl.com>; Fri, 24 Apr 2020 13:40:27 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E6F3A0AE2 for <quic-issues@ietf.org>; Fri, 24 Apr 2020 13:40:26 -0700 (PDT)
Received: from github-lowworker-1dbcc59.ash1-iad.github.net (github-lowworker-1dbcc59.ash1-iad.github.net [10.56.105.54]) by smtp.github.com (Postfix) with ESMTP id E43802C19B2 for <quic-issues@ietf.org>; Fri, 24 Apr 2020 13:40:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1587760825; bh=ekXSjhWH8GFeb3OxW/0Uaw6nDcOc1KGtyEvIxIbFwOQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sJUhp0aeBBBILQDHyEmYk933NDu+1IVbQIssp28c7CAyJ0alvSAxM0Kq31p75mObV sgcegbMinANeX/4ukWnjDwPbI6vXjvXW1QjOD9hwe9IpGJi+No0QcEHDpCuh6kV+dR /ezIJMWHym0AwRvdVFbCNIooImZPbQ972Sical8Q=
Date: Fri, 24 Apr 2020 13:40:25 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2N427NFKWWJKQNU5V4V4X3TEVBNHHCHRCEXQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3583/619228874@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3583@github.com>
References: <quicwg/base-drafts/issues/3583@github.com>
Subject: Re: [quicwg/base-drafts] Prioritize Handshake probe packet over Short packet (#3583)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ea34eb9d485d_516c3f9afbccd960142154"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/XNp1IaD9f8X3MTOGyClmBwHRmE8>
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: Fri, 24 Apr 2020 20:40:28 -0000

Yes, you move to 4x instead of 2x, but it's worth understanding what packets need to be lost for the 2x vs 4x to come into play.

1) The client's Handshake packet is lost twice in a row.  Not that unlikely, but it's known the Client Finished blocks the server from processing 1-RTT packets, so I think there's an understanding of its importance.
2) (case from this issue) The client's Handshake packet is delivered, but the ACK is lost so the client retransmits it then that packet is lost AND both the first HANDSHAKE_DONE packet and its retransmission are lost.

I'm sure there are many other permutations of these, but the first case seems a lot more likely than the second case.

In this case, the HANDSHAKE_DONE does a nice job of mitigating some potential issues.

-- 
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/3583#issuecomment-619228874

v2.23.0 | Report a Bug | By Email