Re: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13

[Bernard Aboba <[e-mail]>]

Cullen said:

"This has RTX (RFC4588) and MUST. RTX has turned out to be close to useless
in interactive communications systems because the RTT is just too high to
make this viable. "

[BA] Where temporal scaling is used, RTX can be useful in protecting the
base layer.  So it's not universally useless.  I do agree that MUST is too
strict, though.

"It says FEC is not required. I’m OK with this but my notes have it as the
WG previously agreed on this being required. "

[BA] Yeah, I wondered about that, too.


On Fri, May 9, 2014 at 7:41 AM, Cullen Jennings <[e-mail]> wrote:

>
> Overall the document looks in excellent shape. I do have a bunch of
> comments but they are all pretty easy to deal with.
>
> Page 5
> I think that draft-ietf-avtcore-rtp-multi-stream-optimisation should be
> MAY not a MUST. We don’t loose significant interoperability by not having
> it a MUST.
>
> Page
> Sending correct sync information should be MUST not SHOULD. We can’t make
> lip sync work without this and I think the flows I have seen already send
> it. Note people don’t have to deal with correctly implementing lip sync on
> the receiving end, they just have to send enough information to make it
> possible that receivers that want to can.
>
> Has the text "support for RTCP timer reconsideration." but I don’t know
> what this means or how to implement it - suspect we just need a ref or bit
> more text.
>
> I’d refer to see "reduced minimum RTCP reporting interval" be a MUST and I
> could live with MAY but SHOULD is just lame for this.
>
>
> Page 8
>
> It has the text
>
> An end-point that has signalled support for multiple RTP payload formats
> SHOULD be able to accept data in any of those payload formats at any time,
> unless it has previously signalled limitations on its decoding capability.
>
> I think that has to be a MUST not a SHOULD or else this will not work.
>
> Page 18
>
> This has RTX (RFC4588) and MUST. RTX has turned out to be close to useless
> in interactive communications systems because the RTT is just too high to
> make this viable. You need to set your jitter buffer to be larger than the
> RTT for this work and I am aware of any significant internet collaborations
> system that sets the jitter buffer size that high. I think this should be
> MAY not MUST but that said, I can easily live with MUST, it just seems
> useless at a time where we are trying to reduce the complexity of the
> system.
>
>
> Page 19
>
> It says FEC is not required. I’m OK with this but my notes have it as the
> WG previously agreed on this being required. It might be worth putting this
> up on a slide in the May meeting and checking the WG is good with no FEC.
> Perhaps my notes are all wrong - I did not try and go back throughout
> minutes. It’s possible the WG decided different things and different times.
>
>
> Page 20
>
> Has the text
>
>   signalled bandwidth limits SHOULD be used to limit traffic
>
> I might be reading this the wrong way but given the weak congestion
> control in general, I feel pretty strongly that the browser can’t ignore
> signaled bandwidth limits and this needs to say something more like the
> "MUST not exceed signaled bandwidth"
>
>
> Page 20-22,
>
> Section 7.2 - I felt like this section was supposed to convince me it was
> all OK but the more I read it the more confused I was. What does one do if
> sending video on says a 768 kbps link? Send every 5 frames?
>
> I think part of the confusion stemmed from the implication that to do good
> congestion control, you needed a report once ever say RTT but in RTP we
> could not do that so we would fall back to a far less frequent reporting of
> once ever frame. But ever frame is less than the RTT in most internet case
> so I was just confused by the whole section.
>
> I don’t think this section is going to help implementors much as it is -
> perhaps it could just be refactored a bit to help implementers understand
> how often to send RTCP and why.
>
>
> Page 24
>
> Has
>
> All WebRTC implementations MUST be prepared to receive RTP XR report
> packets, whether or not they were signaled.
>
> I disagree with this - we are in a non multicast environment with RTP
> inside DTLS/SRTP. One should not be getting reports for extensions that
> were not negotiated.
>
> Similarly on page 25 the text has
>
> The RTP extensions to be used SHOULD be agreed upon,
>
> I think this needs to be a MUST.
>
>
>
> Page 27
>
> I think it would be best to just remove the line
>
>  This document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to
> map unknown source packet stream SSRCs to MediaStreamTracks and
> MediaStreams.
>
> as that is not key to this spec.
>
>
> Page 36 - 37
>
> Section 12.2.2.
>
> So if I read this right, it says you MUST resolve SSRC collisions but RFC
> 5576 has no way to do that. What are implementors supposed to do ?
>
> Even ignoring 5576 - it’s just not clear to me how one detects and
> resolves SSRC collisions.
>
>
>
> Cullen with my individual contributor hat on.
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>