Re: [Rmt] DISCUSS and COMMENT: draft-ietf-rmt-bb-norm-revised

Although I just submitted a new version of the draft, it was brought to my attention that I didn't address everyone's comments. (I had erroneously assumed that emails were issued for all the discusses and had not checked the document tracker).

So, I overlooked comments from Ron Bonica, Ross Callon, and Dave Ward. This email focuses on Dave's comments.:

a) I agree that the reference to SSM needs to be fixed to be consistent and will do that.

b) With regards to NACK-BB vs. PGM, I will take a look at the text from 3940 as suggested and try to adapt it for the NACK-BB. In _some_ respects, PGM does in fact use some of the same basic mechanisms here. However there are some differences principally with the way that end-to-end feedback suppression and how the FEC building block can be incorporated as compared to the PGM approach. Perhaps that is close to what needs to be said (with details)?

c) In a former iteration of the NACK-BB, we had a section on "Intermediate System Assistance" (i.e. network-based optimization) that would have related to an original RMT charter item (Generic Router Assistance) that was not followed through by the original participants. I _had_ retained discussion in the NACK-BB document on this for the reasons you mention below, but in the last IESG last call was requested (by Pekka Savola) to remove that discussion since it was not currently being actively pursued. I conceded to his comment and removed that discussion.

I personally might have preferred to have retained that discussion since I am hopeful that intermediate system assistance might be revisited in the future (incl. supporting new concepts such as network coding as they mature), but since the Experimental RFC version of the NACK-BB still contains the discussion didn't think the concept would be entirely lost. The NORM Protocol has provisions in it that can be leverage for intermediate system assistance.

I would be happy to re-include this discussion, but perhaps we can get some comments from Pekka and/or the RMT working group on this issue?

Dace Ward comments:

Here are some suggestions and issues:

a) Section 4 refers to ASM service model (RFC1112) and
then to SSM as "Single-Source-Multicast" with reference
as Hughs Diss. Also section 2.6 refers to SSM this way.

These terms and references for SSM should be changed to
"Source Specific Multicast" and reference RFC4607. Those
are the right terms and the RFC1112 (ASM) equivalent
definition of SSM.

b) I suggest including an appendix section highlighting the
functional and value proposition differences between this
NAK building block and the equivalent found in PGM.

There is some discussion in NORM (RFC3940) in section
5.5.2 about this, which is difficult to grok, butIi
think it would belong (in better wording) into this
NAK building block.

c) I'd like the authors to add
a discussion about the applicability of network based NAK
implosion and/or local retransmitter based optimizations
to this building block, and whether or not it would be
possible to do this such that it can be added as an
afterthought into deployments without changes to senders
and/or receivers to better scale them upon increase of
topology and/or group-size.

It's not clear to me how to best have this highlighted,
because this is just the building block and not the full
protocol, so one might argue that this is a NORM issue,
not a NAK building block issue, but it also seems quite
impossible to me to resolve this issue without impacting the
NAK building block. For example, section 4 paragraph 2
of this draft talks about scalability limitation of NAK
approaches, but all of this is only true when you do
assume no network based optimization of retransmission

On Jul 15, 2008, at 8:43 AM, Magnus Westerlund wrote:

Hi,

Regarding the discusses on this document. It seems that you haven't resolved all of them, like David Wards. Can you please send messages to the ADs with discusses for which you think you have them resolved so that they get a trigger to clear.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Färögatan 6 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------