[AVTCORE] ***SPAM*** 7.478 (5) Comments on draft-stokking-avtcore-idms-for-iptv-00

[Kevin Gross <[e-mail]>]

Sorry I have gotten behind following AVT. I will try to catch up. Hans
asked me to have a look at his draft and so here are my comments:

I would avoid using the "SSM" acronym. It is most commonly used for
Source-Specific Multicast. Although RFC 5760 talks about Single-Source
Multicast, it uses "SSM" to refer to Source-Specific Multicast

It took me a while to appreciate the scaling problem you're trying to solve
here. It seems unlikely and undesirable to synchronize all viewers of an
IPTV stream. As per the use cases described in RFC 7272, we're talking
about potentially numerous but small groups. Most viewers will watch in
isolation and don't need synchronization. Can you include some details for
use case where IDMS scalability is an issue. Streams with millions of
receivers doesn't necessarily stress IDMS, what are these receivers trying
to do?

At the top of page 5, maybe you mean RTP timestamp, not NTP timestamp in
two places. Unless you're using RFC 6051, there is no NTP timestamp in the
RTP packet. But further down in the paragraph it appears that RTP
timestamps are different, "various RTP/NTP relationships." I'm confused.

I think Figure 1 and Figure 2 are sort of swapped. In RFC 7272 the
presentation timestamps are 64 bits and the receive timestamps are 32 bits.
You're showing the opposite here.

In section 3, I'm not sure I appreciate why multicast IDMS settings packets
is not considered scalable. This information does not need to be
transmitted frequently. It doesn't look like parsing a large list of
synchronization groups is an unreasonable task in the context of all the
other RTCP traffic a receiver will be fielding in such a widely-received
stream.

Kevin Gross - AVA Networks