Return-Path: 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 892283A0B99 for ; Thu, 23 Apr 2020 13:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 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_28=1.404, 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 knAHgncKkAH3 for ; Thu, 23 Apr 2020 13:04:37 -0700 (PDT) Received: from out-26.smtp.github.com (out-26.smtp.github.com [192.30.252.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF993A0B8D for ; Thu, 23 Apr 2020 13:04:37 -0700 (PDT) Received: from github-lowworker-c5134a3.ac4-iad.github.net (github-lowworker-c5134a3.ac4-iad.github.net [10.52.23.55]) by smtp.github.com (Postfix) with ESMTP id EF10A282C3B for ; Thu, 23 Apr 2020 13:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1587672275; bh=/zDNahNLdSwCpcVIKyUF+p9vHmXnBBhYgxXoJjSB2s4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Onu7UYkR8LO8wIneb/LgGB/xTrGgerXITHNUY9CunqaJV8KT/JiJB7mq3+LmyJ9CW eZeaurusJ8PUgezN9/A7mkqWo4kHQXBqEM2blIgSsIzlUrbLb+dcig6BNnp8MKybER Tr4hmUdocnh14QyXUFkRyGqWEaffsvPClDNNiPHI= Date: Thu, 23 Apr 2020 13:04:35 -0700 From: ianswett Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Prioritize Handshake probe packet over Short packet (#3583) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5ea1f4d3ded37_79403ffcf22cd95c22442ea"; 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: X-BeenThere: quic-issues@ietf.org 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: Thu, 23 Apr 2020 20:04:41 -0000 ----==_mimepart_5ea1f4d3ded37_79403ffcf22cd95c22442ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit In this case, I believe alternating is the right thing to do, because the server either has Handshake receive keys or 1-RTT receive keys, and the client doesn't know which. Because of HANDSHAKE_DONE, the client will eventually complete the handshake and drop the Handshake PN space as long as the client's Handshake packet(containing the finished) gets to the server. However, this case is an excellent motivation for this text: > In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from other packet number spaces with in-flight data, coalescing packets if possible. This text was written prior to HANDSHAKE_DONE, but I think there may be other reasons to use handshake complete and not confirmed in this case, so I would be very hesitant to change it without a lot of consideration. Is there a part of mozilla/neqo#448 I should focus on? The text talks a lot about packets being marked as lost when the PTO timer fires, which makes me very confused, since QUIC doesn't mark packets as lost when the PTO fires. -- 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-618634815 ----==_mimepart_5ea1f4d3ded37_79403ffcf22cd95c22442ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

In this case, I believe alternating is the right thing to do, because the server either has Handshake receive keys or 1-RTT receive keys, and the client doesn't know which. Because of HANDSHAKE_DONE, the client will eventually complete the handshake and drop the Handshake PN space as long as the client's Handshake packet(containing the finished) gets to the server.

However, this case is an excellent motivation for this text:

In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from other packet number spaces with in-flight data, coalescing packets if possible.

This text was written prior to HANDSHAKE_DONE, but I think there may be other reasons to use handshake complete and not confirmed in this case, so I would be very hesitant to change it without a lot of consideration.

Is there a part of mozilla/neqo#448 I should focus on? The text talks a lot about packets being marked as lost when the PTO timer fires, which makes me very confused, since QUIC doesn't mark packets as lost when the PTO fires.

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

----==_mimepart_5ea1f4d3ded37_79403ffcf22cd95c22442ea--