Hi Colin,

I've picked up your changes (including RTCWEB -> WebRTC globally)
in my working draft, with two exceptions:

(1) Items 3 and 4 in the list of what can be multiplexed.

I don't think you suggested any changes to these two items, but
they need significant attention for other reasons:

- Ben's comment that item 3 ought to focus on the WebRTC data channel
- STUN doesn't encapsulate WebRTC traffic (TURN does).

I plan to merge these items 3 and 4 as part of revising them, and
intend to move the topic of TURN encapsulation out to be discussed
elsewhere, as it's independent of multiplexing.  I'll propose
specific text in a separate message.

(2) PHBs and DSCPs for RTCP.

I'm not sure what to say about this, as it looks like I need to set
off a discussion (debate?) between you and my co-author, Paul Jones.  

Colin (from WGLC comments):

> Rather, within a single RTP session there are RTCP packets sent
> that give information about the RTP streams that are being sent, and that
> report on the reception quality of RTP streams being received. Using a single
> PHB and DSCP for all RTCP packets within an RTP session might make sense, but
> it's important to note that one role of RTCP is to provide an estimate of the
> round-trip time seen by the media, so the PHB/DSCP will have to be chosen with
> care to avoid biasing that estimate too much.

Paul (from shortly after the Toronto meeting:

> During the meeting, there was discussion of marking RTCP packets.  Some
> notes I received on this topic suggested that it was proposed that RTCP
> should be marked the same as for RTP.  The argument was that this is used
> for RTT calculations.  If that is what was said, I'd like to state my
> disagreement. :-)
> 
> The forward and reverse paths are not necessarily the same and there is
> nothing one should assume about the reverse path to provide guidance about
> the forward path (or vice versa).  As perhaps a gross example, I have the
> ability to download far faster on my home Internet connection than I can
> upload.  Other important traffic characteristics differ in each direction.
>  
> Further, an RTCP packet might provide information related to several different
> RTP packets.  I certainly would not want to see one RTCP packet per RTP packet.

I'll watch where that discussion goes before proposing text.

Thanks,
--David


> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Monday, August 18, 2014 11:18 AM
> To: dart@ietf.org
> Cc: avt@ietf.org WG; Ben Campbell; draft-ietf-dart-dscp-rtp.all@tools.ietf.org
> Subject: Re: [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02
> 
> Hi,
> 
> [I'm not on the DART list, so please cc me in replies]
> 
> This draft looks good overall, but I did have some comments, primarily about
> the discussion of RTP multiplexing.
> 
> The four bullet points in Section 2.1 that follow "The RTCWEB protocol suit
> encompasses a number of forms of multiplexing" seem to confuse RTP sessions,
> RTCP, and transport-layer flows. I suggest they be changed to:
> 
> >    The RTP streams that comprise a WebRTC session can be multiplexed
> >    together in a number of ways:
> >
> >    1.  Individual source streams are carried in one or more individual
> >        RTP streams. These RTP streams can be multiplexed onto a single
> >        transport-layer flow or sent as separate transport-layer flows.
> >        This memo only considers the case where the RTP streams are to be
> >        multiplexed onto a single transport-layer flow, forming a single
> >        RTP session;
> >
> >    2.  The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed onto
> >        the same transport-layer flow as the RTP stream with which it is
> >        associated, as described in [RFC5761], or it may be sent on a
> >        separate transport-layer flow;
> >
> >    3.  The RTP and RTCP traffic can be multiplexed with other protocols
> >        via UDP encapsulation over a common pair of UDP ports as described
> >        in [RFC5764] as updated by
> >        [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and
> >
> >    4.  The data may be further encapsulated via STUN [RFC5389] and TURN
> >        [RFC5766] for NAT (Network Address Translator) traversal.
> 
> In the following paragraph (penultimate paragraph in Section 2.1), I suggest
> changing "unidirectional UDP packet flow" to "transport-layer flow" since it
> will not be unidirectional (since RTCP also flows in the reverse direction),
> and might not use UDP.
> 
> In the first paragraph of section 2.2, I suggest changing "multiplexed over
> RTP sessions" to "multiplexed in a single RTP session" and "multiplexing of
> source streams in RTP sessions" to "multiplexing of source streams in a single
> RTP session".
> 
> In Section 6, the second bullet point refers to "an RTCP session". There is no
> such thing. Rather, within a single RTP session there are RTCP packets sent
> that give information about the RTP streams that are being sent, and that
> report on the reception quality of RTP streams being received. Using a single
> PHB and DSCP for all RTCP packets within an RTP session might make sense, but
> it's important to note that one role of RTCP is to provide an estimate of the
> round-trip time seen by the media, so the PHB/DSCP will have to be chosen with
> care to avoid biasing that estimate too much.
> 
> Editorial: the protocol is called WebRTC, but the working group is RTCWEB.
> Accordingly, I think all instances of "RTCWEB" in this draft need to change to
> "WebRTC".
> 
> Cheers,
> Colin
> 
> 
> 
> 
> 
> On 9 Aug 2014, at 19:48, Ben Campbell <ben@nostrum.com> wrote:
> > Hi,
> >
> > The DART working group has started a last call for draft-ietf-dart-dscp-rtp-
> 02, ending on August 22. This informational draft describes considerations for
> the use of DiffServ code points in situations where one multiplexes multiple
> RTP packet streams, and potentially other protocol streams, that share the
> same 5-tuple.
> >
> > Since this draft is likely of interest to several working groups, I would
> like to solicit additional reviews from participants of TSVWG, AVTCORE,
> MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback
> to the effect of "this is ready to progress") to the DART working group
> mailing list.
> >
> > Thanks!
> >
> > Ben.
> >
> > Begin forwarded message:
> >
> >> Resent-From: draft-alias-bounces@tools.ietf.org
> >> From: Ben Campbell <ben@nostrum.com>
> >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02
> >> Date: August 9, 2014 at 12:50:16 PM CDT
> >> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com
> >> To: dart@ietf.org
> >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com,
> Richard Barnes <rlb@ipv.sx>
> >>
> >> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's
> available on the data tracker at the following URL:
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/
> >>
> >> The WGLC will conclude on 22 August, 2014. Please send your comments to the
> authors and the DART mailing list. If you've reviewed it and think it's good
> to go, please say so.
> >>
> >> Thanks!
> >>
> >> Ben.
> >>
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>