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

[Zaheduzzaman Sarker <[e-mail]>]

Hello,

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

Some more reflections below.

//Zahed

On Tue, Nov 21, 2023 at 4:09 PM Kai GAO <[e-mail]> wrote:

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

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.


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

do you mean "UpdatesGraphSummary" ? can we put the inline ref to the
section where version datatype is defined to avoid confusion?


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

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

//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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
>