Re: [quicwg/base-drafts] Use a "stream" for transmitting CIDs (#1826)

Kazuho Oku <notifications@github.com> Tue, 02 October 2018 20:09 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 34BAB1310AB for <quic-issues@ietfa.amsl.com>; Tue, 2 Oct 2018 13:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.456
X-Spam-Level:
X-Spam-Status: No, score=-8.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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_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 xrM_L2OjbYYh for <quic-issues@ietfa.amsl.com>; Tue, 2 Oct 2018 13:09:29 -0700 (PDT)
Received: from out-16.smtp.github.com (out-16.smtp.github.com [192.30.254.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD84131067 for <quic-issues@ietf.org>; Tue, 2 Oct 2018 13:09:29 -0700 (PDT)
Date: Tue, 02 Oct 2018 13:09:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538510968; bh=OaeoGRuATrxz5agzwnuZOEePWLMGTciOj2chEj7ToKE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=okJZSZOKCO5vS/OMjNDkokvjFuk5oGIYhLcJt4wPX/ESblnJFBCVBE5NSKZBFI1bJ OuZaaM9QTegdb9403WGPGaMOpjf5UvyR7x0IdJ97JVPu5b0A9CrEQjFZv0PKZC1dLn ZjJrYsYvj3K56atdCeHnvO1S3QEDA9yyItaJBkHs=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6fb6e38b8604dd2195326317235bdcb795d323d092cf0000000117cb927092a169ce15d12f59@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1826/426412476@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1826@github.com>
References: <quicwg/base-drafts/issues/1826@github.com>
Subject: Re: [quicwg/base-drafts] Use a "stream" for transmitting CIDs (#1826)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb3d070204a6_675e3fad3b0d45bc2200ec"; 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/edDk2-8akD8_XHvFLGmtF-ODc1A>
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, 02 Oct 2018 20:09:31 -0000

@nibanks 
> I still feel that making them a stream is more overhead than necessary. For instance, if you sent three new CIDs to the peer and the first is lost, if you have a stream design, the second two stay around longer than necessary on the sender side.

It is true that head-of-line blocking exists. But IMO it is not an issue latency-wise (because there is no need to race for 1-RTT for delivering / retiring CIDs) nor memory-wise (because CIDs are so small compared to stream buffers and because there would only be few CIDs inflight.

> Overall, I'm still not sure of the problem that currently exists that this is the solution to. What doesn't work with the current model that would require this design to fix? I feel like we're at a phase where we should start taking changes required to fix a particular problem, not changes that (some believe) make for a cleaner design.

FWIW, my view is that the proposal retains the new model (i.e. retirement of CIDs always transmitted as an explicit signal), at the same time changing the transmission framework of the CIDs to a mechanism that have proven record (rather than introducing a framework specific to the purpose).

As I have stated earlier, it is beneficial to use a proven method because we are at a later moment like this, instead of trying to fix all the design issues of a framework specific to transmitting CIDs that we haven't seen any interop.

-- 
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/1826#issuecomment-426412476