From nobody Wed Sep 8 09:40:45 2021 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606913A2E74 for ; Wed, 8 Sep 2021 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7JjFCQLjwMaZ for ; Wed, 8 Sep 2021 09:40:39 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BE03A2E73 for ; Wed, 8 Sep 2021 09:40:38 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id m9so4258171wrb.1 for ; Wed, 08 Sep 2021 09:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hUWVthZrqiGM9kf+GRl4mBORrG5zKZJIfmALDfeIUHI=; b=fl8bkZa9n8Tk9/WS5KA4u4I679zShYkXwd3ZCo0PTgfI4XHJotJHBCUmcpHal0mBqD TDe9mc6nrb8JwcGAkd3bcXT7tbRlsNy1XoLsGRL4qf1rcmeWnQg6GhFPlSxCI5ojXzFN iK95k5PgoYEKn/yZ7sdgdDm5D/dqPz1QwnBxuFy2HlZ+9LkFkuJRbP2NS87kmyQG+n16 Mda1ejl18JiWq0HX9geqhiJpCmAEjdsi4TNcpfPYskDkWTOntQn6X6VqJdtwWsZ6ueQu OlA6etmueZ6uWbLR3yutJuY16KgccifJv+Z4y6YQ9qSjCY1eCGXyp4J4+C1jADH2p4H3 fMyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hUWVthZrqiGM9kf+GRl4mBORrG5zKZJIfmALDfeIUHI=; b=6VOGRO0OYd03c9YRWh3y/mBRtvlgbDgAbPGmhFJNvHthWBzhTIKqcloQ1qdyhDWOoe QltgyO0hUx0cbvPcY9VMW7Xow3JvJ/fndGQJ1caMdjkN+rtDSGnvsXekahXj8KrybAYF uMrwhoS3DsUQp4f9aYjgda0qKmf4l8xTcgpqkltLMkKvpLSZzugeXTezpW+zSf9sCPBI URmyYxDU8XmSjvEq56FKiBMTOGOnbVlO6pQkEzZsRi9OHbFmD6P2ZYsVsMh4ueESUa9s A9/gcEDSQSHiQV52Wy71gOgm3Drlfcm5GQWOwqdm9HAPQ5TG+Bhv7fpMME654by+8cxO FLxA== X-Gm-Message-State: AOAM532uRLTyXY1vke+oi+B4poTZJWNFOu5BSyFhBOlFoZbBHEsE1fn8 dYkUjWhibZWWSgxpb+0TzSeeg9PX1I+9yR2hVwWNtt+jBPw= X-Google-Smtp-Source: ABdhPJyF6T9Bvj00hCqsz1gJLFWGyVOyxgXt9E5wEPARjHHri9/C3qpNeuST7LiWzc61FZB14g/K+Q22NbjjJeuqd7U= X-Received: by 2002:a5d:438a:: with SMTP id i10mr5234886wrq.285.1631119236163; Wed, 08 Sep 2021 09:40:36 -0700 (PDT) MIME-Version: 1.0 References: <16d22e18-a169-418c-89af-0355a241fbf0@www.fastmail.com> In-Reply-To: From: Ryan Hamilton Date: Wed, 8 Sep 2021 09:40:23 -0700 Message-ID: Subject: Re: Consensus call for adding support for non-ack eliciting DATAGRAMs To: Ian Swett Cc: Martin Thomson , quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000a8b7a705cb7e8ac9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 16:40:45 -0000 --000000000000a8b7a705cb7e8ac9 Content-Type: text/plain; charset="UTF-8" Well said, Ian and Martin. I agree that no change is the right outcome here. On Wed, Sep 8, 2021 at 8:53 AM Ian Swett wrote: > Agreed, if we're going to do this, I'd like to address it in the ack > frequency draft and not in datagram. I also think there are valid use > cases to not ACK stream data as well, such as Media over QUIC, where frames > may not fit into a single QUIC packet. > > On Wed, Sep 8, 2021 at 8:22 AM Martin Thomson wrote: > >> No change is good. It's nothing we can't fix trivially later if we find >> that was the wrong outcome. And getting this right, even if it were >> needed, would be tricky. It's also not all that useful when you consider >> that ack frequency exists as a way to manage the cost and overhead of >> acknowledgments. >> >> On Wed, Sep 8, 2021, at 21:31, Lucas Pardue wrote: >> > Hello QUIC WG, >> > >> > This is a consensus call for datagram issue #42 [1] - Allow a Sender to >> > Control Datagram ACKs. The proposed resolution is to close this issue >> > with no action. >> > >> > If you object to the proposal, please do so on the issue or in response >> > to this message. >> > >> > The call will run for one week, closing at end of day on September 15 >> > 2021, anywhere on earth. >> > >> > [1] https://github.com/quicwg/datagram/issues/42 >> >> --000000000000a8b7a705cb7e8ac9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well said, Ian and Martin. I agree that no change is the r= ight outcome here.

On Wed, Sep 8, 2021 at 8:53 AM Ian Swett <ianswe= tt=3D40google.com@dmarc.ietf= .org> wrote:
Agreed, if we're going to do this, I'd like to= address it in the ack frequency draft and not in datagram.=C2=A0 I also th= ink there are valid use cases to not ACK stream data as well, such as Media= over QUIC, where frames may not fit into a single QUIC packet.

On Wed, Sep = 8, 2021 at 8:22 AM Martin Thomson <mt@lowentropy.net> wrote:
No change is good.=C2=A0 It's nothin= g we can't fix trivially later if we find that was the wrong outcome.= =C2=A0 And getting this right, even if it were needed, would be tricky. It&= #39;s also not all that useful when you consider that ack frequency exists = as a way to manage the cost and overhead of acknowledgments.

On Wed, Sep 8, 2021, at 21:31, Lucas Pardue wrote:
> Hello QUIC WG,
>
> This is a consensus call for datagram issue #42 [1] - Allow a Sender t= o
> Control Datagram ACKs. The proposed resolution is to close this issue =
> with no action.
>
> If you object to the proposal, please do so on the issue or in respons= e
> to this message.
>
> The call will run for one week, closing at end of day on September 15 =
> 2021, anywhere on earth.
>
> [1] https://github.com/quicwg/datagram/issues/42

--000000000000a8b7a705cb7e8ac9--