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

From: Brian Adamson <[email-masked]>
Date: Wed, 16 Jul 2008 08:54:10 -0400

I had forgotten to cc Ross on this note, so this retransmission is for  
his benefit.

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 Ross' comments.:

With regards to the comments:  I added the "obsoletes RFC3941"  
statements.  I will add the details you suggest on approaches to  
possibly deal with poorly-performing receivers in the group and fix  
the sentence in Section 1.

On Ross' questions:

The way the NACK-based protocols can use FEC is _not_ just to reduce  
the probability of error by adding FEC packets to the stream, but to  
actually send FEC packets in response to NACKs as repair packets.   
With Maximum Distance Seperable (MDS) FEC codes like Reed Solomon, the  
protocol can deterministically and efficiently send FEC repair packets  
so that receivers can fill their "erasures" (missing packets in this  
case) within FEC blocks.  This building block and the NORM PI, in  
further detail, describe the FEC-based repair strategies to somewhat  
optimize this approach.  This is one of the differences with this  
building block/NORM and the PGM spec  (this relates to the other IESG  
comment).
And BTW, the NACK protocols can actually do both:  add "proactive" FEC  
content to the original transmitted content _and_ provide additional  
FEC repair packets in response to NACKs as needed.  I will review this  
discussion in the document and try to clarify this further.

And I can move forward the "bulk transfer" definitions the document  
addresses as you suggested.

> Ross Callon comments:

>> I just have a few minor comments that the authors can address or  
>> not at their discretion. Having once long ago looked at a few  
>> reliable multicast protocols I had noticed that reliable multicast  
>> is in fact a family of loosely related problems rather than one  
>> problem, and I am quite pleased that this document recognizes and  
>> clarifies this, and is focused on an approach that supports  
>> multiple related solutions.
>>
>> Questions:
>>
>> Does this document obsolete RFC3941? If so it should say so.
>>
>> Minor:
>>
>> I think that you should say a bit more about what to do when one  
>> receiver, or a few receivers, are suffering from either much slower  
>> or much less reliable service than other receivers. One option  
>> would be to slow down the entire group. Another option would be to  
>> remove the receiver from the group, and either serve it in a  
>> different group, or not serve it at all. Is there some threshold  
>> below which a receiver should be cut out of the group (since it  
>> would be harming service to everyone else)? Is this so obvious that  
>> it doesn't need to be discussed?
>>
>> Minor Editorial:
>>
>> In section 1, the following sentence is at best awkward, and is  
>> probably not grammatically quite right:
>>
>>   Here the protocol mechanism for reliability is described as a  
>> "repair
>>   process" since the use of packet-based Forward Error Correction  
>> (FEC)
>>   erasure coding for recovery of missing packets as compared to
>>   classical re-transmission schemes.
>>
>> I have two questions regarding this sentence. One issue is that my  
>> understanding of FEC is that it can be used to substantially reduce  
>> the probability of error. However, it can't completely eliminate  
>> any chance of error. Also, the document otherwise talks about NAKs,  
>> suggesting that there will be cases where receivers have figured  
>> out that they are missing something (and something like "classic  
>> retransmission" may be needed). Thus on the one hand I can't figure  
>> out what this sentence is intending to say (and my second problem  
>> is that whatever it is trying to say, I don't think that it does).
>>
>>
>> In reading section 2 (top of page 5) there is the mention of bulk  
>> transfer. At this point I was wondering whether this referred to a  
>> known fixed length bulk transfer (in the case that one receiver  
>> among a great many miss a few packets, this would allow reliable  
>> multicast by transmitting the whole thing once and then going back  
>> and retransmitting parts that someone missed) versus indefinite  
>> length bulk transfer (which needs a different solution). About 20  
>> pages later I found the correct answer in section 3.5 on page 25  
>> (which is that both need to be supported). I am wondering if there  
>> should be a very brief forward reference on page 5 (although a  
>> reader might assume that they need to read on if they have such  
>> questions early in the document).

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: [email-masked]
> ----------------------------------------------------------------------
>

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

---

From: Brian Adamson <[email-masked]>
Date: Wed, 16 Jul 2008 08:50:43 -0400

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

On Ross' questions:

---

From: Brian Adamson <[email-masked]>
Date: Wed, 16 Jul 2008 08:40:14 -0400

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