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

[Kai GAO <[e-mail]>]

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 PM Zaheduzzaman Sarker via Datatracker <
[e-mail]> 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/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=1,
> 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 not
> 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 relation
> 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 RFC8895
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).

- 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?


> - 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.
>
>
[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.


> - The encoding or data type of "updates graph (ug)" and "version" is not
> 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.


> -  Here we are composing URIs from the ug , that tells me without 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?
>
>
[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.


> and I am also supporting Roman's discuss.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I think my other AD colleagues have already identified nits and typos.
>
>
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>