[Gen-art] Re: [Mops] Genart last call review of draft-ietf-mops-treedn-04

[Reese Enghardt <[e-mail]>]

Thank you for the changes, they look good to me!


On 7/11/24 20:02, Leonard Giuliano wrote:
> Reese- thank you for the thoughtful review.  We have updated the draft
> based on your feedback.  Please let us know if the latest revision
> addresses your concerns.  A diff can be found here:
>
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-mops-treedn-04&url2=draft-ietf-mops-treedn-05&difftype=--html
>
> Further comments inline:
>
> On Wed, 1 May 2024, Reese Enghardt via Datatracker wrote:
>
> |
> | Reviewer: Reese Enghardt
> | Review result: Ready with Issues
> |
> | I am the assigned Gen-ART reviewer for this draft. The General Area
> | Review Team (Gen-ART) reviews all IETF documents being processed
> | by the IESG for the IETF Chair.  Please treat these comments just
> | like any other last call comments.
> |
> | For more information, please see the FAQ at
> |
> | <https://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!CNrNEPu4qRUMw3Af6GTBO7VT-huI-R0DP6h608nNh80rCEgCpAXjq7rsbFR-uOudwJJ0bn5t4ZJo5Q$ >.
> |
> | Document: draft-ietf-mops-treedn-04
> | Reviewer: Reese Enghardt
> | Review Date: 2024-05-01
> | IETF LC End Date: 2024-05-06
> | IESG Telechat date: Not scheduled for a telechat
> |
> | Summary: The document presents a fairly clear and concise case study. To make
> | it more readable and useful, I suggest a few clarifications and tweaks in tone,
> | as well as adding a bit more content to the interesting points about the
> | multicast deployment issues.
> |
> | Major issues: None.
> |
> | Minor issues:
> |
> | Section 1:
> | "[…] while more efficiently utilizing network resources, and thus, improving
> | the experience of end users" Why does more efficiently utilizing network
> | resources improve the experience of end users? Please consider explicitly
> | stating any assumptions you are making, e.g., about bottleneck links.
>
> Noted that the assumption is based on the elimination of duplicated
> traffic.
>
> |
> | Section 3:
> | How do these reasons interact with RFC 9049, which lists obstacles to
> | deployment of path-aware networking techniques? Please consider reading Section
> | 4 of RFC 9049 and naming the lessons from RFC 9049 that apply to Multicast.
> | RFC9049 lists multicast as "future work" and I think it would be nice if this
> | draft could be considered the future work item for multicast, as the authors
> | appear to already have done the work of thinking through the deployment
> | obstacles.
>
> Thanks for the pointer to this doc.  Added a ref to RFC9049 in sect 4.1.
> The past challenges noted in sect 3 are there to provide some brief
> background and context about the problems being solved with this
> architecture.  This doc is not intended to be a comprehensive study of
> lessons learned about multicast deployment- and it's probably beyond the
> scope of the MOPS WG.  Such analysis is better covered in
> https://datatracker.ietf.org/doc/draft-ietf-pim-multicast-lessons-learned/
>
>
> | Section 4:
> | Please consider starting by saying that TreeDN can be either an overlay or a
> | "native on-net". Section 8 summarizes it well: "TreeDN is essentially the
> | synthesis of SSM plus overlay networking technologies like AMT." I think
> | stating this basic principle early on will make it much easier for the reader
> | to follow the rest of Section 4.
> |
> | "TreeDN leverages advances in the availability and understanding of overlay and
> | underlay networking." What specific advances does TreeDN leverage? Does it use
> | a new type of overlay different from previous overlays or underlays, or any new
> | techniques that weren't available in previous overlays? If not, please consider
> | rephrasing this text to explain in a more neutral tone that TreeDN leverages
> | overlay networks because they have certain advantages, or similar.
>
> Changed beginning of Sect 4 to:
> "TreeDN leverages a simplified model for multicast deployment combined
> with network overlays to deliver traffic to receiving hosts on
> unicast-only networks."
>
> |
> | Section 5:
> |
> | "[…] specialized CDN devices, which typically are servers that need to be
> | racked, powered and connected to revenue-generating ports on routers" I'm not
> | sure revenue-generating port is a widely understood term. Please consider
> | providing a brief explanation.
>
> Replaced with "and connected to ports on routers that could otherwise have
> been consumed by paying customers"
>
> |
> | "In this way, SPs can offer new RaaS functionality to content providers at
> | potentially zero additional cost in new equipment (modulo the additional
> | bandwidth consumption)." At face value, this text appears to be at odds with
> | the previous statement that TreeDN reduces bandwidth consumption. Please
> | consider rephrasing this text to make it clearer what is meant here.
>
> Good point.  Rephrased to eliminate confusion.
>
> |
> | "Additionally, TreeDN is an open, standards-based architecture based on mature,
> | widely implemented protocols." The term "standard" has a specific meaning in
> | the IETF and refers to only RFCs published on the Standards Track, and not as
> | Experimental or Informational RFCs. While it appears that TreeDN can be
> | implemented based on specifications that are published as Standards-Track RFCs,
> | I'm not sure if TreeDN mandates that only Standards Track protocols can be
> | used, as opposed to Experimental or proprietary protocols. Please consider
> | rephrasing this text to clarify to what extent TreeDN is always based on IETF
> | standards.
>
> Removed "standards-based".
>
> |
> | Section 6:
> | "This reduces the cost for content sourcing […] By effectively reducing to zero
> | the marginal cost to the source of reaching each additional audience member" I
> | wonder if this text makes any implicit assumptions about the networks in which
> | content sources are located and about the interconnections and cost models used
> | by these networks. Please consider making these assumptions explicit.
>
> Explicitly noted this is from the perspective of the source.
>
> |
> | Section 7.2:
> | "Traditional unicast-based CDNs frequently rely on HTTPS over TCP transport"
> | Does this statement apply equally to QUIC, assuming we're not talking about MoQ
> | but simply replicating the existing unicast model using HTTP/3? If so, please
> | consider rephrasing this statement to be more generic and talk about HTTP in
> | general, independent of version.
>
> No, this statement applies to TCP, not QUIC.
>
> |
> | Nits/editorial comments:
> |
> | Section 3:
> | Please consider expanding PIM-SM and mLDP on first use.
>
> Added
>
> |
> | Section 4.2
> | Please consider expanding GTM on first use.
>
> Added
>
>