Re: RE: [External] New Version Notification for draft-chen-quic-quicu-01.txt
Yongyi Yu <yuyongyi.yyy@bytedance.com> Tue, 27 September 2022 15:04 UTC
Return-Path: <yuyongyi.yyy@bytedance.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 93BE9C157B3A for <quic@ietfa.amsl.com>; Tue, 27 Sep 2022 08:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bytedance-com.20210112.gappssmtp.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 FPx1DRm9olqj for <quic@ietfa.amsl.com>; Tue, 27 Sep 2022 08:04:03 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 9A1BEC157B4A for <quic@ietf.org>; Tue, 27 Sep 2022 08:04:03 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id i15-20020a17090a4b8f00b0020073b4ac27so10317608pjh.3 for <quic@ietf.org>; Tue, 27 Sep 2022 08:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:in-reply-to:from:mime-version :references:from:to:cc:subject:date; bh=Ty2YzXQbOmY4uH/6okkD+6dAeN/1PJw+Qk7B61COIN8=; b=YFccr/YupI3prBeeNxYov/Ypz3lWxaHl9Y7wb8Tj933ZHBeFHz3e+kCvS8nabgQGLj DeuliFb1UbpBxjcC0LAG/v3IAy1vsBLJU+1FdECB9ow7Edeic119KFLA2u9j2Zh/SlYE 7fVm5Oro/9H12Cnt1skZflwuKMcvkgua5ToGEu0X5drOngpxh3G8nkNgRsyYeL8aSDKD VJeqn6gzIv8UJiPD9EU6d6UcM/mjGJC5n1bc9jGpv4CINc/eMRpOT1mdwDLhYugKXjuk JRqOlj2AFqohdZm6pRzbAtbGmEzf51AcrJsY1Fzo97dW+cNnG99cY0Bet4Kxn1aZduLA Q0Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:in-reply-to:from:mime-version :references:x-gm-message-state:from:to:cc:subject:date; bh=Ty2YzXQbOmY4uH/6okkD+6dAeN/1PJw+Qk7B61COIN8=; b=ym5buIqsPV8ikCFjt9WL88VSRSqMbHKVNmvbmTEVmenz9uYgkgtcqxS1MudJiKV5MY TW+ay4kCH1hDk8JCEeJQqOMPU9T4qgb0K7xt1qJFLNZHmOOpvp2FeAC0SvWDvYA3CpFJ UhvVTXKXCjSbhaJ4dY9MUS9JcG39G08UeQev2FoasbZ7/ONLcbLuIPGr6+2roXutK0mW RN4HWyEsZ05zMC5gRJw2yCcz+IFkU5DWUDKJvBXOfyzm1oHIPBn+xA/K8zyv6/Pu494W fkiJkdHq2KVpWa8AQCRbXR9Ll4HPYzJ5bVYQrpT8rTk7G9A0ErULJdcVv1qSkLofszJx uMzQ==
X-Gm-Message-State: ACrzQf0qP617EvweIgVq9UCBFYzlwGsQbGEjjTeoXtviNT55AN+KOG1U SRX8LKsjaNSfFK0EW9TSWls+OirAtFKPLI90y5P7qlkqFK5CgQ==
X-Google-Smtp-Source: AMsMyM7P461zHg+/Q+8ZzmqlKTcth9qZF0pGaodaNRWSc7Yc74vfuK5yHJOBFe0IlIBwoet+WzOtviibDuRg/3/+A9Q=
X-Received: by 2002:a17:90b:1b0b:b0:205:9926:3a6b with SMTP id nu11-20020a17090b1b0b00b0020599263a6bmr4979979pjb.139.1664291041947; Tue, 27 Sep 2022 08:04:01 -0700 (PDT)
Received: from 349319672217 named unknown by gmailapi.google.com with HTTPREST; Tue, 27 Sep 2022 08:04:01 -0700
References: <166359205152.6422.10161941398731313578@ietfa.amsl.com> <CAGAnozYePCwo5S-EUTN4X=-EixNFVgF+1MwiD60-GDogw7ojnA@mail.gmail.com> <CAJ_4DfS8n5sZXEk0=Eojq_DEK6QGvgG6-KjOiVnHv8etxzCSkQ@mail.gmail.com> <AE5493E8-DFAD-42F2-A41C-4B924B8602EF@apple.com> <CAGAnozZHFChVbK2MNkxVm5XbF3msGyHuRy1er7OjAGPzE_EMLQ@mail.gmail.com> <d0f85f1306c94e8d92ad4ad706e9f48f@akamai.com>
Mime-Version: 1.0
From: Yongyi Yu <yuyongyi.yyy@bytedance.com>
In-Reply-To: <d0f85f1306c94e8d92ad4ad706e9f48f@akamai.com>
Date: Tue, 27 Sep 2022 08:04:01 -0700
Message-ID: <CAGAnozaGaYNPFFcv3SXM9wqWJ+NWUh_+bTKFcp_D0_fuQUd0Aw@mail.gmail.com>
Subject: Re: RE: [External] New Version Notification for draft-chen-quic-quicu-01.txt
To: "Lubashev, Igor" <ilubashe@akamai.com>
Cc: Tommy Pauly <tpauly@apple.com>, Ryan Hamilton <rch=40google.com@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>, 陈鉴平 <chenjianping.ireader@bytedance.com>, 景君羡 <jingjunxian@bytedance.com>, 刘天一 <liutianyi.lty@bytedance.com>
Content-Type: multipart/alternative; boundary="0000000000005c0b6b05e9a9f477"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/0_-2sVpg2Wbg6oH2F36L_7PfZmA>
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: Tue, 27 Sep 2022 15:04:07 -0000
Hi Igor, Thanks for your replying. Our proposal indeed shares similar ideas with yours, but there are also some difference. We'd like to update our draft to clarify the difference in detail, and to briefly summary here, there are three major points. 1. Our proposal splits a QUIC stream into many data blocks by Boundary Frame. The receiver would provide data to the application layer only when a data block is completely received. Therefore, the application layer needn't be aware of the gap at the expiration point or discard data already read. 2. Because the stream is split into blocks, the sender could send or expire data by data blocks. Then the transport layer could track the message boundaries instead of the application layer. 3. With the introduction of Correlation Frame, we can combine multiple QUIC streams into single data stream while avoiding head of line blocking. This feature could be quite useful in many scenarios, e.g., transmitting both video and audio data through single HTTP response. Please do let me know if you have any further advice, and please do not hesitate to point out if I make any mistakes. Thanks, Yongyi. From: "Lubashev, Igor"<ilubashe@akamai.com> Date: Mon, Sep 26, 2022, 00:29 Subject: RE: [External] New Version Notification for draft-chen-quic-quicu-01.txt To: "Yongyi Yu"<yuyongyi.yyy@bytedance.com>, "Tommy Pauly"<tpauly@apple.com> Cc: "Ryan Hamilton"<rch=40google.com@dmarc.ietf.org>, "quic@ietf.org"< quic@ietf.org>, "陈鉴平"<chenjianping.ireader@bytedance.com>, "景君羡"< jingjunxian@bytedance.com>, "刘天一"<liutianyi.lty@bytedance.com> Are you trying to implement something like https://datatracker.ietf.org/doc/html/draft-lubashev-quic-partial-reliability-02 or https://datatracker.ietf.org/doc/html/draft-lubashev-quic-partial-reliability-03? (The -02 and -3 versions have somewhat different properties, and some people prefer -02 version.) - Igor *From:* Yongyi Yu <yuyongyi.yyy@bytedance.com> *Sent:* Friday, September 23, 2022 1:11 AM *To:* Tommy Pauly <tpauly@apple.com> *Cc:* Ryan Hamilton <rch=40google.com@dmarc.ietf.org>; quic@ietf.org; 陈鉴平 < chenjianping.ireader@bytedance.com>; 景君羡 <jingjunxian@bytedance.com>; 刘天一 < liutianyi.lty@bytedance.com> *Subject:* Re: [External] New Version Notification for draft-chen-quic-quicu-01.txt Thanks for your replying. I agree "partial reliability" fits our draft better, since we do retransmit lost data and provide in-order transmission. And, our proposal could be compatible with H3, should we clarify the behavior in the draft? Please do let me know if you have any further advice. Thanks, Yongyi. From: "Tommy Pauly"< <tpauly@apple.com>tpauly@apple.com> Date: Thu, Sep 22, 2022, 11:32 Subject: Re: [External] New Version Notification for draft-chen-quic-quicu-01.txt To: "Ryan Hamilton"< <rch=40google.com@dmarc.ietf.org> rch=40google.com@dmarc.ietf.org> Cc: "于涌溢"< <yuyongyi.yyy@bytedance.com>yuyongyi.yyy@bytedance.com>, " quic@ietf.org"< <quic@ietf.org>quic@ietf.org>, "陈鉴平"< <chenjianping.ireader@bytedance.com>chenjianping.ireader@bytedance.com>, " 景君羡"< <jingjunxian@bytedance.com>jingjunxian@bytedance.com>, "刘天一"< <liutianyi.lty@bytedance.com>liutianyi.lty@bytedance.com> I noticed that this draft does reference RFC 9221, and DATAGRAM frames. If I’m understanding correctly, it seems like this is trying to define an approach for what’s more commonly referred to as “partial reliability”, which was something DATAGRAM explicitly didn’t try to include. If this is the case, I think it would be useful to reframe the document in terms of that, since the heavy use of “unreliable” is quite confusing. It also isn’t clear to me how this proposal would work with specific application protocols on top of QUIC — is this something that’s meant to be compatible with H3, or is it for entirely separate use cases? Best, Tommy On Sep 21, 2022, at 3:17 PM, Ryan Hamilton <rch=40google.com@dmarc.ietf.org> wrote: QUIC has support for unreliable data via the DATAGRAM frame, RFC 9221 <https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc9221__;!!GjvTz_vk!VHC6upHgCOojEiYhln21JerQBPYz1cbPLifo7gevl5sFTM-5qEoTkN-TxpvuKG1MQfnSBiZsXrrQ2OC2qjWu1aws$>. 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-quic-quicu-01__;!!GjvTz_vk!VHC6upHgCOojEiYhln21JerQBPYz1cbPLifo7gevl5sFTM-5qEoTkN-TxpvuKG1MQfnSBiZsXrrQ2OC2qol99skU$> 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>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> chenjianping.ireader@bytedance.com>, "Junxian Jing"< <jingjunxian@bytedance.com>jingjunxian@bytedance.com>, "Tianyi Liu"< <liutianyi.lty@bytedance.com>liutianyi.lty@bytedance.com>, "Yongyi Yu"< <yuyongyi.yyy@bytedance.com>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://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-chen-quic-quicu-01.txt__;!!GjvTz_vk!VHC6upHgCOojEiYhln21JerQBPYz1cbPLifo7gevl5sFTM-5qEoTkN-TxpvuKG1MQfnSBiZsXrrQ2OC2qgIVZwR1$> https://www.ietf.org/archive/id/draft-chen-quic-quicu-01.txt Status: <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-chen-quic-quicu/__;!!GjvTz_vk!VHC6upHgCOojEiYhln21JerQBPYz1cbPLifo7gevl5sFTM-5qEoTkN-TxpvuKG1MQfnSBiZsXrrQ2OC2qqEw9hmD$> https://datatracker.ietf.org/doc/draft-chen-quic-quicu/ Htmlized: <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-quic-quicu__;!!GjvTz_vk!VHC6upHgCOojEiYhln21JerQBPYz1cbPLifo7gevl5sFTM-5qEoTkN-TxpvuKG1MQfnSBiZsXrrQ2OC2qk9rs9H6$> https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu Diff: <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-chen-quic-quicu-01__;!!GjvTz_vk!VHC6upHgCOojEiYhln21JerQBPYz1cbPLifo7gevl5sFTM-5qEoTkN-TxpvuKG1MQfnSBiZsXrrQ2OC2qv4nuLVS$> 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
- Fw: [External] New Version Notification for draft… 于涌溢
- Re: Fw: [External] New Version Notification for d… Ryan Hamilton
- Re: [External] New Version Notification for draft… Tommy Pauly
- Re: [External] New Version Notification for draft… Yongyi Yu
- RE: [External] New Version Notification for draft… Lubashev, Igor
- Re: [External] New Version Notification for draft… Matt Joras
- Re: [External] New Version Notification for draft… Matt Joras
- Re: [External] New Version Notification for draft… Yongyi Yu
- Re: RE: [External] New Version Notification for d… Yongyi Yu
- Re: RE: [External] New Version Notification for d… Yongyi Yu
- RE: RE: [External] New Version Notification for d… Lubashev, Igor
- Re: [External] New Version Notification for draft… Konstantin Tsoy
- Re: [External] New Version Notification for draft… Ryan Hamilton
- RE: [External] New Version Notification for draft… Konstantin Tsoy
- Re: [External] New Version Notification for draft… Yongyi Yu
- Re: RE: RE: [External] New Version Notification f… Yongyi Yu
- RE: [External] New Version Notification for draft… Shihang(Vincent)
- Re: RE: [External] New Version Notification for d… Roberto Peon
- RE: RE: RE: [External] New Version Notification f… Lubashev, Igor
- Re: RE: [External] New Version Notification for d… Yongyi Yu
- RE: [External] New Version Notification for draft… Shihang(Vincent)