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

"Black, David" <david.black@emc.com> Fri, 22 August 2014 20:28 UTC

Return-Path: <david.black@emc.com>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5D71A0682; Fri, 22 Aug 2014 13:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.969
X-Spam-Level:
X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 UiOqNAOgt6t2; Fri, 22 Aug 2014 13:27:59 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABC81A06C0; Fri, 22 Aug 2014 13:27:58 -0700 (PDT)
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKRsPI030820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 16:27:54 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MKRsPI030820
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408739275; bh=wSFrxb7gPvz95v9//OXJLDGuK3M=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kut0RRoE0341LRh4js+UbDCVdGjPWueST3uxO9VUBw4SzmrhwyxyyoO/1N1Q8uG7Z 1Vvd1nvctW+mQoFAr+8J3oVCbrlqH8iycPXqUEQlOp7gzY2DZ4Jo03/GaiH8tArJCw 44ZFwC6zkV+2i0vtVNNenPfJ+/lzVawusD/0m2H4=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MKRsPI030820
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 16:27:40 -0400
Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKRixh012085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 16:27:44 -0400
Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Fri, 22 Aug 2014 16:27:44 -0400
From: "Black, David" <david.black@emc.com>
To: Ben Campbell <ben@nostrum.com>, Colin Perkins <csp@csperkins.org>
Date: Fri, 22 Aug 2014 16:27:43 -0400
Thread-Topic: WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4
Thread-Index: Ac++R4bkunELpkmtSCSVGR/gKcaoAg==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A80@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: DLM_1, public
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/GNC8bCFHkSW46USj5Q-LRmU5yV8
Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>, "Black, David" <david.black@emc.com>, "dart@ietf.org" <dart@ietf.org>, "avt@ietf.org WG" <avt@ietf.org>
Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 20:28:01 -0000

Section 2.1 of the draft currently has this text on WebRTC multiplexing:

   3.  An RTP session could 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.

That text has at least a couple of problems:

	- This list is about WebRTC, so item 3 ought to specifically
		focus on the WebRTC data channel.
	- STUN doesn't encapsulate WebRTC traffic (TURN does).

On the latter, for simplicity, I plan to remove the mention of
encapsulation from here and deal with it elsewhere as part of
discussion of what happens if TURN decides to send all the traffic
over TCP (that'll be in a separate message, stay tuned).

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.

Thanks,
--David


> -----Original Message-----
> From: Black, David
> Sent: Thursday, August 21, 2014 9:06 PM
> To: Ben Campbell; Colin Perkins
> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; avt@ietf.org
> 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:dart-bounces@ietf.org] On Behalf Of Ben Campbell
> > Sent: Monday, August 18, 2014 4:48 PM
> > To: Colin Perkins
> > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; avt@ietf.org
> > 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 <csp@csperkins.org> 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 <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/
> > >
> > >
> > >
> >
> > _______________________________________________
> > Dart mailing list
> > Dart@ietf.org
> > https://www.ietf.org/mailman/listinfo/dart