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.:

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 [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