Skip to main content

Last Call Review of draft-ietf-mops-treedn-04
review-ietf-mops-treedn-04-opsdir-lc-schoenwaelder-2024-05-05-00

Request Review of draft-ietf-mops-treedn
Requested revision No specific revision (document currently at 07)
Type IETF Last Call Review
Team Ops Directorate (opsdir)
Deadline 2024-05-06
Requested 2024-04-22
Authors Lenny Giuliano , Chris Lenart , Rich Adam
I-D last updated 2025-01-17 (Latest revision 2024-08-21)
Completed reviews Tsvart IETF Last Call review of -04 by Magnus Westerlund (diff)
Opsdir IETF Last Call review of -04 by Jürgen Schönwälder (diff)
Secdir IETF Last Call review of -04 by Stephen Farrell (diff)
Genart IETF Last Call review of -04 by Reese Enghardt (diff)
Opsdir Telechat review of -05 by Jürgen Schönwälder (diff)
Intdir Telechat review of -05 by Carlos Pignataro (diff)
Assignment Reviewer Jürgen Schönwälder
State Completed
Request IETF Last Call review on draft-ietf-mops-treedn by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/z03B1CjuBlLOQ7zDjEvNdsr5GNg
Reviewed revision 04 (document currently at 07)
Result Not ready
Completed 2024-05-05
review-ietf-mops-treedn-04-opsdir-lc-schoenwaelder-2024-05-05-00
This informational document describes a tree-based CDN architecture
(called TreeDN) addressing the scaling challenges of live streaming to
mass audiences. The document points out three reasons why traditional
multicast solutions did not receive widespread deployment and use.
Afterwards the document argues that combining Source-Specific
Multicast (SSM) [RFC4607] and Automatic Multicast Tunneling (AMT)
[RFC7450] addresses all these challenges.

Even though the document is fairly short, it occasionally feels a bit
repetitive (e.g., first paragraph in Section 5) and sometimes a bit
too much white paper marketing style. While the authors claim that
TreeDN solves the chicken and egg problem of multicast deployments, it
feels to me that this document was written in order to help solve the
chicken and egg problem of TreeDN deployment. ;-) There is probably
nothing wrong with this kind of informational documents marketing a
certain architectural idea. However, as someone with a background in
research, I would have loved to see some hard (quantitative) facts
demonstrating that TreeDN is indeed a good solution outperforming
others and not suffering from the general multicast challenges.	Some
descriptions of several successful deployments of the TreeDN idea
would make this document stronger.