Skip to main content

RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report
RFC 6642

Yes

(Robert Sparks)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Gonzalo Camarillo)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)

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

Robert Sparks Former IESG member
Yes
Yes (for -16)

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -16)

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -16)

                            
Brian Haberman Former IESG member
No Objection
No Objection (2012-04-04 for -16)
I just have a few questions on this draft:

1. The Protocol Overview section states : "Intermediaries in the network that receive a RTCP TPLR SHOULD NOT send their own additional Third-Party Loss Report messages for the same packet sequence numbers."  Why is this not a MUST?  Is it simply to handle intermediate devices that don't support this function?  If there is another scenario where a device may send a TPLR that overlaps, it would be good to spell that out.

2. There are two places (Sections 4.1 & 4.2) where the length field in the feedback message is set to "2+1*N".  Should I interpret that to mean the value is really just N+2?  Or is there something I am missing?
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -16)

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-04-08 for -16)
The document writeup says, "There are not yet any reported implementations." Are you really saying that for a protocol that appears to have serious congestion control effects, nobody has written a line of code yet? Has there been any testing of this at all? Are there any planned implementations (perhaps by more than one independent implementer)? If not, perhaps this should be published as Experimental first.
Ron Bonica Former IESG member
No Objection
No Objection (for -16)

                            
Russ Housley Former IESG member
No Objection
No Objection (for -16)

                            
Sean Turner Former IESG member
No Objection
No Objection (2012-04-11 for -16)
Had the same question Stephen had.
Stephen Farrell Former IESG member
No Objection
No Objection (2012-04-10 for -16)
Just checking: there's no way that a 3rd party loss report
could cause a flood of re-transmitted data (that hadn't
actually been lost) to be (re-)sent to a target is there? If
so, that might constitute a new DoS vector. Its not clearly
the case that that can't happen. If it could, then 
that'd be another reason to authenticate these messages.

nits/typos:

- s/to pose/pose/
- s/message,which/message, which/
- maybe s/the distribution source will not/if the
  distribution source will not/ in 6.1? (and some
  missing spaces there too)o
- I like "badly screwed up" as a descriptive phrase!
Stewart Bryant Former IESG member
No Objection
No Objection (for -16)

                            
Wesley Eddy Former IESG member
(was Discuss) No Objection
No Objection (2012-04-12 for -16)
moved from DISCUSS to COMMENT after emails from authors:

(1)

"screwed up" in Section 6.5 is not very technical; please say what is really wrong (loss, corruption, reordering, etc.)


(2)

Section 1 lists a number of *BUGS* in implementations as the motivations for this.  It starts by saying that a use case for this is people not implementing RFC 4585 dithering correctly, then says that another use case is that there are other poor designs causing implosions of FIRs.

It seems silly to write this new RFC adding a new mechanism rather than just applying pressure to fix those implementations; it would be useful to discuss why that isn't the right answer, since receivers have to implement reactions to this new report anyways, they should be fixing their bugs.  I think this is an especially relevant question given the lack of implementation noted in the writeup and Pete's ballot.