Hi, Prompted by the new revision and Qin's email, I decided to have a look at this latest version of draft-ietf-alto-new-transport.
Thanks to the authors for all the effort put in to add this important functions to ALTO. I hope these comments help. Best, Adrian === First thing to say is that it is probably time to look at what idnits has to say about the draft, and clean up any warnings. You can see the idnits output at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id /draft-ietf-alto-new-transport-05.txt --- Please be consistent about "http" or "HTTP" throughout. --- I was fortunate to read the Appendix before the rest of the document! There I found... This draft is focusing on HTTP/2 enhancement of the ALTO protocol and the design takes advantage of HTTP/2 design features such as parallel transfer and respects HTTP/2 semantics (e.g., PUSH_PROMISE). Doesn't that mean that the rest of the document should be clearer about that? In particular, the Abstract and Introduction seem to be misleading because they mention "newer versions of HTTP (e.g., HTTP/2" and "such as HTTP/2 [RFC7540]) and HTTP/3 [RFC9114]". Actually, once you get into section 2.2, the document seems to be clear that it *does* apply to HTTP/2 or HTTP/3. So the Appendix might be the bit that is wrong. --- Abstract. This is a big blob of text and fairly hard to parse. You are also close to 25 lines which is the maximum suggested by the Style Guide. So, maybe the following. Still quite long, but easier to read? The ALTO protocol leverages HTTP/1.x and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources, and the server responds for each resource one at a time. ALTO Server-Sent Events (SSE) defines a multiplexing protocol on top of HTTP/1.x, so that the server can push updates to the client whenever monitored network information resources change, allowing the client to monitor multiple resources at the same time. This document introduces the ALTO Transport Information Publication Service (TIPS). This allows the naming of (i.e., assigning resource identifiers to) individual incremental updates to multiple ALTO information resources, and the distribution of those names. TIPS enables ALTO to take advantage of support for concurrent, non- blocking transport of multiple streams in the same HTTP connection made available in HTTP/2 and later versions of HTTP. In particular, it gives an ALTO client the capability to explicitly request (pull) a specific incremental update. It also provides an ALTO server the capability to push a specific incremental update. This document defines TIPS as a service, independent of client pull or server push. A companion document defines the complete server- push ALTO transport based on ALTO TIPS. --- Move the "Requirements Language" from the document header into Section 1.1 (to make the RFC Editor happy). --- Section 1 Per RFC 8895, I believe SSE stands for "Server-Sent Events" s/and ideally,/and, ideally,/ OLD HTTP/2 [RFC7540]) NEW HTTP/2 [RFC7540] END --- 2.1 The start of this section is very confusing with the two concepts being introduced in rather a random way. The use of "resource" and "transport state" seems a bit casual in the rest of the document. I don't know, maybe... OLD A key design of the ALTO TIPS is to distinguish between network information resource and the transport information (referred to as transport state). * A transport state is always created for a network information resource. * The basic component of a transport state is an updates queue, which contains a sequence of incremental updates about the network information resource. Each incremental update is assigned a sequence number, and a URI can be constructed using the sequence number. * A static network information resource (e.g., Cost Map, Network Map) may need only a single updates queue, and a dynamic network information resource (e.g., Filtered Cost Map) may create an updates queue for each unique filter request. * A transport state is a container that may include other transport information beyond the updates queue. This document also defines the push updates state, to support server push updates. NEW ALTO TIPS operates on two key information components. * Per [RFC7285], a network information resource is a piece of retrievable information about network state. * Transport state is defined in this document to be container of transport information that is information about the network information resource. A key design of the ALTO TIPS is to distinguish between network information resource and the transport information. * In TIPS, each network information resource has an associated transport state. * The basic component of a transport state is an updates queue, which contains a sequence of incremental updates about a network information resource. Each incremental update is assigned a sequence number, and a URI can be constructed using the sequence number. * A static network information resource (e.g., Cost Map, Network Map) may need only a single updates queue. A dynamic network information resource (e.g., Filtered Cost Map) may create an updates queue within the transport state for each unique filter request. * A transport state may also include other transport information beyond the updates queue. This document the updates queue as described above, and the push updates state to support server push updates. END --- 2.1 s/Figure 2 shows an example/Figure 1 shows an example/ --- Figure 1 As above, the text talks about the "push updates state", but Figure 1 describes the "server push state". Further, "ts" is marked as "transport information resource" where that term has not been defined, and I think you mean "transport state". Lastly, and this is probably important, information resource #3 seems to have two sets of transport state. There is no explanation of this. Initially, I thought it might be that there is transport state for each client that wants to access the network information resource, but client 1 and client 2 both access ts1. When we get to the text in 2.2 we find that: an ALTO client opens an HTTP connection with an ALTO server, and uses TIPS to create a transport state at the server for each network information resource that the client wants to monitor. ...which implies that each client has its own transport state for each network information resource. I am confused! Additionally, I found the figure hard to read because, I think, the clients should talk to the server not to the state. If I am right, and the server maintains the network information resource and the transport state. The network information resource may be fed by information from other sources. Would the picture look better as follows (borrowing from figure 1 of RFC 7285)... +-------------+ +-----------+ +--------------+ | Dynamic | +-----------+ | Routing | | Provisioning | | Network | | External | | Protocols | | Policy | | Information | | Interface | +-----------+ +--------------+ +-------------+ +-----------+ | | | | | | | | +------------------------------------------------------------------+ | ALTO Server | | | | +--------------------------------------------------------------+ | | | Network Information | | | | | | | | +-------------+ +-------------+ +-------------+ | | | | | Information | | Information | | Information | | | | | | Resource #1 | | Resource #2 | | Resource #3 | | | | | +-------------+ +-------------+ +-------------+ | | | | | / \ | | | +-----|--------------------------------------/-------\---------+ | | | / \ | | +-----|------------------------------------/-----------\-------+ | | | | Transport Information / \ | | | | | / \ | | | | +--------+ +--------+ +--------+ | | | | | ts1 |----+ +-----| ts2 | +---| ts3 | | | | | +--------+ | | +--------+ | +--------+ | | | | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ +-------+ +-------+| | | | | ts1uq | | ts1sp | | ts2uq | | ts2sp | | ts3uq | | ts3sp || | | | +-------+ +-------+ +-------+ +-------+ +-------+ +-------+| | | +----|\---------/\---------|---------/----------|----------|---+ | | | \ / \ | / | | | +------|--\-----/----\-------|-------/------------|----------|-----+ | \ / \ | / | | | +-/-----+ \ | / | | | / \ \ | / A single + + | / ===\==\===|===/=== HTTP \ / | / \ \ | / connection \ / +----------+ +----------+ +----------+ | Client 1 | | Client 2 | | Client 3 | +----------+ +----------+ +----------+ tsi = transport state information i tsiuq = incremental-updates queue associated with tsi tsisp = server push state associated with tsi Figure 1: ALTO Transport Information. --- 2.2 It was a bit of a surprise (to me) to discover in this section that the transport state is created in response to a specific request from a client. Previously I had assumed that the server just created the state for each network resource information that it maintained access to. Probably this fact should find its way into section 2.1. --- 2.2 Do you not think you should include some text describing the URS and UPS (with forward pointers to the relevant sections) before you expose them as major elements in Figures 2 and 3? --- 2.2 Looking at the differences between Figures 2 and 3, I found: Create Transport state for resource 1 | ------------------------------------> | ...and... Create Transport state for resource 1 indicate receiving server push | ------------------------------------> | I presume it is important that in the first case the client does not indicate that it wishes to receive server push. You should show that. --- 3. The complete framework of TIPS defines 3 types of services: Transport Information Publication Service (TIPS), TIPS Queue State Service (QSS), TIPS Update Read Service (URS), and TIPS Update Push Service (UPS). This document defines the first two. I spent way too long working out what was going on here! The TIPS framework defines 3 types of service: the TIPS Queue State Service (QSS), the TIPS Update Read Service (URS), and the TIPS Update Push Service (UPS). This document defines the QSS (Section 5) and the URS (Section 6). The UPS is defined in [draft-schott-alto-new-transport-push]. --- 4. s/An TIPS service allows/TIPS allows/ --- 4.1.2 The capabilities declaration of TIPS is motivated by that defined in Section 6.3 of [RFC8895]. Motivated? Maybe "modelled on"? --- 4.1.2 I think "Normally, this will be" should be "For implementations of this specification, this will be" --- 4.1.2 s/then need to send/then needs to send/ --- 4.1.3 Assuming the "resources" mentioned in this section are "network information resources" then it was not previously clear that multiple network information resources could share transport state. Perhaps, the resource mentioned here is "transport information" in the meaning of 2.1 --- 4.2.1 An ALTO client requests that the server sets up transport state for a given resource by sending an HTTP POST body with the media type "application/alto-tipsparams+json". Do you think that figures 2 and 3 should show "POST"? --- 4.2.1 s/queue.Note/queue. Note/ --- 4.2.1 There are a couple of uses of "MAY" in the text. These are OK, but you need to indicate why an implementation would choose to do that. --- 4.2.2 I could not parse this sentence... Let absolute-transport-state-uri as the absolute URI after resolution. --- 4.2.2 transport-state-uri There is a chunk of text here on security that seems reasonable. It should either be moved to Section 10, or Section 10 should include a back pointer. --- 4.2.2 transport-state/updates-queue-meta/state-summary/start-seq: This MUST be a valid non-negative integer. Define "valid". Actually, define start-seq: sure, it's a number. But what does it mean? --- 4.2.2 Seems to me there are some fields you haven't described. If they are already defined somewhere else, just give pointers. Possibly some of them are defined in draft-schott-alto-new-transport-push, but that makes me worry about that draft needing to be a normative reference. I see: push-updates-meta state push-enabled next-seq --- 4.3 s/(See Section 4.2.2)/(see Section 4.2.2)/ --- 4.5 There are some non-ASCII characters in the example response. --- 5.5 Seq: A required, positive JSON integer indicating the sequence number of the incremental update. As JSON allows a large integer space, when the server reaches the largest integer, the server SHOULD close the incremental update queue. What is the optional alternative to this "SHOULD"? --- 5.5 media-type: A required JSON string giving the type of the incremental update (see ALTO/SSE). Do you mean, "(see [RFC8895])" ? --- 5.6 There are some non-ASCII characters in the example response. --- 5.6 An ALTO client can also read the (meta data) of an individual element in the updates queue. The HTTP method MUST also be GET, and the URI is constructed by appending the seq at the end of the preceding URI. The second sentence is a bit hard to work out. I think: s/The HTTP method MUST also be GET,/The HTTP method is a GET,/ s/at the end/to the/ But: - which seq? - the URI preceding what? --- 6. s/of a an update/of an update/ --- 6. There are some important points missing in this section. When a client reads an entry from the updates queue, is that entry removed from the queue? This is particularly important if two clients have access to the same updates queue. (Of course, see the previous questions about whether there is transport state per network resource information per client.) Can a client have URS and UPS active on the same updates queue? One hopes not. It sort of becomes apparent, but should say clearly that the read from queue process here is not "read top of queue", but "read any item on the queue". --- 6.3 s/must be/is/ --- 7. Include a reference to [draft-schott-alto-new-transport-push]. --- 8. Why "In particular,"? --- 9.1 Isn't there an element of processing here that should allow TIPS to know that an update is still on the updates queue (i.e. has not been read) and so "merge" (batch) a further update into that one rather than fill up the queue with unread updates? To take your example. Suppose a prefix is moved from one PID to another, and an item is placed on the updates queue. Now, suppose the prefix is moved back to the original PID. We might expect a new item to be placed on the updates queue, but suppose the first item has not yet been read? --- 9.2 When implementing server push, the server SHOULD send updates for dependent resource (i.e., the cost maps in the preceding example) in a timely fashion. However, if the ALTO client does not receive the expected updates, a simple recovery method is that the ALTO client uses client pull to request the missing update. The ALTO client MAY retain the version tag of the last version of any tagged resources and search those version tags when identifying the new updates to pull. Although not as efficient as possible, this recovery method is simple and reliable. Does this belong in this document or in the companion document? --- 9.3 If it did not, the updates queue SHOULD NOT have an update. You mean it MAY have an update? Why? How? --- 10.1 predicative fetching Do you mean "predictive" --- 10.2 The availability of continuous updates, when the client indicates receiving server push, can also cause overload for an ALTO client, in particular, an ALTO client with limited processing capabilities. The current design does not include any flow control mechanisms for the client to reduce the update rates from the server. Under overloading, the client MAY choose to remove the information resources with high update rates. It's OK to observe this overloading issue here, but you can't say "the current design" because this document doesn't include any design for push mode. You need to defer the issue to the companion document. --- 10.3 s/a fraudulent "DELETE" requests/fraudulent "DELETE" requests/ --- 11. s/IANA will need to register/IANA is requested to register/ --- 12. The authors of this document would also like to thank many for the reviews and comments. ;-) _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
