IETF Logo Mail Archive

Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)

kaigao@scu.edu.cn Tue, 28 November 2023 03:19 UTC

Return-Path: <kaigao@scu.edu.cn>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC7DC14CEFA; Mon, 27 Nov 2023 19:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level:
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL=1.31, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
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 wkJK9BUZKFvp; Mon, 27 Nov 2023 19:19:25 -0800 (PST)
Received: from sgoci-sdnproxy-4.icoremail.net (sgoci-sdnproxy-4.icoremail.net [129.150.39.64]) by ietfa.amsl.com (Postfix) with ESMTP id D9D1EC14CF1B; Mon, 27 Nov 2023 19:19:22 -0800 (PST)
Received: from kaigao$scu.edu.cn ( [125.70.169.101] ) by ajax-webmail-app1 (Coremail) ; Tue, 28 Nov 2023 11:19:20 +0800 (GMT+08:00)
X-Originating-IP: [125.70.169.101]
Date: Tue, 28 Nov 2023 11:19:20 +0800
X-CM-HeaderCharset: UTF-8
From: kaigao@scu.edu.cn
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Kai GAO <godrickk@gmail.com>, Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>, The IESG <iesg@ietf.org>, alto-chairs@ietf.org, draft-ietf-alto-new-transport@ietf.org, alto@ietf.org
X-Priority: 3
X-Mailer: Coremail Webmail Server Version 2023.2-cmXT5 build 20230915(bf90896b) Copyright (c) 2002-2023 www.mailtech.cn scu
In-Reply-To: <CAM4esxTTdQt8aP_Z99rkpaUbYXPjM7YVOBer8UOmuapPd5+yRQ@mail.gmail.com>
References: <169831780119.36194.13653420443569229487@ietfa.amsl.com> <CAOELiNOBp2b=aGvn6k3O92ByN=-T2c0Ey+25hco4CQ69Bv4g7g@mail.gmail.com> <CAM4esxTTdQt8aP_Z99rkpaUbYXPjM7YVOBer8UOmuapPd5+yRQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="----=_Part_24350_1607642323.1701141560247"
MIME-Version: 1.0
Message-ID: <2f7d6615.1ae3.18c13f03bb7.Coremail.kaigao@scu.edu.cn>
X-Coremail-Locale: en_US
X-CM-TRANSID: Mf0DCgB3iXg4XGVl7HkqAA--.1664W
X-CM-SenderInfo: 5ndlwt3r6vu3oohg3hdfq/1tbiAQYJB2Vkl+si5gACsy
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/po0Crgm-tpMBylWVjYqUt5LR_Co>
Subject: Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Nov 2023 03:19:27 -0000

Hi Martin,

The paragraph is in -19 which I just submitted. Thanks for the reminder.

Best,

Kai




-----Original Messages-----
From:"Martin Duke" <martin.h.duke@gmail.com>
Send time:Tuesday, 11/28/2023 05:29:06
To: "Kai GAO" <godrickk@gmail.com>
Cc: "Zaheduzzaman Sarker" <zahed.sarker.ietf@gmail.com>, "The IESG" <iesg@ietf.org>, alto-chairs@ietf.org, draft-ietf-alto-new-transport@ietf.org, alto@ietf.org, "Kai Gao" <kaigao@scu.edu.cn>
Subject: Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)


Two comments:


On Tue, Nov 21, 2023 at 7:09 AM Kai GAO <godrickk@gmail.com> wrote:

- I didn't find any explanation of how the "Concurrent, non-blocking update
transmission" requirement is meet by the new transport. is this solved by the
use of HTTP/3 with uses QUIC and does not have HOL blocking within a
connection? Or is this addressed by multiple concurrent HTTP connection to the
ALTO server? This need to be understood better and we should define what
actually "Concurrent, non-blocking update transmission" means in this context
of fetching updates.




HTTP/2 was of course intended to be non-blocking at the application layer. Resources can be delivered whenever they are ready, instead of in order of request. That's pretty important for update use cases like this one.


Of course, it doesn't solve blocking related to packet loss -- that's what QUIC is for. But it's totally accurate to say that this transport provides non-blocking transmission under either version of HTTP.


 
 
[KAI] The requirement basically requires that incremental updates can be transmitted
at the same time (concurrent) and the transmission of one update will not be blocked
by the transmission of another update. This can be realized by 1) multiple HTTP
connections, or 2) HTTP/3 using multiple streams. This is compared with RFC 8895
where SSE multiplexes the updates in a single sequence. You make a good point that
we should clarify how this can be done with new transport. We will add a paragraph to
Sec 2.1 and upload a revision soon.



I don't see a new paragraph in Sec 2.1 in draft-18. Please post a new draft with the change, or update this thread with your changed intent.

v2.23.0 | Report a Bug | By Email