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

Suhas Nandakumar <suhasietf@gmail.com> Fri, 09 May 2014 23:36 UTC

Return-Path: <suhasietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9DF1A00F6 for <rtcweb@ietfa.amsl.com>; Fri, 9 May 2014 16:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5ZynRkK9yP0 for <rtcweb@ietfa.amsl.com>; Fri, 9 May 2014 16:36:46 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0EC1A010C for <rtcweb@ietf.org>; Fri, 9 May 2014 16:36:45 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id f8so2058981wiw.16 for <rtcweb@ietf.org>; Fri, 09 May 2014 16:36:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NOUnn51q9C7kAi9wAO6fv+kC2BFlOwgSsl4voKSUFG4=; b=knP0yADB6RfrrWmRWVKzk/zyv0zsY3JUtw4pdB70sq06Htd9ZVkzBBrSmdmKzpxkO7 yP2flYnhj5X4TpOAudughpzoOoyGglNhHbuLs0COlS01kwySHs4rNcHkjJX6UG2BXhL6 wupYsFCdOsznIohWhwobWzcZ9QvdI2BBHKFC8brYDcpci4TLnWZs2A+Oweyl4gMqiFbd TkH4IIcHQ+EN1S24rNAiwgATtvUC5zuh3gS8YEzJpTtYT3XqD3r04GZADTC/3fsZiJmJ tP1Tnoj389yK9jokgNNYmIHkx/GRjVsztHaV1bOrFFvHIQcJ55QhAbXxoInRuqHQBQgK 2YfQ==
MIME-Version: 1.0
X-Received: by 10.194.60.4 with SMTP id d4mr10638323wjr.28.1399678600096; Fri, 09 May 2014 16:36:40 -0700 (PDT)
Received: by 10.180.13.73 with HTTP; Fri, 9 May 2014 16:36:40 -0700 (PDT)
In-Reply-To: <2FAF1D94-DBAB-43EB-97CF-7ACA2213A7B5@iii.ca>
References: <CA+9kkMCeoA27gOw=6+oESFGptDrXYpXeux7yjBByHaApp7=-YA@mail.gmail.com> <2FAF1D94-DBAB-43EB-97CF-7ACA2213A7B5@iii.ca>
Date: Fri, 9 May 2014 16:36:40 -0700
Message-ID: <CAMRcRGSmnZH=D8BAMZ5v7nOMJfdLsiMdmW6GfH+-mH9QJZ-Yxg@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary=047d7bacb40ec2302004f900115f
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aZsWeZTRb_YOfSDZ0-eoiEyVq7w
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 23:36:50 -0000

Thanks Magnus and all for this work. I liked the way the document has
turned out to be.

Apologies for the last minute response, I am been wanting  to read this
spec and finally got some time late in this week.

I have listed down few points that reflect my notes when i read the
document from a RTP implementor and WebRTC developer perspectives.

*Comments*


2. Handling of documents from AVTCore related to MultiStream,
MultiStreamOptimization, MultiMediaRTPSession that are normatively
referenced. It was not clear if all these should be normatively referenced.

3. RTP Taxonomy usage. This comment is applicable to the RTP documents
referred by this document which dont follow the Taxonomy. This caused lot
of concept mapping in my mind to go between the different usages to
understand the implications. I would strongly recommend alignment with the
Taxonomy for these dependent documents and I volunteer to do some of it If
needed.

4. trr-int of 4 seconds has be recommended in couples of places. But i dont
see a reference to the choice of 4 seconds and the reason why it was chosen
that way. I am not sure if we want to specify this detail in this document.

5. Section 4.1 says,

   - Support for multiple end-points in a single RTP session, and for
   scaling the RTCP transmission interval according to the number of
   participants in the session; support for randomised RTCP transmission
   intervals to avoid synchronisation of RTCP reports; support for RTCP timer
   reconsideration.

All these MUST requirements need references. If some of these belong to
RFC3550, then we need to say that.

6. Section 4.2
     Not sure if the side note for trr-int fits in this section

7. Section 4.3 Para 2
      - I felt this Para was getting too busy in laying out the cases of PT
Reuse combinations. Can we break it , if possible ?
      - We can probably delete the note referring to BUNDLE spec since we
refer to it again in Section 4.4 where it contextually makes more sense.

8. Section 4.3 Para 3
   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.

Shouldn't the SHOULD be MUST above. If not, I think we fail interoperability

9.Nit ..  Section 4.4 Para 3 says
Further discussion about the suitability of different RTP session
structures and multiplexing methods to different scenarios are suitable can
be found in [I-D.ietf-avtcore-multiplex-guidelines]<http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-13.html#I-D.ietf-avtcore-multiplex-guidelines>
.

How about rewording it to,
Further discussion about the suitability of different RTP session
structures and multiplexing methods to different scenarios can be found in
[I-D.ietf-avtcore-multiplex-guidelines]<http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-13.html#I-D.ietf-avtcore-multiplex-guidelines>
.


10.  Section 5.1 ( Topology Recommendations)
       - Nit .. Adding reference to RTCPeerConnections might be useful
       - I dont think this document should make recommendations against
applicability of a particular topology for a given context. Specifically,
the pointers to carrying out congestion control mechanisms are still under
development and denying a topology based on it might not be a good idea. I
would prefer this section referring to the Topo document as an informative
reference and implications of each topology under various scenarios should
be moved in there, if needed.

11. Section 5.1.2
      Should we add the requirement for the WebRTC end-point sending PLI
messages?

12. Section 10
     - Nit - Reference to ICE is needed

13. Section 11 Para 3
       Not sure, if this is needed altogether. Probably saying a given
Media Source might end up in several RTP Packet Streams  with their
associated SSRC following WebRTC API mechanisms defined in <ref>

 14. Section 11 says
 Note: this doesn't result in a tracking issue, since the creation of
matching CNAMEs depends on existing tracking.

  We need bit more context here explaining the tracking or remove it
altogether

15. Section 8
      There is no requirement that the data contained in such reports be
used, or exposed to the Javascript application, however.
  Do we need this sentence ?

16. Section 11 has,
The above will currently force a WebRTC end-point that receives an
MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing on any
RTCPeerConnection to perform resynchronisation of the stream. This, as the
sending party needs to change the CNAME, which implies that it has to use a
locally available system clock as timebase for the synchronisation. Thus,
the relative relation between the timebase of the incoming stream and the
system sending out needs to defined. This relation also needs monitoring
for clock drift and likely adjustments of the synchronisation. The sending
entity is also responsible for congestion control for its the sent streams.
In cases of packet loss the loss of incoming data also needs to be handled.
This leads to the observation that the method that is least likely to cause
issues or interruptions in the outgoing source packet stream is a model of
full decoding, including repair etc followed by encoding of the media again
into the outgoing packet stream. Optimisations of this method is clearly
possible and implementation specific.

Probably,I am missing the context here, but I don't see the need for this
para in this document since it is very application specific

17 Section 12
    - Not sure if we really need the topology details in here. But I am
fine going with it one way or the other.

18. Section 12.1.3
     Should this be moved out as a separate section, since, it is more than
just implementation guidelines

19. SSRC Collision
     It is not clear what implementation guidelines that is being provided.






Cheers
Suhas






On Fri, May 9, 2014 at 7:41 AM, Cullen Jennings <fluffy@iii.ca> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>