IETF Logo Mail Archive

Re: [quicwg/base-drafts] Limit fallout of on-stream badness (#3336)

Martin Thomson <notifications@github.com> Wed, 15 January 2020 23:30 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 28689120113 for <quic-issues@ietfa.amsl.com>; Wed, 15 Jan 2020 15:30:16 -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 fiEuKskIJcjF for <quic-issues@ietfa.amsl.com>; Wed, 15 Jan 2020 15:30:15 -0800 (PST)
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 CA122120044 for <quic-issues@ietf.org>; Wed, 15 Jan 2020 15:30:14 -0800 (PST)
Received: from github-lowworker-edec459.ac4-iad.github.net (github-lowworker-edec459.ac4-iad.github.net [10.52.18.32]) by smtp.github.com (Postfix) with ESMTP id ECAAF6E11EB for <quic-issues@ietf.org>; Wed, 15 Jan 2020 15:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579131013; bh=B7BRN+FSMpJBe3FHnjMl7GQDP5a8F2B1SmtR8Efwv/U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gOVdzVWFYlCmUqDzgPBAYQ2B7l+fwnpZfUU7gElzcyTWPvkg2OTdqbnrMTDj0HOfr IzLIEdMLbypy51Rg91PDWWjY4RXzzX/nQosV1bvzv86b1xQvUOaTh67Ur8VvdmcTLH AGPosZF61IMXoy5cNumHYNiZ5Sml+Kbcq/XpaUc8=
Date: Wed, 15 Jan 2020 15:30:13 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYXATG2UWVQ22B27IV4FTJQLEVBNHHCBO6ZLI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3336/c574905887@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3336@github.com>
References: <quicwg/base-drafts/pull/3336@github.com>
Subject: Re: [quicwg/base-drafts] Limit fallout of on-stream badness (#3336)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1fa085dc42a_45443fca3cacd96022843e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/bFR6_LCbDRhoU-4vhcgCg6lUQBs>
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: Wed, 15 Jan 2020 23:30:16 -0000

I think that this a reasonable compromise, even if I'm not 100% happy with it.

Part of what we are attempting to do here is establish what the common intersection is between implementations.  Some tolerance for errors in streams is awful, but it seems inevitable that there will be pressures to be tolerant that have more force than anything we might define here.  Maybe that's a little too cynical, but there you go.

If you accept that thesis, it doesn't necessarily follow that errors will remain hidden or go unpunished (if punitive measures are your thing).  All we need is some non-negligible portion of the deployed base, as encountered by new implementations, both client and server, to make these stream errors more visible in some way.

-- 
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/3336#issuecomment-574905887

v2.23.0 | Report a Bug | By Email