Re: [quicwg/base-drafts] PTO MUST send new data or retransmit data if possible (#3057)

ianswett <notifications@github.com> Mon, 28 October 2019 18:33 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 658DA1201DE for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 11:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ieE1VvfgYZ2L for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 11:33:03 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855B912025D for <quic-issues@ietf.org>; Mon, 28 Oct 2019 11:33:03 -0700 (PDT)
Date: Mon, 28 Oct 2019 11:33:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572287582; bh=Ga4JYapo32luZoTs6hTc5l8qNsIkmYNB5r/85j9O6d0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EX4fcyDsAWZC089ziw1PIKj4O1wazXU+hbepHMz1eWFNyIIxhRXz3aCSjhjlLlT/r v28ZiMKHLRqSUnJUAhc8MnKlrvxO4zT8LTan3NbqiosGu9JBEAdR7480MlWiS3NfQ/ tf/0776RRC3TNWx9SBJBUnUTP01UUL70DEr9tDSw=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK53R34MLLU2SLALJHN3YR2O5EVBNHHB3IPO4M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3057/review/308062479@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3057@github.com>
References: <quicwg/base-drafts/pull/3057@github.com>
Subject: Re: [quicwg/base-drafts] PTO MUST send new data or retransmit data if possible (#3057)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db7345e6af1c_4c003ffd71ecd96c12288f"; 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/FCO2WZeFsFTbr2Cw9Nu8ox0YlwM>
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: Mon, 28 Oct 2019 18:33:05 -0000

ianswett commented on this pull request.



>  
-When there is no data to send, the sender SHOULD send a PING or other
-ack-eliciting frame in a single packet, re-arming the PTO timer.
+It is possible the sender has no new or previously-sent data to send.
+As an example, consider the following sequence of events: new application data
+is sent in a STREAM frame, deemed lost, then retransmitted in a new packet,
+and then the original transmission is acknowledged.  When there is no data to
+send, the sender SHOULD send a PING or other ack-eliciting frame in a single
+packet, re-arming the PTO timer.

Yes, but this is existing text and I didn't want to tie this PR to the PTO per PN space PR.

One of the reasons I'd like to get this change in soon is it's going to cause conflicts with the multiple PN spaces PR, and the other PR is more substantive.

The original issue(#3056) was that there was no MUST to retransmit the client Initial, and if the server doesn't create connection state until receiving a client Initial, the handshake fails.

That being said, the client sending a full sized ack eliciting packet that's not the Initial seems odd.  And if the server isn't going to create state, it seems like it should send a Retry to do path validation.

-- 
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/pull/3057#discussion_r339726721