[Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02

"Black, David" <david.black@emc.com> Fri, 22 August 2014 20:12 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 69E1E1A0B77; Fri, 22 Aug 2014 13:12:28 -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 1nakvOx-zamu; Fri, 22 Aug 2014 13:12:26 -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 E2C581A0B13; Fri, 22 Aug 2014 13:12:25 -0700 (PDT)
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKCJxL026823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 16:12:20 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MKCJxL026823
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408738340; bh=g0LEEAbeiL0x5qlVrYlrS24CzJ0=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=KaAoe412suL5NqXBgo6BShHD0A7DXcAK2AZyBCqsfTBZnKbcFuxSnrPwF5RUNTr6b nhjHSyhU8yy4Tb3Xf6626/pGspsEbzpXkvqedHG06RWVYg018kgILH4ObvLgzcvu1X zo7Cp8hWMMhvHw/Jwhza12e0tQB9GLCorPkYT70g=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MKCJxL026823
Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 16:12:08 -0400
Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKCDb1013366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 16:12:13 -0400
Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Fri, 22 Aug 2014 16:12:13 -0400
From: "Black, David" <david.black@emc.com>
To: Colin Perkins <csp@csperkins.org>, "dart@ietf.org" <dart@ietf.org>
Date: Fri, 22 Aug 2014 16:12:11 -0400
Thread-Topic: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02
Thread-Index: Ac++RVa30ZbqhMbvSbS28VmO3im/pA==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A7A@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: mailusrhubprd04.lss.emc.com
X-RSA-Classifications: DLM_1, public
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Xr_GN7Rs2THIkW5RP7bzlSLtJlQ
Cc: Ben Campbell <ben@nostrum.com>, "avt@ietf.org WG" <avt@ietf.org>, "Paul E. Jones \(paulej@packetizer.com\)" <paulej@packetizer.com>, "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>
Subject: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02
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:12:28 -0000

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/
> 
>