General summary =============== My impression of this protocol is that while it has several aspects that need work, it's on a good track towards a solution to the media multicast problems it addresses. However, this also (possibly inadvertently) describes a useful contribution to the HTTP ecosystem, as the protocol seems to be suitable for distribution of other data already. (For example, it could be used to distribute software updates). I think that splitting the document conceptually into how to stream (in the first place, arbitrary) sets or ranges of resources through multicast, and a second part that deals with peculiarities of media streams (such as 3.8.2 that the manifest should be sent wherever the data is sent). Mechanisms like this have been discussed around draft-ietf-core-observe-multicast-notifications in the context of constrained devices, which has informally been applied also for firmware updates. Questions and comments ====================== * Given this is built on HTTP's architecture, there may be some benefits to reap in terms of simplification by building on it: * In section 2 there is a lot of description on how the multicast server obtains the data through the HAS from the origin server, and how the multicast receiver is a gateway that relays the received data through the HAS again. This makes sense to set the stage and paint the expected usage scenario, but for normative text (and even later parts of section 2) the protocol is essentially between a server and a client, no matter whether either of them serves as a proxy. * As noted in the general summary, most of this is independent of whether media or other resources are transported. This should also be reflected in the structure. For example, the semantics of the Object URI field need not be part of the HAS protocol dependent section. For other components it's less clear how they are used, but chances are there are corresponding concepts in HTTP already. * 3.1 "MSYNC Packet Format", "Whenever this object ID change that means the transfer of the previous object is finished". Packets can be reordered in transit. Will this make later packets unusable to the receiver? Also later in 3.7 "the MSYNC sender MUST send the following MSYNC packets in the specified order": Reception in that order is generally not guaranteed, so why make this a requirement? If recipients need to reorder packets, it may make sense to prescribe some form of object identifier incrementing (eg. that they always increase by 1). This would make it easier for the recipient to distinguish stray packets received from previously processed objects (which could be discarded) from the first data packet that was received ahead of the corresponding info packets (which better be stored). * 3.2 "object URI size" / "object URI": This appears to be redundant and needlessly complex, given that UDP already gives the packet length. If for alignment reasons the size needs to be a multiple of 4, that property could also be obtained by nul-padding (without indicating the padding length) because 0x00 is not a legal character in a URI -- but I think that'd need good justification. * 3.4 "Object HTTP Header Packet": After reading the whole document I found myself wondering which kind of headers would be transported here. * 3.5 "super object offset": I'd like to see alternatives to the object / super-object split explored -- if it's just about length not being known in advance, the separation might be overkill. Comparing to Content-Range might help here. * 3.7 "then only one object info packet MUST be sent.": Is not doing this an interoperability hazard? If not, why the MUST? (And on the "curious questions" level, why is it forbidden?) * 3.8.1.1 I'm not familiar with the precise HLS and DASH concepts used, but if this is all only about resources whose content changes over time, it may make sense to utilize ETag instead of a media-specific concept. This could replace the media sequence item in the object info packet. (If not, some more detail could help generalize this). * 3.8.1.2 "Object URI": Comparing URIs as substrings is a highly irregular operation. Appeding a hash characterh ("#") already has a defined meaning in URI references (setting the fragment identifier, or extending it if one was present before), which is not aligned with how numbers are appended here. I'd make a more concrete suggestion on how to improve this, but that'd require full understanding of how it is supposed to work, and given that CTE is not expanded (and HTTP does not use Content-Transfer-Encoding as which I'd read it), the intended operation is unclear. Specification clarity ===================== * 3.1 "sub-header" (and other >8-bit numbers): While frequent readers of IETF documents will be aware that this is intended to be encoded in Network Byte Order (also called big-endian), some readers might appreciate this being explicit. * 3.2 "object CRC": Which polynomial? * 3.2 "object type", "mtype": It is unclear to me why these need to be indicated, given that their URIs are known for entry points. Both appear to be overlapping with media types, which could replace both fields. * 3.2 "media sequence": "The default value is 0x00". Given the field is not optional, I think this would better be phrased along the lines of "If this field is unused, it MUST be set to 0x00, and receivers MUST ignore it." * 3.4 "Object HTTP Header Packet" serializes HTTP headers. Given there are now multiple versions of the HTTP protocol with different expressions for how headers are encoded, please consider referencing into a concrete document for the format. * 3.4 "Object HTTP Header Packet" vs. 3.5 "super object offset": Does the use of super objects imply that the Content-Range header will not be used? Otherwise, how do they interact? Depending on earlier items, the Content-Format header may have some overlap with the mtype. It may be prudent to define which takes precedence, or (as I'd prefer) that the headers that are redundant with info packet fields are forbidden in header packets. * 3.4 "Object HTTP Header Packet": It pains me to say it, but it may make sense to check with HTTP experts on whether 64KiB is a reasonable limit for HTTP headers. Versioning ========== * 3.1 "version": What's the evolution plan for this protocol? How are recipients supposed to react to packets with a different protocol version? * 3.1 "packet type": This appers to be the main extension point for the protocol. How are recipients supposed to react to packets with unknown packet types? What is the procedure for adding packet types? If it's not "publish an RFC that updates this document", this would need a registry. Same goes for mtype (but see also main comment on mtype). Curious questions ================= * Why is the Object Info Packet sent with distinct packet types, instead of just being transmitted twice? * 3.7: "source IP address, destination multicast IP address and destination transport port number is the discriminator". Why was the source IP included but the source port not? If fail-over was considered, allowing variation in the source IP would appear to be a good choice, whereas allowing variation in the source port contributes only marginally there (and off my head I would see no other reason). Editorial notes =============== * 1. Introduction: Please expand ABR * 1.2 Terminology: Please expand CTE (presumably to Content-Transfer-Encoding?) * 1.2 Definitions: I think this would be better readable if it were in a bottom-up sequence. Someone new to the topic (like me) needs to jump forward a lot, and the current alphabetical sorting is not that relevant any more when there is full-text search in all relevant media. * 1.2 "HTTP Adaptive Streaming (HAS) session": Maybe substitute "init" with "init segments" for better flow. (Although flow would also be helped by having read "init segment" earlier). * 1.2 "media": How the term is used in "media chunk", "media segment" etc seems to imply that as used here there is always a temporal component to it. * 3.4 "Object HTTP Header Packet" talks of "one HTTP header". In RFC7230 there are many "header fiels" joint in a "header section" (also called "the headers"), but never "a header". * various typo: "mechanism.; this"; "teh" * capitalization: "streaming, The"; "if the object" Scope notes =========== * I am only very vaguely familiar with RTP, thus my reading of section 3.9 was very superficial.