IETF Logo Mail Archive

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

Kazuho Oku <notifications@github.com> Tue, 29 October 2019 21: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 C57B012006D for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 14:33:12 -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 qzZUsYHrTOo6 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 14:33:11 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C4912001E for <quic-issues@ietf.org>; Tue, 29 Oct 2019 14:33:11 -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 826A3520C48 for <quic-issues@ietf.org>; Tue, 29 Oct 2019 14:33:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572384790; bh=ddeA672bwNLT1gfY8p0BavGBFHu8gPNuxIR9Me7Um00=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TbgW54OEHEQWLhGKmJmcy0HdJR8Erd2ldQV/K7Z7lleXaAIthl4C7LNAChOscE94l BF/oC/aFozrc48CA7u7qxQGsadZIUAxaLdgsCNz0hNC3OsX0nKeLyXzsGL4cWpyXZ7 UU0yYcwHJqWFAts5N3BX34OAKiFcFGedKau27dsc=
Date: Tue, 29 Oct 2019 14:33:10 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7TGVDLQOKT762SO553YXRJNEVBNHHB5GVBRY@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/547639187@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_5db8b01673487_7b7d3fa4d1ccd96c2637b1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/-As_CLc1qhp_SMQl5R97huDLdvA>
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, 29 Oct 2019 21:33:13 -0000

@ianswett 
> PTO always uses exponential backoff, so if the first PTO was 1ms, that'd be ~10 PTOs, not 1000.

Ah. Thank you for pointing that out. Though it seems that the amount of the data that the server can send could go like 4x the amount of data that the client has sent rather than the current 3x.

To paraphrase, I think what we might be trading here is the initial amount of data the server can send vs. the capability of sending PINGs. My view is that the former is a scarce resource, and that I'd prefer having the more space in the former even if requires us to have some complexity.

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

v2.23.0 | Report a Bug | By Email