Early Review of draft-bichot-msync-08
|Requested revision||02 (document currently at 10)|
|Team||Transport Area Review Team (tsvart)|
|Requested by||Eliot Lear|
|Authors||Sophie Bale , Remy Brebion , Guillaume Bichot|
|I-D last updated||2023-02-28|
Tsvart Early review of -08
by Joerg Ott
Artart Early review of -08 by Christian Amsüss (diff)
Cullen has already reviewed. Looking for one or two more.
|Reviewed revision||08 (document currently at 10)|
I reviewed version -08 of the document. The draft describes a system comprising two gateways and some elements of a protocol between those two gateways. A sender side gateways retrieves HAS streaming content, i.e., media segments, from an HTTPS server, thus acting as a HAS client, and sends these segments along with some metadata via IP multicast to a receiver gateway. The latter receives and stores ("caches") these and serves them to regular HAS clients, thus acting as a HAS server. The protocol between the two gateways is called MSYNC. This draft has substantial issues (not just) from a transport layer perspective and it is actually questionable how those can be addressed within the scope of the document. Given the significance of the fundamental issues, I focus on those and leave details aside. Section 1 states that MSYNC is "simple" and as part of this simplicity does not do "flow control". The authors may mean "no congestion control" but it actually does neither as the rest of the document confirms. Reading further, the authors appear to assume that a single provider is running this protocol within its own network where it has full control of the network capacity and can set aside a capacity share for exclusive use by MSYNC. A number of examples of specific link layers are given, and one may get the impression that the protocol is indeed targeted towards a single link for a single IP hop, rather than a more complex IP network (even though slicing or similar mechanisms could support setting aside dedicated capacity in an IP network as well. This also becomes evident also in section 3.6 in which it is said that packets should not exceed MTU size but no guidance is provided how to obtain it. (I note that the max UDP datagram size has a typo.) As this mix of system/protocol description obviously refers to a closed environment, this begs the question why the IETF should bother dealing with this document in the first place. HAS is not defined in the IETF but the IETF has defined a number of specifications for multicast transport (e.g., RFC 5740, RFC 5401 for NORM), which could probably be used. No discussion of any such existing solutions is given. So, it would seem one could just achieve the intended goals by combining existing technologies. The draft does make reference to RTP (section 3.9) but remains very vague to silent on, e.g., how to use payload types and how to perform encapsulation including timestamps, etc. Just referencing RFC 3551 alone is clearly insufficient. The security considerations effectively state that no security is provided and that this may be risky. While this is not a security review, I consider this problematic, especially since security building would appear to be available. The spec appears vastly incomplete. It seems that many details are missing to allow two independent implementations to interoperate. There are many nits but, focusing on one, I find the term "super object" to refer to an "unterminated" object, i.e., one of unknown side, confusing, given the various uses the term "super" has seen in distributed systems in the past (e.g., super peers). At least the term isn't a good fit for what it refers to. Also concerning terminology, it would be useful to stick to the terms used within the Internet context, e.g., for multicast groups, we talk about joining and leaving, not about attaching to them. I consider the draft to be questionable in terms of scope for the IETF RFC publication process as it is intended for closed networks only and does not consider substantial IETF work. With its technical flaws, its usefulness is questionable. With this and in light of the IPR disclosures related to this draft, I am wondering if the IETF community should spend (more) cycles on it. But I may miss some background or context here.