Re: Fw: [External] New Version Notification for draft-chen-quic-quicu-01.txt

Ryan Hamilton <rch@google.com> Wed, 21 September 2022 22:17 UTC

Return-Path: <rch@google.com>
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 4D8D2C1524D9 for <quic@ietfa.amsl.com>; Wed, 21 Sep 2022 15:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -22.607
X-Spam-Level:
X-Spam-Status: No, score=-22.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEHYnU31qBfQ for <quic@ietfa.amsl.com>; Wed, 21 Sep 2022 15:17:24 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0761EC14F727 for <quic@ietf.org>; Wed, 21 Sep 2022 15:17:24 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id 125so10106004ybt.12 for <quic@ietf.org>; Wed, 21 Sep 2022 15:17:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=gK38p/Kbh64h3uMRGsgR9vrjhZHoCIHuTO1mIbOvOnk=; b=S6vVDzpDlimcXkx6/PBgmFLLuQIZRKWkKQ5WZiIvahbBmgHz5zELx8U1N4qG1RJ7HP VTYDsOmlykDg4zfQQMmYtN7jJafWUcIePgu6erJaEcRB6C9pZw1RUTyPFJJ04Ttq8a7q YOqTvSTF/i3AEmTinwxlKNQ+ZW04pDkhy8TbJJq8Of0Suo8+sMKzWbBdoYfQ8WHKAlzM 2/HDs727+gINbsm7UbLJVIU/eiMJxDhuHDdD+kWttu0kV1A8RRixFQ98EzhXJCEP6Zhd s/gtbVs299yI6C5Ff+pFrXzXebXSnNiC+PQPLJe5SZ7H6aqdbImYB5PnPuJvp1cCd6w3 nBJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=gK38p/Kbh64h3uMRGsgR9vrjhZHoCIHuTO1mIbOvOnk=; b=wT4DnPQICBaEdCOakg6sxKuM4fKz/x8B/+IAzmOYSscWoNOyOV6FXznG2IvR67HYzf 3+1uz7/QRnnnFfkdfQC/pABo+kP/q+BfAjYhos875IAC6ciJUwpBFodeN0BIIPASqupE 5MZD46vxVm4+WdTqtX1rOkDWeT0r1HrVDfSqeYIsGAqz/yT71mHaR4LQvoPHHLiCjRkw WfJdaHgRfOQDSI+yHnXL0B+7lr3ZL+QNRt9qsUubqOWCOx1q53ufu4SpYFU8CdSDDwo2 LjHoOgylAOCEway8X/2Ta6Dsbkrb4nrBXgz0oLEdUxliBrxJGxek7Rhxl5uIVTbn1wql sU3A==
X-Gm-Message-State: ACrzQf2zHvCDCCci+CL6whVoFjSxpgYBD5WAt6cm6QsM+JV2olruWWgI wL9MqXKZeQH6bnMRAAkiR0EnnbcZM60XI+6GqOmrWA==
X-Google-Smtp-Source: AMsMyM6YwqkHbpGokp2jAGE17xkAerzoYftlsbOllLmWUos/a+aNHa8MsFkzikBzcj0MPi0wGU2TcOvfyoW1zH4Pzho=
X-Received: by 2002:a25:d487:0:b0:6a9:3faf:ca99 with SMTP id m129-20020a25d487000000b006a93fafca99mr605655ybf.16.1663798642712; Wed, 21 Sep 2022 15:17:22 -0700 (PDT)
MIME-Version: 1.0
References: <166359205152.6422.10161941398731313578@ietfa.amsl.com> <CAGAnozYePCwo5S-EUTN4X=-EixNFVgF+1MwiD60-GDogw7ojnA@mail.gmail.com>
In-Reply-To: <CAGAnozYePCwo5S-EUTN4X=-EixNFVgF+1MwiD60-GDogw7ojnA@mail.gmail.com>
From: Ryan Hamilton <rch@google.com>
Date: Wed, 21 Sep 2022 15:17:11 -0700
Message-ID: <CAJ_4DfS8n5sZXEk0=Eojq_DEK6QGvgG6-KjOiVnHv8etxzCSkQ@mail.gmail.com>
Subject: Re: Fw: [External] New Version Notification for draft-chen-quic-quicu-01.txt
To: 于涌溢 <yuyongyi.yyy@bytedance.com>
Cc: "quic@ietf.org" <quic@ietf.org>, 陈鉴平 <chenjianping.ireader@bytedance.com>, 景君羡 <jingjunxian@bytedance.com>, 刘天一 <liutianyi.lty@bytedance.com>
Content-Type: multipart/alternative; boundary="00000000000014019905e9374f39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KAvkrtKr5snnrZMeTwSGJana9ZM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2022 22:17:28 -0000

QUIC has support for unreliable data via the DATAGRAM frame, RFC 9221
<https://www.rfc-editor.org/info/rfc9221>. It seems that this new proposal
attempts to add unreliable data support not to QUIC, but to QUIC *streams*.
QUIC streams, of course, offer a reliable, in-order, sequence of bytes. Did
you consider starting with DATAGRAMs, and building from there instead?

Cheers,

Ryan

On Wed, Sep 21, 2022 at 1:14 AM 于涌溢 <yuyongyi.yyy@bytedance.com> wrote:

> Deal all,
>
> We would like to introduce an extension of the QUIC protocol for
> unreliable data transmission called QUIC Unreliable (QUICU) . The following
> draft is submitted for your consideration and comments. We would also like
> to present this at IETF 115 to discuss further.
>
> To summarize on this draft: it describes an extension of the QUIC protocol
> for unreliable data transmission called QUIC Unreliable (QUICU), which
> mainly through the definition and use of three new types of frames, namely
> the Expire Offset Frame, Boundary Frame, and Correlation Frame. The main
> purpose of this extension is to reduce data delivery delay. Through
> controlling the timing and scope of packet losses, QUICU reduces useless
> transmission to improve transmission efficiency, reduces head-of-line
> blocking to improve transmission timeliness, which are beneficial to
> delay-sensitive applications, especially audio and video applications. This
> document describes the motivation, the operations, and the wire formats of
> the three new types of frames.
>
> Link to html:
> https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu-01
>
> Please feel free to reach us for any comments or questions on this.
>
> Thanks,
> Yongyi.
>
> ---------- Forwarded message ---------
> From: internet-drafts@ietf.org
> Date: Mon, Sep 19, 2022, 20:54
> Subject: [External] New Version Notification for
> draft-chen-quic-quicu-01.txt
> To: "Jianping Chen"<chenjianping.ireader@bytedance.com>, "Junxian Jing"<
> jingjunxian@bytedance.com>, "Tianyi Liu"<liutianyi.lty@bytedance.com>,
> "Yongyi Yu"<yuyongyi.yyy@bytedance.com>
> A new version of I-D, draft-chen-quic-quicu-01.txt
> has been successfully submitted by Yongyi Yu and posted to the
> IETF repository.
>
> Name:                draft-chen-quic-quicu
> Revision:        01
> Title:                An Unreliable Extension to QUIC
> Document date:        2022-09-19
> Group:                Individual Submission
> Pages:                10
> URL:
> https://www.ietf.org/archive/id/draft-chen-quic-quicu-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-chen-quic-quicu/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-chen-quic-quicu-01
>
> Abstract:
>   QUIC Unreliable (QUICU) is an extension of the QUIC protocol for
>   unreliable data transmission, mainly through the definition and use
>   of three new types of frames, namely the Expire Offset Frame,
>   Boundary Frame, and Correlation Frame. The main purpose of this
>   extension is to reduce data delivery delay. Through controlling the
>   timing and scope of packet losses, QUICU reduces useless transmission
>   to improve transmission efficiency, reduces head-of-line blocking to
>   improve transmission timeliness, which are beneficial to delay-
>   sensitive applications, especially audio and video applications.
>
>   This document describes the motivation, the operations, and the wire
>   formats of the three new types of frames.
>
>
>
>
> The IETF Secretariat
>