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

[Brian Adamson <[e-mail]>]

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 [phone]
> Färögatan 6                | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>

_______________________________________________
Rmt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rmt