Re: [Mops] TreeDN next steps

[Leonard Giuliano <[e-mail]>]

Thanks for the thoughtful comments, Kyle.  To try to stimulate some 
discussion, here are some thoughts:

-The requirements envisioned are kind of covered in the intro section. We 
can peel them out into a new section explicitly named "Requirements" or 
rename the Intro, but the short answer to "what are the requirements?" is 
to build a scalable CDN architecture for live streaming content to mass 
audiences, where bitrates for streams are climbing and live audience sizes 
are exploding.  If this is not clear from the text, let us know.

-You aren't the first person to suggest a diagram, so we'll work on
something that hopefully makes it more clear.

-As for a more formal description of the architecture and the excellent 
question "Could multiple teams working independently create 
mutually-interoperating implementations of TreeDN from this document and 
normative references?"  In short, TreeDN is really just PIM-SSM + AMT. The 
main point we are trying to get across is that most people are scared away 
from mcast bc there's a laundry list of protocols that make their heads 
spin.  Here, we are saying most of that stuff is irrelevant- just use 
PIM-SSM on the parts that are native and then use AMT to tunnel over the 
non-native parts so unicast-only receivers can receive the streams.

-There is really nothing novel about the parts of architecture- PIM-SSM 
and AMT are mature and reasonably well-known (in "some" circles).  What is 
novel is the synthesis of these parts into an architecture that is greatly 
simplifed and useful in solving the problem (live streaming to mass 
audiences).  The goal is a clear document that is very readable and 
accessible for folks who care about content distribution but aren't 
necessarily familiar with the components (those reside outside the "some 
circles" above, but could really benefit most from this architecture). We 
could certainly dive deeper into the routing stuff, maybe talk about 
peering between TreeDN providers (perhaps pointing to RFC8313), maybe some 
discussion on MBGP for those peerings, but this routing stuff isn't 
terribly different for TreeDN than what is done today between content and 
service providers for traditional unicast content, and is that something 
this group would care about for those models?

Anyway, hope this frames what are the goals of the doc, and we are looking 
for more feedback from the WG on how best to achieve (and if they are good 
goals to have in the first place).  The doc is fairly short (and hopefully 
less rambling than my email here), so we'd welcome review and input on 
what is meaningful to this WG and what should/shouldn't be added to the 
doc.


Thanks,
Lenny

On Tue, 21 Feb 2023, Kyle Rose wrote:

| 
| We're now a little over a month out from the start of IETF 116, and the chairs would like WG participants to help us with a little prep work.
| 
| Now that we've completed adoption of the TreeDN draft, one next step for the chairs is to add WG milestones related to the document's development. Lenny stated that he
| should have sufficient time to devote to the document over the course of the year, so we could aim for a fairly aggressive timeline to WGLC. To that end, it seems like a
| reasonable approach would be for interested participants to identify areas where we think the document could use work and from that try to pin a rough date by which we think
| the document would be ready for preliminary expert reviews.
| 
| In my initial review, I noted that the document as it stood was very high-level. For example, the architecture section outlines and briefly describes a set of technologies
| leveraged by TreeDN, but no architectural description of how those pieces fit together to solve particular aspects of the problem space. A diagram or set of diagrams would
| be a good start in helping readers without deep knowledge of the multicast ecosystem form a mental model of how TreeDN works.
| 
| Similarly, the problem statement section lists three challenges for deployment of applications based on IP multicast, but does not translate these into specific requirements
| that motivate the combination of technology choices listed in the architecture section.
| 
| Being the type who prefers the horse in front of the cart, I would aim to flesh out the requirements first. One traditional way of doing this is to consider user stories for
| the problem space, but I'm not sure anything so formal is really required here: there exists plenty of literature looking at trend lines on the growth of internet video
| traffic and extrapolating those trends to very large numbers (q.v. one of Jake's presentations to mboned from a few years back). I could also see requirements related to
| democratization of content distribution, and probably a bunch of things I haven't thought of yet.
| 
| That having been said, I think good progress could also be made in parallel in detailing a more formal architectural description. The success criteria I would propose here
| is "Could multiple teams working independently create mutually-interoperating implementations of TreeDN from this document and normative references?" At this point the
| document seems a long way from that.
| 
| How does this sound? Once we have agreement on next steps, we can talk about what granularity of milestones for this draft makes sense for the WG.
| 
| Kyle
| 
|