Hi, Qin:
Thank you so much for taking the time to review this. In response to your
comments, as I understand it -
1. You are right that we didn't commit either way. After discussion,
our goal is both to provide a version independent mechanism, but also
provide server push protocol. In the revision, we plan to merge push
promise as defined in [draft-schott-alto-new-transport-push] into this
document, as they share many overlapping sections. There will be a section
to explain the HTTP/1.1 caveats.
2. We will focus on PUT in the next iteration because we want to focus
on first getting correct pull and push.
3. #2 and #4 follow the same patterns as #1 and #3 so examples are not
provided.
4. The answer to this will likely change based on updates we are
currently making to the design but in this draft the idea was that: We use
absolute URI for the location of the transport state because it may be
located at the same host as the invoking TIPS or on a different
host. Relative URI is used for URI's within the transport state object
(specifically for the updates queue details), because transport state and
the updates queue must be located on the same host (to simplify client
construction of URI's for future updates that clients will long pull).
5. How the server handles transport states (shared or not) is up to the
implementer, which will be clear in revision. Example of transport state
shared by client A and client B: the server keeps a single queue for an
incremental network resource which is occasionally compacted. Client A and
client B can both request to receive incremental updates, which will be
pulled from that queue. The queue is not consumed by being read. Client A
and client B keep track of where they are reading from with the sequence
number, following an n+1 pattern.
6. If multiple clients are subscribed to a single transport state, the
server must keep track of who is still subscribed, so as not to delete the
transport state if it is still in use, but this is up to the implementor.
Will clarify that a client sending DELETE only deletes it from the view of
the client, not necessarily on the server itself.
7. SSE is a push-only protocol but in a lot of cases we can benefit
from client long pull because it gives the client flexibility about how and
when to receive updates. Will add this idea to the introduction of the
document.
Hopefully this provides clarity, and please let me know if something is
still not clear.
Best,
Lachlan
On Thu, Feb 9, 2023 at 9:46 AM Qin Wu <[email protected]> wrote:
> Hi, Authors:
> I have a few high level comments on ALTO new transport:
> 1. I believe the main goal of this work is to provide modernized
> transport for ALTO protocol,
> define HTTP version independent mechanism, therefore protocol
> version dependent mechanism
> is not in the scope of this document, if this is true, I believe
> should make it clear whether
> push promise defined in [draft-schott-alto-new-transport-push]
> is in the scope.
> 2. See our earlier discussion on protocol design choices:
> https://mailarchive.ietf.org/arch/browse/alto/?q=server%20put
> server put is also one of choices for protocol version independent
> mechanism. I am wondering whether
> you need to touch it and clarify the relationship with long pull
> design.
> 3. for network information resource in figure 1, we only provide
> example for #1 and #3, what about #2,#4?
> 4. This draft support both absolute URL and relative URL, i am
> wondering when we use absolute URL , when we use relative URL?
> 5. How transport states are shared by multiple client, can you provide
> an example?
> 6. Suppose transport states are shared by client A and Client B, Client
> A delete transport state, what impact on Client B?
> 7. I am wondering whether we should provide comparison analysis between
> SSE and long pull? e.g., SSE needs to provide control channel and data
> channel while long pull not.
>
> -Qin (Speak as Individual)
> > -----Message d'origine-----
> > De : I-D-Announce <[email protected]> De la part de
> > [email protected] Envoyé : mardi 7 février 2023 00:29 À :
> > [email protected] Cc : [email protected] Objet : I-D Action:
> > draft-ietf-alto-new-transport-05.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Application-Layer Traffic
> > Optimization WG of the IETF.
> >
> > Title : ALTO Transport Information Publication
> > Service
> > Authors : Roland Schott
> > Y. Richard Yang
> > Kai Gao
> > Lachlan Keller
> > Filename : draft-ietf-alto-new-transport-05.txt
> > Pages : 32
> > Date : 2023-02-06
> >
> > Abstract:
> > The ALTO base protocol [RFC7285] is based on HTTP/1.x, designed for
> > the simple, sequential request-reply use case, in which an ALTO
> > client requests a sequence of information resources, and the server
> > sends the complete content of each information resource to the
> > client
> > one by one. To support the use case that an ALTO client can
> > monitor
> > multiple resources at the same time and the ALTO server sends only
> > their updates, the ALTO Working Group introduced ALTO/SSE
> > [RFC8895],
> > which defines a new, SSE-based multiplexing protocol on top of
> > HTTP/1.x, to allow the server to concurrently, and incrementally
> > push
> > updates to the client whenever monitored network information
> > resources change. However, newer versions of HTTP (e.g.,
> > HTTP/2
> > [RFC7540]) already support concurrent, non-blocking transport of
> > multiple streams in the same HTTP connection. This document
> > introduces the ALTO transport information publication service
> > (TIPS),
> > which allows the naming of (i.e., assigning resource identifiers
> > to)
> > individual incremental updates to multiple ALTO information
> > resources
> > and the distribution of the naming, enabling ALTO to take advantage
> > of newer HTTP versions. In particular, it gives an ALTO client the
> > new capability to explicitly request (pull) a specific incremental
> > update. It also provides an ALTO server the new capability to push
> > a
> > specific incremental update using native HTTP/2 or HTTP/3 server
> > push. This document defines TIPS as a service, independent of
> > client
> > pull or server push. A companion document
> > [draft-schott-alto-new-transport-push] defines the complete
> > server-
> > push ALTO transport based on ALTO TIPS.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-alto-new-transport-
> > 05.html
> >
> > A diff from the previous version is available at:
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-alto-new-
> > transport-05
> >
> >
> > Internet-Drafts are also available by rsync at
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
