From zahed.sarker.ietf@gmail.com Wed Nov 29 04:01:22 2023 Return-Path: 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 E469CC14F74A; Wed, 29 Nov 2023 04:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KX0InZ55Jfjb; Wed, 29 Nov 2023 04:01:21 -0800 (PST) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 CBCACC14F73F; Wed, 29 Nov 2023 04:01:21 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2851a2b30a2so4772764a91.3; Wed, 29 Nov 2023 04:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701259281; x=1701864081; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6o6El0FU/9ZL/tToPbXIITF0Y1lye/6xSydxpZSIzac=; b=MI4FHIp37QAu7XnZTU8xYjAxx5jXwfRLmLolqGPsBKK2TGNC/DBa/ULP3Tf91RCOOy Q5xCcJxAhCinKLBiVtgpCthvtgv+xlUwtksgellGsjV5YZcjCQT2Z04gjukRfTVybNrk oVMb4QbQTpxAF1E1O1U8DQP6e4kituISg8ZoDG4Q2aWqi3POWCUz3P8rwhkdAZG5TKyU q79AZlK4EgIr8M3BjsGoUO1PlCvFLciuElwN8RuQ2rYkncZLm505FzrdqUkIb24wykI3 HYa59+Ofl3HL44qgjwO+P05dtODnOi0iAWJwJqkngjzv7F5Zx6rElfsnAmruvg6Sac01 OejA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701259281; x=1701864081; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6o6El0FU/9ZL/tToPbXIITF0Y1lye/6xSydxpZSIzac=; b=HzXlH3BEsx6ipUAvcpOJrRdyFTU+uALBNLysQnMs+jFzJ2Z1JbkUqu8zPhaviuYuC2 hq4vXKn73OpGW/RiZlmqHlRbsBi4fRPwQUQVq4NFOOhPiWMGnNwhyXQWSrd37UbGZNt/ ANIGEjSPvczEz5BySGa+NF/V8zTYwwOMjcLuAK58NEmGB1enM3WJ03wlGhPnEsFjUkiw qBfJKgAcxaZdYM7ckNpjbSvjkYSP0pTTwQU9ltTp0ce96w6MafAHZNNROJrtVVIGlHU3 zt7iUTykqMzK7N29LmHeVyRKGwOinWuuhhhj7xrt21lNxPriYxZnlMlBPDE0eFOm8A2d rNew== X-Gm-Message-State: AOJu0YxzUnH6ph0GY8lMInW/B5jFbpxbbpKeCm+gj7mgqokWAlV3ZN3Z 933zlYijzX4jSQQtWG6Jd1lTyuU9pQepgNcQz48= X-Google-Smtp-Source: AGHT+IHaLPWW5LJsl/AFUcIdEfmXLz4PxOKcVwp8kIxVl2+EbUf5hBjmUhs0XG453BHiYwL8rqbE+4wBxvfzo24yVuM= X-Received: by 2002:a17:90b:4d8b:b0:27d:c36:e12c with SMTP id oj11-20020a17090b4d8b00b0027d0c36e12cmr18512091pjb.9.1701259280988; Wed, 29 Nov 2023 04:01:20 -0800 (PST) MIME-Version: 1.0 References: <169831780119.36194.13653420443569229487@ietfa.amsl.com> <12e4e9ff.2435.18c1ae22112.Coremail.kaigao@scu.edu.cn> In-Reply-To: <12e4e9ff.2435.18c1ae22112.Coremail.kaigao@scu.edu.cn> From: Zaheduzzaman Sarker Date: Wed, 29 Nov 2023 13:01:10 +0100 Message-ID: To: kaigao@scu.edu.cn Cc: Kai GAO , The IESG , alto-chairs@ietf.org, draft-ietf-alto-new-transport@ietf.org, alto@ietf.org Content-Type: multipart/alternative; boundary="0000000000001d3d23060b494bba" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2023 12:01:23 -0000 --0000000000001d3d23060b494bba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2023 at 12:41=E2=80=AFPM wrote: > Hi Zahed, > > Thanks for the comments! Please see the responses inline. I already have > the updates in place but would like to submit a new revision after you > review the proposed texts. > > Best, > > Kai > > > -----Original Messages----- > *From:* "Zaheduzzaman Sarker" > *Send time:* Tuesday, 11/28/2023 20:02:44 > *To:* "Kai GAO" > *Cc:* "The IESG" , 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) > > Hello, > > Thanks for addressing the comments. The -19 version looks improved. > > Some more reflections below. > > //Zahed > > On Tue, Nov 21, 2023 at 4:09=E2=80=AFPM Kai GAO wrot= e: > >> Hi Zaheduzzaman, >> >> We are sorry for the late reply -- the mail was blocked by the spam >> detector. Please see our responses inline. >> >> Best, >> Kai >> >> On Thu, Oct 26, 2023 at 6:56=E2=80=AFPM Zaheduzzaman Sarker via Datatrac= ker < >> noreply@ietf.org> wrote: >> >>> Zaheduzzaman Sarker has entered the following ballot position for >>> draft-ietf-alto-new-transport-17: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-posit= ions/ >>> for more information about how to handle DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> Thanks for working on this specification. >>> >>> I have following points which I want to discuss further - >>> >>> - I understand this new transport is supposed to take advantages of >>> HTTP/2 and >>> HTTP/3 features and have backward compatibility with HTTP/1.x (x=3D1, >>> likely). My >>> take is, if I want to server ALTO server over HTTP2/ or HTTP/3 I would >>> use this >>> new transport. Now if I also want to also support HTTP1.x for whatever >>> reasons >>> then I have issue, should this new transport is sufficient to support >>> all the >>> HTTP versions up to HTTP/3? if yes, then why this does specification no= t >>> update >>> or even obsolete rfc8895? if the answer is NO, does that mean I need to >>> implement both this specification and rfc8895 for HTTP1.1? This relatio= n >>> is not >>> explicitly defined in this current draft, which it should. >>> >>> [KAI] Thanks for the comment. Yes, the new transport is sufficient to >> support all HTTP >> versions up to HTTP/3. The relationship between new transport and RFC889= 5 >> is also >> raised by the IoT telechat review by Wesley Eddy. Our understanding is >> that new >> transport is not a replacement of ALTO/SSE, and these two extensions can >> be combined >> (see the introduction of -18 for more complete discussions). >> > > This looks better in -19 version. Thanks > >> >> - I am not convinced that incremental update actually reduces storage at >>> ALTO >>> server, how is that so? I don't think there is an strict requirement >>> that all >>> the ALTO clients need to be updated to the recent version to be >>> functional (as >>> described in this specification), that means unless the serve is sure >>> that all >>> the clients are updated to certain version it has to keep the update >>> versions. >>> As storage reduction is a motivation for the transport requirement this >>> motivation need to be well described to derive the requirement. >>> >> >> [KAI] The "reduced storage" is compared to the case where the server >> stores the contents >> of each version. It is a motivation to use incremental updates (which >> applies to RFC 8895 >> as well) and we consider incremental updates as one motivation for the >> new transport. >> Does this make sense? >> > > The draft still just mentions this as a statement. I think it would be > better if it is clear that the comparison is done with the case where the > server stores the contents of the each version. > > > [KAI] Got it. The proposed text is: > > NEW: > Incremental updates only maintain and transfer > the "diff" upon changes. Thus, it is more efficient than storing > and transferring the full updates, especially when the change of > an ALTO resource is minor. > LGTM. > > > >> >> >>> - 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 wha= t >>> actually "Concurrent, non-blocking update transmission" means in this >>> context >>> of fetching updates. >>> >>> >> [KAI] The requirement basically requires that incremental updates can be >> transmitted >> at the same time (concurrent) and the transmission of one update will no= t >> 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. >> >> >>> - The encoding or data type of "updates graph (ug)" and "version" is no= t >>> defined. The example uses numeric numbers which is easy to understand >>> with >>> incremental values. However, unless and otherwise this data type is >>> defined >>> then it is up to the implementers to select that and which will lead to >>> interoperability issues. or may be I am missing something here, that is >>> why I >>> need to discuss the intention here. >>> >>> >> [KAI] The data type of the version tag (the one held by the client) is a >> string (JSONString) >> but the "version" used to compute the URLs is a sequence number >> (JSONNumber), both >> specified in Sec 6.2. >> > > do you mean "UpdatesGraphSummary" ? can we put the inline ref to the > section where version datatype is defined to avoid confusion? > > > [KAI] The proposed texts are added to the "Updates graph" and "Version" > entries in Sec 2.2. > > NEW: ... Encoding of a updates graph is specified in Section 6.1. > > NEW: ... Version is encoded as a JSONNumber, as specified in Section 6.1. > Better now. > >> >>> - Here we are composing URIs from the ug , that tells me without prope= r >>> encoding on ug defined there might be some internationalization issues >>> (see >>> rfc6365). Has there been any thoughts or discussions on this encoding a= nd >>> potential issues? >>> >>> >> [KAI] Good point. According to RFC 7285 (the base ALTO protocol), the >> contents >> of the ALTO maps only allow ASCII characters. I think this document >> should have >> the same restrictions. >> > > have you mentioned this in -19 version? if not then please write the > restriction. > > [KAI] I checked the charset for JSON (e.g. RFC 4627). Seems that the > encoding is unicode (and UTF-8 by default). In that case, there is only o= ne > potential risk that a tips-view-uri may contain international characters, > as other parts of the constructed URLs are all ASCII. In Sec 6.2, we > require tips-view-uri to follow RFC 3986 which only uses ASCII characters > for the URL. Our proposal is to add a text in Sec 6.2: > > NEW: > > The field [tips-view-uri] MUST contain only ASCII characters. If the > original URL contains international characters (e.g., in the domain name)= , > they MUST be properly encoded into the ASCII format (e.g., using the > "urlencode" function). > I think we need to hint on "who" is going to convert them using that function. //Zahed > > > //Zahed > > > > >> >> >>> and I am also supporting Roman's discuss. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I think my other AD colleagues have already identified nits and typos. >>> >>> >>> >>> _______________________________________________ >>> alto mailing list >>> alto@ietf.org >>> https://www.ietf.org/mailman/listinfo/alto >>> >> --0000000000001d3d23060b494bba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 29, 2023 at 12:41=E2=80= =AFPM <kaigao@scu.edu.cn> wr= ote:

Hi Zahed,

Thanks for the comments! Please see the responses inline. I already have t= he updates in place but would like to submit a new revision after you revie= w the proposed texts.

Best,

Kai



-----Original Messages-----
From: "Zaheduzzaman = Sarker" <zahed.sarker.ietf@gmail.com>
Send time: Tuesday, 1= 1/28/2023 20:02:44
To: "Kai GAO" <godrickk@gmail.com>
Cc: "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)

Hello,

Thanks for addressing the comments. The -19 version looks improved.

Some more reflections below.

//Zahed

On Tue, Nov 21, 2023 at 4:09=E2=80=AFPM Kai GAO <godrickk@gmail.com> wrote:
Hi Zaheduzzaman,

We are sorry for the late reply -- the mail was blocked by the spam d= etector. Please see our responses inline.

Best,
Kai

On Thu, Oct 26, 2023 at 6:56=E2=80=AFPM Zaheduzzaman Sarker via Data= tracker <noreply@i= etf.org> wrote:
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-alto-new-transport-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://= www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-alto-new-transport/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for working on this specification.

I have following points which I want to discuss further -

- I understand this new transport is supposed to take advantages of HTTP/2 = and
HTTP/3 features and have backward compatibility with HTTP/1.x (x=3D1, likel= y). My
take is, if I want to server ALTO server over HTTP2/ or HTTP/3 I would use = this
new transport. Now if I also want to also support HTTP1.x for whatever reas= ons
then I have issue, should this new transport is sufficient to support all t= he
HTTP versions up to HTTP/3? if yes, then why this does specification not up= date
or even obsolete rfc8895? if the answer is NO, does that mean I need to
implement both this specification and rfc8895 for HTTP1.1? This relation is= not
explicitly defined in this current draft, which it should.

[KAI] Thanks for the comment. Yes, the new transport is sufficient t= o support all HTTP
versions up to HTTP/3. The relationship between new transport and RF= C8895 is also
raised by the IoT telechat review by Wesley Eddy. Our understanding = is that new
transport is not a replacement of ALTO/SSE, and these two extensions= can be combined
(see the introduction of -18 for more complete discussions).

This looks better in -19 version. Thanks=C2=A0=C2=A0

- I am not convinced that incremental update actually reduces storag= e at ALTO
server, how is that so? I don't think there is an strict requirement th= at all
the ALTO clients need to be updated to the recent version to be functional = (as
described in this specification), that means unless the serve is sure that = all
the clients are updated to certain version it has to keep the update versio= ns.
As storage reduction is a motivation for the transport requirement this
motivation need to be well described to derive the requirement.

[KAI] The "reduced storage" is compared to the case where = the server stores the contents
of each version. It is a motivation to use incremental updates (whic= h applies to RFC 8895
as well) and we consider incremental updates as one motivation for t= he new transport.
Does this make sense?

The draft still just mentions this as a statement. I think it would be = better if it is clear that the comparison is done with the case where the s= erver stores the contents of the each version.
=C2=A0
[KAI] Got it. The proposed text is:

NEW:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Incremental updates only maintain and trans= fer
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the "diff" upon changes.=C2=A0 Thu= s, it is more efficient than storing
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and transferring the full updates, especiall= y when the change of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an ALTO resource is minor.=C2=A0
=

LGTM.=C2=A0





- I didn't find any explanation of how the "Concurrent, non-blocki= ng 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.

=C2=A0
[KAI] The requirement basically requires that incremental updates ca= n be transmitted
at the same time (concurrent) and the transmission of one update wil= l not be blocked
by the transmission of another update. This can be realized by 1) mu= ltiple HTTP
connections, or 2) HTTP/3 using multiple streams. This is compared w= ith RFC 8895
where SSE multiplexes the updates in a single sequence. You make a g= ood point that
we should clarify how this can be done with new transport. We will a= dd a paragraph to
Sec 2.1 and upload a revision soon.
=C2=A0
- The encoding or data type of "updates graph (ug)" and &q= uot;version" is not
defined. The example uses numeric numbers which is easy to understand with<= br> incremental values. However, unless and otherwise this data type is defined=
then it is up to the implementers to select that and which will lead to
interoperability issues. or may be I am missing something here, that is why= I
need to discuss the intention here.


[KAI] The data type of the version tag (the one held by the client) = is a string (JSONString)
but the "version" used to compute the URLs is a sequence n= umber (JSONNumber), both
specified in Sec 6.2.

do you mean "UpdatesGraphSummary" ? can we put the inline ref to the = section where version datatype is defined to avoid confusion?=20
=C2=A0
[KAI] The proposed texts are added to the "Updates graph" and &q= uot;Version" entries in Sec 2.2.

NEW: ... Encoding of a updates graph is specified in Section 6.1.

NEW: ... Version is encoded as a JSONNumber, as specified in Section 6.1.<= br>

Better now.=C2=A0
=C2=A0
-=C2=A0 Here we are composing URIs from the ug , that tells me witho= ut proper
encoding on ug defined there might be some internationalization issues (see=
rfc6365). Has there been any thoughts or discussions on this encoding and potential issues?

=C2=A0
[KAI] Good point. According to RFC 7285 (the base ALTO protocol), th= e contents
of the ALTO maps only allow ASCII characters. I think this document = should have
the same restrictions.

have you mentioned this in -19 version? if not then please write the re= striction.

[KAI] I checked the charset for JSON (e.g. RFC 4627). Seems that the encod= ing is unicode (and UTF-8 by default). In that case, there is only one pote= ntial risk that a tips-view-uri may contain international characters, as ot= her parts of the constructed URLs are all ASCII. In Sec 6.2, we require tip= s-view-uri to follow RFC 3986 which only uses ASCII characters for the URL.= Our proposal is to add a text in Sec 6.2:

NEW:

The field [tips-view-uri] MUST contain only ASCII characters. If the origi= nal URL contains international characters (e.g., in the domain name), they = MUST be properly encoded into the ASCII format (e.g., using the "urlen= code" function).

I think w= e need to hint on "who" is going to convert them using that funct= ion.

//Zahed=C2=A0=C2=A0
=C2=A0


//Zahed


=C2=A0
=C2=A0
and I am also supporting Roman's discuss.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think my other AD colleagues have already identified nits and typos.



_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
--0000000000001d3d23060b494bba--