Reviewer: Magnus Westerlund Review result: Not Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. So I am glad the draft at least scratches a little on the surface when it comes to the transport challenges of multicast transport deployment. However, I think this architecture needs to actually discuss how it is going to handle some of these issues in more detail. This as they are both challenging and also can have significant impact on the underlying unicast network. To the level where they actually likely need to be part of the real architecture that enables multicast delivery. Congestion Control and bit-rate adaptation The AMT RFC 7450 contains section 4.1.4.2: "AMT relies on UDP to provide best-effort delivery of multicast data to gateways. Neither AMT nor UDP provides the congestion control mechanisms required to regulate the flow of data messages passing through a network. While congestion remediation might be provided by multicast receiver applications via multicast group selection or upstream reporting mechanisms, there are no means by which to ensure that such mechanisms are employed. To limit the possible congestion across a network or wider Internet, AMT service providers are expected to deploy AMT relays near the provider's network border and its interface with edge routers. The provider must limit relay address advertisements to those edges to prevent distant gateways from being able to access a relay and potentially generate flows that consume or exceed the capacity of intervening links." Which means that this requirement to have congestion control do apply on the one running the end-to-end service over the TreeDN RaaS. The draft is not particular clear on that it will fall on these deploying a multicast based service to have a solution for rate adapation in place. I rather think the text tries to gloss this over. For example noting that reliability can be addressed by FEC, which clearly is one of the tools in the tool box, hinting that packet loss rates up to 5% can be hidden. The other side of this is that if the multicast application running over AMT these flow will push basically all other congestion controlled traffic out of the way. Anyone deploying an application using multicast over this architecture will only be bitten themself when enough users actually receive multicast flows that are at higher bandwidth than the link capacity, or possibly when N users of poorly adopting services share the bottleneck and those N flows can fit. With SSM the congestion control and real-time media services, rather than file distribution broad cast discs one likely have to select the most approriate quality level and subscribe to that. Which means that the replication do gets fragmented. For large file deliverly and usage of broad cast discs congestion control could be more fine grained and use like WEBRC (RFC 3738). Using NORM have interesting implications as that will result in selecting a rate adapted to the lowest capable receivers within a multicast group. Also I want to come back to NORM when it comes to feedback implosion problems. But, I get the impression that this really is targeting large scale deployments, where some these problems will be elevated significantly. I think this document needs should be clearer about the non-negotiable requirement to have bit-rate adaptation. Feedback implosion The usage of SSM like structure also means that the service on top of this RaaS will have to think hard about Feedback implosion. And this goes further than many other multicast deployments as if this one is successful one have near global reach. So the number of participant a popular service needs to handle are clearly in the many millions, without a natural upper limit. So the application deployer need to deploy a structure for any gathered feedback that scale and have the tools to inform the receivers about where to send the traffic. This issue of feedback also come into the usage of AMT and its managability. Where there will be many users and thus receivers are not governed by the multicast topology, instead of where the users are. Thus, deploying feedback servers in the right topology places will be part of a managability challenge. I do want to note that how an application receiver directed to send some feedback depending on protocol actually need mechanism to prevent it from being an unwanted participant in a DDoS attack. Managability of the AMT tunneling What is not discussed is what set of tools are needed to manage this RaaS. I see many challenges. First one needs to find the most appropriate AMT relay to ensure that the AMT traffic takes a way through the network that has appropriate resources. Another challenge is how to actually attempt to reach the desired goal that the users local access network actually support multicast. Here several challenges appear to exist. First determining that support and getting access to it from an endpoint within the local network. There also appear to exist a need for an happy eyeball handling of attempting to use local network to determine if it actually can reach the desired multicast group. Will TreeDN move back multicast address to have global uniquness to ensure that one can ask for just the address and get the right service from a network potentially using AMT it self? There are requirement in the architecture on being able to find AMT relay's delivering the right group. Otherwise the complexitiy will not ensure the desired incentaive of deploying local multicast in an attempt to reduce the unnecessary duplication. The main point is that for TreeDN architecture to be successful it actually needs to include much more components and addressing a number of additional questions that actually makes it useful. Not simply provide replication of packets. How to actually manage the AMT tunnels, as well as ensure safe deployment over Internet also needs to be considred. Then there are some options for the transport protocol level depending on the actual application. That is clearly a seperate layer, but there are some requirements on this level that it would be good to make clear to avoid congesting some access networks or directing a feedback implosion onto some node. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
