Skip to main content

Forward Error Correction Grouping Semantics in the Session Description Protocol
RFC 5956

Yes

(Robert Sparks)

No Objection

(Alexey Melnikov)
(Dan Romascanu)
(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Ron Bonica)
(Stewart Bryant)

Note: This ballot was opened for revision 10 and is now closed.

Lars Eggert (was Discuss) No Objection

Comment (2010-04-20)
Section 1., paragraph 1:
>    Any application that needs a reliable transmission over an unreliable
>    packet network has to cope with packet losses.  Forward Error
>    Correction (FEC) is an effective approach that provides reliable
>    transmission particularly in multicast and broadcast applications
>    where the feedback from the receiver(s) is potentially limited.

  FEC doesn't provide complete reliability - it provides *improved*
  reliability under loss (compared to no FEC), but only to a certain
  loss rate.


Section 3., paragraph 0:
> 3.  Requirements and Changes from RFC 4756

  It would be good to also discuss how exactly this document updates
  3388bis and 5576. (3388bis is mentioned, but at least to me it's
  unclear what the update here is; 5576 is not mentioned.)

(Robert Sparks; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2010-04-29)
The -08 revision addresses nearly everything from my previous Discuss and Comment.

In my Discuss I said:

>> Section 3.2
>> It is not clear from reading this section how there is 
>> any "Requirement and Changes from RFC 4756" described.
>> I presume that [I-D.ietf-fecframe-framework] describes
>> something that cannot be provided by RFC 4756. The text
>> should say so!

Ali reponded:

> 4756 did not have semantics to define/specify additive
> repair flows.

I understand, but my problem is that the text in this section does not say what is new or different from 4756, and does not state that the description of additivity summarised in this section is a feature added by this document.

I would fix this as (changes in first and last paragraph)...

   The FEC Framework [I-D.ietf-fecframe-framework] also describes 
   support for additive repair flows.  Additivity among the repair flows
   means that multiple repair flows may be decoded jointly to improve
   the recovery chances of the missing packets in a single or the same
   set of source flows.  Additive repair flows can be generated by the
   same FEC scheme or different FEC schemes.

   For example, in Figure 3, repair flows R5 and R6 may be additive
   within the FEC Framework instance #1.  Alternatively, all three
   repair flows R5, R6 and R7 could be additive, too.

           SOURCE FLOWS              | FEC FRAMEWORK INSTANCE #1
           S4: Source Flow |---------| R5: Repair Flow
                           |         | R6: Repair Flow
                           |
                           |---------| FEC FRAMEWORK INSTANCE #2
                                     | R7: Repair Flow

    Figure 3: Example scenario with two FEC Framework instances, where
    two repair flows in the first instance and a single repair flow in
            the second instance protect the same source flow S4

   This document defines the mechanisms to support additive flows that
   were not included in [RFC4756].

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Harrington; former steering group member) (was Discuss) No Objection

No Objection (2010-06-09)

                            

(Gonzalo Camarillo; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2010-04-19)
Please spell out "SSRC" on first use.

The text "It is RECOMMENDED that the receiver SHOULD do integrity check" is conformance language overload; it is sufficient to say "The receiver SHOULD perform integrity checks..."

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2010-04-20)
  Please consider the Gen-ART Review comments from David Black:

  The IPv4 addresses used in the examples are not from the 192.0.2.0/24
  block of addresses for examples - they appear to be IP Multicast
  addresses, and I'm not sure what IP Multicast addresses are
  appropriate for use in examples.

  The 3388bis entry on the Updates: line on the title page is novel.
  Please add an RFC Editor Note to the Abstract asking the RFC Editor
  to replace that with the RFC number assigned to 
  draft-ietf-mmusic-rfc3388bis-04 when it is published.

(Sean Turner; former steering group member) No Objection

No Objection (2010-04-21)
Two nits on the security considerations:

1) r/failure of FEC to protect, and/or mishandling of other media payload streams/failure of FEC to protect, and/or mishandle other media payload streams

2) r/do integrity check/do an integrity check

(Stewart Bryant; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection (2010-04-21)
I support Alexey's discuss with respect to section 4.4.