IETF Logo Mail Archive

Re: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)

ianswett <notifications@github.com> Sun, 03 November 2019 19:59 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 958E41200CE for <quic-issues@ietfa.amsl.com>; Sun, 3 Nov 2019 11:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 01zvPRnnNDFv for <quic-issues@ietfa.amsl.com>; Sun, 3 Nov 2019 11:59:43 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D4812008C for <quic-issues@ietf.org>; Sun, 3 Nov 2019 11:59:43 -0800 (PST)
Received: from github-lowworker-25680bd.va3-iad.github.net (github-lowworker-25680bd.va3-iad.github.net [10.48.17.61]) by smtp.github.com (Postfix) with ESMTP id 613CA9602E6 for <quic-issues@ietf.org>; Sun, 3 Nov 2019 11:59:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572811182; bh=W7TbwACVcBMUfpmP1m5Md1s9xU9tAxQyg00tV6o1vJQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZTIKWLiLe/L3pVseugzaZGH8d5pFTGpdUvjdsCTqZGExPQ+Y1bD5FqA30DOLyriAh Ub1LFuvfUhjoWiaFh7Sb7II5j4gQuGMZCNT0ZnLxQZ8gM/TZ+MwGPgyGUuHZVt9QUL FFmnEghTYNrMHsAJGeGk6mZRERrT40rkRxj94bqs=
Date: Sun, 03 Nov 2019 11:59:42 -0800
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4XMXOVO6NGVCQSJPV3ZRSC5EVBNHHB5GVBRY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3161/549172711@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3161@github.com>
References: <quicwg/base-drafts/issues/3161@github.com>
Subject: Re: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dbf31ae5241c_4c413f8d3dccd96817815f1"; 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/dopeLKtjcbF8otHFl4BOIrhwq9U>
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: Sun, 03 Nov 2019 19:59:46 -0000

I believe this is simpler to implement assuming one is implementing both a client and server.  I already have special case code to send a PING when there are bytes in flight but nothing to send, so this is very similar.

I agree it's not necessary, but I find the simplification appealing, and when we first discussed this problem, no one suggested this solution, so I thought it was worth writing up.

If we keep the existing text that the client has to keep sending, I'm not sure doing this on the server side is a valuable optimization, so I'd prefer to stick with one mechanism or the other.

To me, the main negative is the server sending extra datagrams, as you said.  And maybe that's enough to stick with what we have.

-- 
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/3161#issuecomment-549172711

v2.23.0 | Report a Bug | By Email