IETF Logo Mail Archive

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

Lucas Pardue <notifications@github.com> Tue, 14 January 2020 23:47 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 5EAD812006D for <quic-issues@ietfa.amsl.com>; Tue, 14 Jan 2020 15:47:25 -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 krWAZ_mqeo-t for <quic-issues@ietfa.amsl.com>; Tue, 14 Jan 2020 15:47:23 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DEE12002F for <quic-issues@ietf.org>; Tue, 14 Jan 2020 15:47:23 -0800 (PST)
Received: from github-lowworker-45eca55.ac4-iad.github.net (github-lowworker-45eca55.ac4-iad.github.net [10.52.25.70]) by smtp.github.com (Postfix) with ESMTP id 10556C6033F for <quic-issues@ietf.org>; Tue, 14 Jan 2020 15:47:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579045643; bh=qJGQ0UUyxqXai76RGoNHWVVZ7a4B66r7nn5r3c7xm2M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VjuadIzBzEI3BtE8podLAlQTYI6r550V/eL7eQ1z8lGR13OMWTTaTn79F6V13pd3q O8vZHwfhcewQT3XLIE+5qaMCjWdmM7OpGtuCOAN1vsBOCRsrebSiD5cDqmmtET+TaB vRWX9BbTjf8mYtaH63vJk/6bi5cmmoTtlyykmZtE=
Date: Tue, 14 Jan 2020 15:47:22 -0800
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK66KF37QIUHKLJCH7N4FOCYVEVBNHHCBO6ZLI@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/review/342913018@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_5e1e530af3089_30ba3ff8820cd96410848"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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/4AyXohDGXaLrr28Gb8EfbWdmHRM>
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, 14 Jan 2020 23:47:25 -0000

LPardue requested changes on this pull request.

Where is the "Disapprove" button? :)

I previously argued for relaxation of a connection error related to reducing Push ID limits. The argument against relaxation was that the client (in this case) has all required information to prevent such an occurence. 

This proposal seems advantagous but I'd say it makes the protocol too meek. Especially control frames on request streams. For example, a server that can wants to operate this way will accept bogus frames on a client's requests streams, so it will probably accept a request and then abort the stream causing the client to be starved (and eventually timeout?). Attack of the zombie H3 connections. 



-- 
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#pullrequestreview-342913018

v2.29.0 | Report a Bug | By Email | System Status