Re: [alto] WG adoption call for draft-schott-alto-new-transport-01

[Jordi Ros Giralt <[e-mail]>]

Hi Authors,

In addition to Qin's questions/comments below, here are some additional notes from my reading of the draft. Thank you.

  *   Instead of "work flow", kindly suggest using "workflow" (there are a few instances in the draft)
  *   "Section 4.1 Transport Queue Operations: An ALTO client creates a transport queue using the HTTP POST method". Could this increase the exposure of ALTO service to a potential DoS attack? E.g., in the case that multiple non-legit clients allocate queues for the purpose of consuming additional memory/compute resources from the system. Is there a need to mention it in Section 10 to ensure implementations provide safety measures against this potential threat?
  *   Section 4.2: instead of "structure of incremental updates queue will be specified", suggest "the structure of the incremental updates queue will be specified"
  *   Section 5.1:
     *   While the acronym CRUD might be known in the community, suggest defining it the first time it is used:
        *   Instead of "Among the CRUD operations", suggest "Among the create, read, update, and delete (CRUD) operations"
     *   Instead of "an incremental updates queue supports only", suggest "an incremental updates queue only supports"
  *   In Section 6.1:
     *   Suggest adding RFC reference next to SETTINGS_ENABLE_PUSH so reader can look up the definition. So intead of "SETTINGS_ENABLE_PUSH", suggest "SETTINGS_ENABLE_PUSH [RFC7540]"
     *   Instead of "PUSH_PROMISE", suggest "PUSH_PROMISE [RFC7540]"
     *   Regarding this requirement "The server MUST maintain the last entry pushed to the client (and hence per client, per connection state)"
        *   Will it scale?
        *   Can we add a note on scalability (e.g., scalability can be addressed by adding multiple ALTO servers)?

As with Peng, I also think this version is maturing so I would support the adoption as we continue to provide and address all the feedback.

Jordi
________________________________
From: alto <[e-mail]> on behalf of Qin Wu <bill.wu=[e-mail]>
Sent: Wednesday, June 8, 2022 11:36
To: [e-mail] <[e-mail]>
Subject: Re: [alto] WG adoption call for draft-schott-alto-new-transport-01


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi, authors:

I have read the latest version of ALTO transport, here is a few clarification questions and comments:

1. What is the relationship between HTTP/2 connection and Transport queue? one to one?

Will information resources share the same transport queue?

2. What is the relationship between transport queue and incremental update queue? one to one mapping?

3. Will receivers share the same incremental update queue? or each receiver can join different incremental update queue? For the former case, how does new receiver know

or discover the existing incremental update queue? Information resource will provide hints for the receiver or the client?



4. How incremental push update is different from incremental update?



5. In Figure 2  should 'sq/rs' be 'tq/rs'?



6. Individual update is not present in the figure 2? would it be nice to clarify the

relation between incremental update and individual update? Is incremental udpate shared by multiple receivers?



7. Should this draft need to update RFC7285 since it introduce new functionalities such as transport queue, incremental update queue, receiver set?

8. Is there any open issues section to track issue tickets?



-Qin (without chair hat)

发件人: alto [mailto:[e-mail]] 代表 Qin Wu
发送时间: 2022年5月31日 19:11
收件人: [e-mail]
主题: [alto] WG adoption call for draft-schott-alto-new-transport-01



Hi folks,



This begins a 2 week WG Adoption Call for the following draft:



https://datatracker.ietf.org/doc/draft-schott-alto-new-transport/



Please indicate your support or objections by June 15th, 2022.



Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.



Thanks,



-Qin/Med