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: magnus.westerlund at ericsson.com----------------------------------------------------------------------
|