Re: [quicwg/base-drafts] QUIC lacks on-path exposure of packet loss (#3189)

Mark Nottingham <notifications@github.com> Wed, 06 November 2019 00:39 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 96EBA1200E9 for <quic-issues@ietfa.amsl.com>; Tue, 5 Nov 2019 16:39:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 TMHR_njxnHAB for <quic-issues@ietfa.amsl.com>; Tue, 5 Nov 2019 16:39:08 -0800 (PST)
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 046781200C3 for <quic-issues@ietf.org>; Tue, 5 Nov 2019 16:39:08 -0800 (PST)
Received: from github-lowworker-f045d1f.ac4-iad.github.net (github-lowworker-f045d1f.ac4-iad.github.net [10.52.19.54]) by smtp.github.com (Postfix) with ESMTP id 434CE52084B for <quic-issues@ietf.org>; Tue, 5 Nov 2019 16:39:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573000746; bh=ZYZ89XQJNoYIX/a7gk8pMw+f0bpUZMZ88F8YzEZH0Kw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YE56wpCofrSOAo5jT3lNXet2C2XxA9QqpAfEB/W0XLSeodI6yo36oJlWejSW8OdQL Mh/w6xJTqj/lZmkBkNT2wHa1onFooj163tZBsvQCHbTduGZwYQULjQlOQLAjSmR+Zb +oHzAjSFbAKYmV82d9S2ZA/lNkoAqMOnoVZZx+JQ=
Date: Tue, 05 Nov 2019 16:39:06 -0800
From: Mark Nottingham <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4WLBBGR3ACHKOQDVN3Z5EKVEVBNHHB5VOOHI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3189/550088196@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3189@github.com>
References: <quicwg/base-drafts/issues/3189@github.com>
Subject: Re: [quicwg/base-drafts] QUIC lacks on-path exposure of packet loss (#3189)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc2162a33260_7f173fadf60cd96815852b"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mnot
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/23eggbkI1UZG9YIdaqqMkZocqrk>
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, 06 Nov 2019 00:39:10 -0000

_Chair hat on_

You have brought what appears to be a concrete proposal, but it comes extremely late in the process; we have come to consensus (in #632) not only that we won't address this in QUICv1, but also that we've [raised the bar for new issues](https://mailarchive.ietf.org/arch/msg/quic/tsm7Dln_ssvHiBSZLp7LH9x44DU) on this draft. 

The question, then, is whether this proposal counts as new information (and note that the late-stage process consensus call lists the primary types of new information as "security and interoperability impact"). Given not only that higher bar but also that so many participants considered this a settled question, I want to consult with @larseggert about how we should triage this issue, and _if_ we accept it as a new design issue, how the discussion should commence.

Until then, there's no need for WG participants to weigh in on this; please use your time to work on other issues and your implementations.

P.S. You [mentioned this work](https://mailarchive.ietf.org/arch/msg/quic/FL_6Qxrz-RejKlBpGLxdnivPK5Q) in the IETF105 timeframe (and presented to other groups then), but did not make it clear that it was a proposal for QUIC -- @igorlord's words on list were "The draft is not targeted at the QUIC WG specifically". We took you at your word and did not give your draft time in the meeting then; that's a shame, because if you had been more forthcoming, we would have had more options to evaluate this work.


-- 
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/3189#issuecomment-550088196