Re: [quicwg/base-drafts] WIP: Begin lightly abstracting over the use of UDP as the underlying transport (#4043)

John Ericson <notifications@github.com> Sat, 29 August 2020 03:05 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 7B7903A0F57 for <quic-issues@ietfa.amsl.com>; Fri, 28 Aug 2020 20:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 nYzbyzN3PZch for <quic-issues@ietfa.amsl.com>; Fri, 28 Aug 2020 20:05:38 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5BC3A0C68 for <quic-issues@ietf.org>; Fri, 28 Aug 2020 20:05:37 -0700 (PDT)
Received: from github-lowworker-2ef7ba1.ac4-iad.github.net (github-lowworker-2ef7ba1.ac4-iad.github.net [10.52.16.66]) by smtp.github.com (Postfix) with ESMTP id 0B5419025D8 for <quic-issues@ietf.org>; Fri, 28 Aug 2020 20:05:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1598670337; bh=AqYe0fslYQIFV/odPksnT1yq3RLICl0R7ue0K9m0JGs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=c4hN7DH0srHMvMGrOGa/6mq9G1k5+c4hO7jC/u2IsBQsIUZ5qV24uHAk37kMmfX7z yzrEC6t6gIofUBX0rqhONanEZ7TwEaJUXYOGtKm1W6Y88O/7EkKq2zF686D0/FE+yR IDRI9ofFn8fycAWYdfyPNnx553H/Bkz5tgLM1KN8=
Date: Fri, 28 Aug 2020 20:05:36 -0700
From: John Ericson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5OTYRMIDIOFZCN6OV5KWTQBEVBNHHCROOLIU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/4043/c683226997@github.com>
In-Reply-To: <quicwg/base-drafts/pull/4043@github.com>
References: <quicwg/base-drafts/pull/4043@github.com>
Subject: Re: [quicwg/base-drafts] WIP: Begin lightly abstracting over the use of UDP as the underlying transport (#4043)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f49c600f0768_3666196417443"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: Ericson2314
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/zi8KsKqPSDIZyL6mW4z5rRVU6sg>
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: Sat, 29 Aug 2020 03:05:40 -0000

@LPardue @MikeBishop So, going the basic thrust of both your comments so far, We'd end up with fewer constraints on the underlying protocol (e.g. need not be message-origin) and a good bit of information being conditioned on UDP only (ECN, MTU discovery and associated limits and restrictions, etc.). I see very different conclusions one might make based on that, such as:

1. Negative: Meaningfully generalizing QUIC is too difficult because so much is UDP specific, and we'd need to make sure the remainder stands on its own.

2. Neutral: Fine to just continue conditioning sections on being UDP-specific, and just leave fleshing out the remainder for other transports as a future exercise.

3. Positive: It's great there are so many UDP-specific details we can cut away. It would be good to reorder or even split the document to make UDP-specific vs UDP-agnostic a prominent axis around which the standard is organized.

I think before I put too much more work with it, would be good to confirm whether you agree with this analysis, and if so, which outlook you both take. Most of the broad feedback is still negative, so I don't want to just stir emotions while beating a dead horse.

-- 
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/4043#issuecomment-683226997