Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 10 Jun 2015 20:07:17 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-rtcweb-rtp-usage-24: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This draft looks very helpful, and I could understand it pretty well, I
think.

I did have a few comments.

Am I reading this correctly? 

   The following RTP and RTCP features are sometimes omitted in limited
   functionality implementations of RTP, but are REQUIRED in all WebRTC
   Endpoints:
   
... skipping down to ...   
   
   o  Support for sending and receiving RTCP SR, RR, SDES, and BYE
      packet types, with OPTIONAL support for other RTCP packet types
      unless mandated by other parts of this specification.  
      
Is this saying that OPTIONAL support is REQUIRED unless some other part
of the spec says it's a MUST? or a MUST NOT? or something else entirely?

In this text,

   Signalled bandwidth limitations, such as SDP "b=AS:" or
   "b=CT:" lines received from the peer, MUST be followed when sending
   RTP packet streams.  A WebRTC Endpoint receiving media SHOULD signal
                                                          ^^^^^^
could you help me understand why this is a SHOULD, and not a MUST?       

   its bandwidth limitations.  These limitations have to be based on
                                                 ^^^^^^^^^^^^^^^^^^^
   known bandwidth limitations, for example the capacity of the edge
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   links.
   
S0, not a 2119 MUST/REQUIRED ... is this simply recognizing that the
signaled limitation has to be based on something, and the capacity of the
edge links is the best upper limit that is easily available without
probing? Or is it saying something else? I'd think the capacity of the
edge links wouldn't be a great plan if you end up with a multi-unicast
mesh with no middleboxes, for instance (but I could be wrong about that),
but you might be saying that's still as good a limit as anything else.

In this text,

   However, implementations that can use
   detailed performance monitoring data MAY generate RTCP XR packets as
   appropriate; the use of such packets SHOULD be signalled in advance.
   
I wouldn't ask this question except that the draft has an entire section
on dodgy implementations, but ... is there an unstated assumption that if
the use of RTCP XR packets is signaled, the sender would respond to this
information? I'm guessing "yes", and that could be fine, but I wanted to
ask.

I think Section 9.  WebRTC Use of RTP: Future Extensions is very good,
but I wonder if the first paragraph needs to be as 2119-heavy as it is.
The second paragraph says what it needs to say without 2119 language.

In this text, I think there's a nit.

      whereas it would it all three participants were part of a single
                       ** I'm guessing this is "if"?

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Jun 2015 16:45:26 +0200

Hi,

Please see inlien.

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

So RTCP packet type SR, RR ,SDES and BYE are REQUIRED (following the top 
statement), but the other RTCP packet types are OPTIONAL unless mandated 
explicitly further down in the document.

Do you want us to rewrite this so that it is clearer that the second 
part is just a note that the not explicitly enumerated packet types are 
OPTIONAL?

      o  Support for sending and receiving RTCP SR, RR, SDES, and BYE
         packet types. Note, that the other RTCP packet types are
         OPTIONAL to support unless mandated by other parts of this
         specification.

>     its bandwidth limitations.  These limitations have to be based on

The reason for a SHOULD is that it may not know. Then signalling a 
limitation it doesn't know is strange. Therefore the should.

If one considers how these figures are created in other applications, 
they are often based on knowledge about the highest intended to be used 
bit-rate for any of the offered codecs and the number of streams are 
usually known. For WebRTC that is less certain. Thus, here one should 
offer a limit that is more related to what one actually know is a 
limitation for what one is capable of receiving. Thus maximum number of 
streams times highest codec rate is possibilities. But that does not 
provide good figures for video either.

So it is fiddly in how an implementation populate the field well.

> information? I'm guessing "yes", and that could be fine, but I wanted to

If RTCP XR is signalled, then it is a request to send those RTCP XR 
attributes, i.e. the consumer requests them to be sent. (unless recvonly 
direction where it is informative what one could report) Thus, yes if 
one request them one can assume that endpoint has some use for them. 
However, because of this style of signalling and multiparty scenarios it 
is a possibility that RTCP XR are included and forward to a particular 
endpoint. The intention is that one should signal and agree on what is 
being sent, but it can't be considered erroneous if an RTCP XR packet 
showed up unasked for.

I would note that if any specific response are expected from the 
reception of an RTCP XR that would need to be specified somewhere.

> The second paragraph says what it needs to say without 2119 language.

Yes, I agree that these RFC 2119 could be replaced.

MUST -> have to
SHOULD (remove)

Any issues with changing this?

>                         ** I'm guessing this is "if"?

Yes, it is a nit.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------