Re: [Tsv-art] Tsvart early review of draft-bichot-msync-08

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Hi Magnus and others,

At long last we are returning to this draft, as IPR issues have been 
worked out.  I would also note the inclusion of text relating to RFCs 
8084 and 8085.  Would the transport area like another shot at reviewing 
this work?

Eliot

On 13.03.23 10:15, Magnus Westerlund wrote:
>
> Hi,
>
> To me it sounds like this document likely need some solutions to 
> handle scenarios when the network is not providing what was expected, 
> i.e. at least some type of circuit breaker 
> https://datatracker.ietf.org/doc/rfc8084/. Secondly, if it really is 
> intended for limited deployments that should be made very clear.
>
> I would note that there are mechanism that could easily break that 
> assumption that interdomain multicast doesn’t work. For example if one 
> deploy Automatic Multicast Tunneling (AMT) 
> https://datatracker.ietf.org/doc/rfc7450/ then one might get Multicast 
> over the Internet. And AMT provides no congestion control either. Only 
> deployment recommendations to ensure that one limit the traffic to 
> what are existing. So there are a lot of fragility in the combination 
> of these systems.
>
> So I think a lot of care needs to be taken here.
>
> Cheers
>
> Magnus Westerlund
>
> *From: *Tsv-art <[e-mail]> on behalf of Independent 
> Submissions Editor (Eliot Lear) <[e-mail]>
> *Date: *Friday, 10 March 2023 at 16:40
> *To: *Guillaume Bichot <[e-mail]>, Joerg Ott 
> <[e-mail]>
> *Cc: *[e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [Tsv-art] Tsvart early review of draft-bichot-msync-08
>
> Hi Guillaume,
>
> Thanks for this update.  I would like to see some further work done in 
> three areas, in response to Joerg's comments:
>
> 1.  Congestion control is important.  It should be called out in its 
> own section, and it must be clear as to what MUST be done when using 
> this protocol so that it behaves well with others.  For instance, 
> should there be rate limiting, and if so, how?
>
> 2. Figure 1 should have a little more detail, and there may yet be 
> another figure hiding beneath.  Specifically, on what networks do you 
> expect this to run?  If the Internet is sitting there in the middle, 
> show it.  If it is a service provider network in which all of this 
> operates, show that.
>
> Note that these two points are related.  In particular, if the 
> Internet is sitting there in the middle, (a) Good Luck with 
> inter-domain multicast in the first place, and (b) you'll have to add 
> a lot more detail about what it means to carry msync through the 
> Internet, and in particular what the QoS requirements are for transit 
> networks.  Let's hope there are none.
>
> All of this leads up to a third area:
>
> The applicability of the work needs to be more clearly stated.  Its 
> *safe* use must be *pre*scribed, so that networks do not congest.
>
> Thanks,
>
> Eliot(ISE)
>
> On 10.03.23 15:17, Guillaume Bichot wrote:
>
>     Hi Joerg, thank you again for your review
>
>     See my responses inline.
>
>     I also generated version 9.
>
>     Guillaume
>
>     -----Original Message-----
>
>     From: Joerg Ott via Datatracker<[e-mail]>  <mailto:[e-mail]>
>
>     Sent: Tuesday, February 28, 2023 8:35 PM
>
>     To:[e-mail]
>
>     Cc:[e-mail]
>
>     Subject: Tsvart early review of draft-bichot-msync-08
>
>     Reviewer: Joerg Ott
>
>     Review result: Not Ready
>
>     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.)
>
>     [Guillaume] MSYNC does not congestion control. I will add explicitly the mention of "congestion control". It does not mean that it is assumed that MSYNC operates the full capacity of the network it is deployed over. The bandwidth can be bounded/ controlled through the  configuration of the MSYNC sender as indicated in section 3.7.  We are going to add some explanation about specifically how to deal with bandwidth restriction.
>
>     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.
>
>     [Guillaume] Instead of using the term "open" or "closed", I would talk about "managed" and "un-managed". Most of the MSYNC implementations have been done in a "managed" environment (e.g. broadband IPTV, satellite) as this where the multicast service is guaranteed and controlled.  Note that it does not preclude opening the multicast network to multiple content/service providers having each their MSYNC delivery as long as the  capacity is shared in a controlled manner.  Although "Managed", the broadband ecosystem relies on many standards including those from IETF. This is because the ISPs relies on various infrastructure providers with the possibility of having e.g. the two MSYNC end-endpoints (sender and receiver) being implemented by two different infrastructure providers.
>
>     NORM was/is the transport protocol specified by Cablelabs in their Multicast ABR specification (2015).  MSYNC has a certain number of features that make it unique. First of all, MSYNC allows using RTP for the transport as well as for the packet repair procedure that is a requirement linked with the IPTV ecosystem (many ISPs use RTP based tooling for e.g. monitoring). Next, the overhead introduced by MSYNC has been compared against alternatives including NORM and exhibits the lowest overhead which is key for some deployments. MSYNC allows de-facto carrying HTTP header fields and supports natively the [progressive] transport of MSYNC objects of unknown size. Finally, MSYNC represents a fair share of the market (maybe more than 80%).
>
>     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.
>
>     [Guillaume] We will add a bit of explanation. Basically, this sticks to RFC3550; no specific requirement on the timestamp. It should be the time when the packet is generated; it is mostly used for monitoring/troubleshooting purpose. CC=0 (no CSRC field), SSRC identifies uniquely the source (i.e. the MSYNC sender).
>
>     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.
>
>     [Guillaume] As of today, none of the IPTV deployments we are aware of have secured their multicast service apart from relying on DRM for content protection. As explained above, the MSYNC pipes take place in a "managed" environment where the surface of attacks is reduced. This said, it is changing. In DVB we have specified the usage of HTTP based secure mechanism such as encryption and tampering protection that remain independent but compatible with MSYNC transport.  So we consider having MSYNC not dependent of a particular security solution more as an advantage.
>
>     The spec appears vastly incomplete.  It seems that many details are missing to allow two independent implementations to interoperate.
>
>     [Guillaume] This harsh  statement seems exaggerated.  May be you should be more precise. Very often a spec alone is not sufficient and some open source validator may be required. MSYNC has been implemented by a big European telco on its own following previous version of the MSYNC draft. An infrastructure provider has developed an MSYNC probe again based on one of the earlier  Internet draft version. We have provided as an open source a receiver tool able to receive HAS objects through MSYNC. MSYNC is referenced in a DVB spec.
>
>     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.
>
>     [Guillaume] I/We are not aware on the term "super peers".  Anyway, the object itself terminates at some point in time but its size is unknown. We could imagine another name but you’re the only one (among 5 reviews) having raised that issue and it does not seem crucial at this point.
>
>     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.
>
>     [Guillaume] "Joining" and "Leaving" is part of the IGMP terminology. Although MSYNC receiver implementation might rely on IGMP, this is not mandatory. This is why "attaching" provides a useful abstraction.
>
>     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.
>
>     [Guillaume] The IPR disclosures do not cover the implementation of MSYNC. The statements mean that an application using MSYNC MAY possibly be concerned by the disclosed IPR which anyway is governed by the FRAND principles.  We can respond to most of the technical flaws raised in your email. The decision to have MSYNC as an Internet draft (and possibly and RFC) is driven by the need to ease the protocol implementation by any party wishing to enter into the multicast ABR (aka MABR) ecosystem. The deployments accelerate and opening/sharing MSYNC as an Internet draft (possibly RFC) was perceived useful in the context of HAS delivery over multicast; worth to mention that MSYNC internet draft is referenced in the last DVB-MABR specification soon to be published.
>
>     Broadpeak, S.A. Registered offices at 15 rue Claude Chappe, Zone des Champs Blancs, 35510 Cesson-Sévigné, France | Rennes
>
>     Trade Register: 524 473 063
>
>     This e-mail and its attachments contain confidential information from Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only for the person to whom it is addressed.
>
>     If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy laws, and is committed to the protection of personal data. Emails and/or attachments thereof exchanged between us may include your personal data which may be processed by Broadpeak and/or its affiliates according to applicable privacy laws & regulations.
>
>     In compliance with Regulation (EU) 2016/679 (GDPR) and applicable implementation in local legislations, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing.
>
>     For such purpose, or to know more about how Broadpeak processes your personal data, you may contact Broadpeak by [e-mail].
>
>     Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 orwww.cnil.fr  <http://www.cnil.fr>
>