IETF Logo Mail Archive

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

Tatsuhiro Tsujikawa <notifications@github.com> Tue, 24 September 2019 01:15 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 862DD12009C for <quic-issues@ietfa.amsl.com>; Mon, 23 Sep 2019 18:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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, 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 7WK2Bw0Vy-sN for <quic-issues@ietfa.amsl.com>; Mon, 23 Sep 2019 18:15:49 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC015120045 for <quic-issues@ietf.org>; Mon, 23 Sep 2019 18:15:49 -0700 (PDT)
Date: Mon, 23 Sep 2019 18:15:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1569287748; bh=HznDCi8wm5QscnnsgjkkhV3G2jNkDTtjTo2LWNgH2N0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oQ+E/fK4nk//1ZZhRx14xxeHl0vTP+qGtZi20aIuQ8RqKnSIiDuHzXTrhXqokSNyJ 0XA7A34gv0dWX3C2rVR8++8ykdeE2NVtVylV9xw19cSt4PMX2EkHuEHSM1dyZ+KSMs sJr8rgR7KTY8XCY4XS5YPQac7v/Ll2oPuzGbmUO0=
From: Tatsuhiro Tsujikawa <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4TKCVUAEQ65DIHSQ53S2QMJEVBNHHB3IPO4M@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/292130362@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_5d896e44daba8_f5b3ffc512cd96c14185"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tatsuhiro-t
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/rgGJy5BKgEOTFq2hdjzIYT2BTd4>
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: Tue, 24 Sep 2019 01:15:52 -0000

tatsuhiro-t 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.

I think this kind of situation only happens when client sent Initial and received its ACK but either sever Initial or Handshake was lost.  Client then literally has nothing to send.  And forced to send ack-eliciting frame (and controversially, draft-23 does not allow PING here).

-- 
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_r327391007

v2.23.0 | Report a Bug | By Email