Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4

["Black, David" <[e-mail]>]

Ok, "signaling traffic for STUN [RFC5389] and TURN [RFC5766]"
	--> "STUN [RFC5389] and TURN [RFC5766] traffic"

It's even fewer words ;-) - consider that done.

Thanks,
--David


> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Friday, August 22, 2014 5:24 PM
> To: Black, David
> Cc: Colin Perkins; [e-mail]; [e-mail];
> [e-mail] WG
> Subject: Re: WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1
> mux items 3 and 4
> 
> I agree except where noted inline:
> 
> On Aug 22, 2014, at 3:27 PM, Black, David <[e-mail]> wrote:
> 
> >
> > Proposed new text (merging item 4 into item 3, which aligns with the
> > structure of RFC 5764 and the rfc5764-mux-fixes draft):
> >
> >   3.  An RTP session could be multiplexed with a single SCTP over DTLS
> >       association plus signaling traffic for STUN [RFC5389] and TURN
> >       [RFC5766] into a single transport level flow as described in
> >       [RFC5764] and [I-D.petithuguenin-avtcore-rfc5764-mux-fixes].
> >       STUN and TURN are used for NAT traversal.
> >
> 
> I agree with the direction here--but I'm not sure I would characterize STUN
> and TURN as signaling traffic. And STUN is used for connectivity checks, as
> well as NAT traversal. OTOH, maybe it would be better to just for this section
> to just say that STUN and TURN can be multiplexed in the flow without the
> additional comments about them?
> 
> 
> > Thanks,
> > --David
> >
> >
> >> -----Original Message-----
> >> From: Black, David
> >> Sent: Thursday, August 21, 2014 9:06 PM
> >> To: Ben Campbell; Colin Perkins
> >> Cc: [e-mail]; [e-mail];
> [e-mail]
> >> WG; Black, David
> >> Subject: RE: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02
> >>
> >> Colin - many thanks for the review.  I'll pick up your proposed changes,
> >> perhaps
> >> with minor edits.
> >>
> >> Ben,
> >>
> >>>>>  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
> >>>
> >>> Can we clarify what "other protocols" are expected? Are we just talking
> >> about
> >>> WebRTC data-channels over SCTP/DTLS, or other things? If the latter, are
> we
> >>> talking things we expect to do today, or in immediate futures, or
> extensions
> >>> that might happen someday?
> >>
> >> WebRTC will only multiplex its data channels, and this numbered list is
> about
> >> WebRTC, so this text should focus on those data channels - I'll revise the
> >> draft
> >> accordingly.
> >>
> >> Other text elsewhere in the draft is broader (e.g., SCTP/UDP without DTLS,
> >> which
> >> is of interest, even though WebRTC always uses DTLS).
> >>
> >> Thanks,
> >> --David
> >>
> >>> -----Original Message-----
> >>> From: Dart [mailto:[e-mail]] On Behalf Of Ben Campbell
> >>> Sent: Monday, August 18, 2014 4:48 PM
> >>> To: Colin Perkins
> >>> Cc: [e-mail]; [e-mail];
> [e-mail]
> >>> WG
> >>> Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02
> >>>
> >>> Hi,
> >>>
> >>> I concur with all of Colin's comments, save one question below:
> >>>
> >>> On Aug 18, 2014, at 10:17 AM, Colin Perkins <[e-mail]> wrote:
> >>>
> >>>> 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
> >>>
> >>> Can we clarify what "other protocols" are expected? Are we just talking
> >> about
> >>> WebRTC data-channels over SCTP/DTLS, or other things? If the latter, are
> we
> >>> talking things we expect to do today, or in immediate futures, or
> extensions
> >>> that might happen someday?
> >>>
> >>>>>
> >>>>>  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 <[e-mail]> 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: [e-mail]
> >>>>>> From: Ben Campbell <[e-mail]>
> >>>>>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02
> >>>>>> Date: August 9, 2014 at 12:50:16 PM CDT
> >>>>>> Resent-To: [e-mail], [e-mail], [e-mail]
> >>>>>> To: [e-mail]
> >>>>>> Cc: [e-mail], [e-mail],
> >>> Richard Barnes <[e-mail]>
> >>>>>>
> >>>>>> 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/avt
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Colin Perkins
> >>>> http://csperkins.org/
> >>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Dart mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dart