From nobody Thu Jun 5 02:06:31 2014 Return-Path: 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 AA5C61A0407 for ; Thu, 5 Jun 2014 02:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 zVRfC2_klHxX for ; Thu, 5 Jun 2014 02:06:26 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id C39B31A03C8 for ; Thu, 5 Jun 2014 02:06:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CC7627C373B for ; Thu, 5 Jun 2014 11:06:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYbHFdJi-iJr for ; Thu, 5 Jun 2014 11:06:17 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4D4C47C36FB for ; Thu, 5 Jun 2014 11:06:17 +0200 (CEST) Message-ID: <53903308.60302@alvestrand.no> Date: Thu, 05 Jun 2014 11:06:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dart@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/8qlzfbfva0kNMayx2bQ-6VVuGzQ Subject: [Dart] Test, please don't ignore X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:06:27 -0000 The official DART archive shows four messages, reflecting the WG review and WG approval. Nothing since April 22. If there is a discussion elsewhere, please send the list a pointer. From nobody Thu Jun 5 09:29:09 2014 Return-Path: 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 6633D1A02D2 for ; Thu, 5 Jun 2014 09:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 PsLdG32lRSW3 for ; Thu, 5 Jun 2014 09:29:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EFC1A023E for ; Thu, 5 Jun 2014 09:29:07 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s55GSfk3008921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jun 2014 11:28:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell In-Reply-To: <53903308.60302@alvestrand.no> Date: Thu, 5 Jun 2014 11:28:39 -0500 X-Mao-Original-Outgoing-Id: 423678519.124542-7523a3175f1b2b214f404760de2688d4 Content-Transfer-Encoding: quoted-printable Message-Id: <7B19A8A3-EA07-47F5-8AD3-BE47D7E9881E@nostrum.com> References: <53903308.60302@alvestrand.no> To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/VWBt0tiAXKIG_m8ILuLffgTxE3E Cc: dart@ietf.org Subject: Re: [Dart] Test, please don't ignore X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:29:08 -0000 On Jun 5, 2014, at 4:06 AM, Harald Alvestrand = wrote: > The official DART archive shows four messages, reflecting the WG = review and WG approval. Nothing since April 22. >=20 > If there is a discussion elsewhere, please send the list a pointer. >=20 There has been no discussion so far, other than between co-authors = working on a 00 draft. They expect to have that published shortly, then = hope to see real discussion happen on this list. Thanks! Ben. From nobody Thu Jun 5 10:19:19 2014 Return-Path: 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 6FB691A0239 for ; Thu, 5 Jun 2014 10:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 E_awfRYrk3uW for ; Thu, 5 Jun 2014 10:19:15 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 143111A029B for ; Thu, 5 Jun 2014 10:18:05 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta12.westchester.pa.mail.comcast.net with comcast id AgQ51o0040ldTLk5ChHygD; Thu, 05 Jun 2014 17:17:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id AhHy1o00U3ZTu2S01hHyLU; Thu, 05 Jun 2014 17:17:58 +0000 Message-ID: <5390A646.3080505@alum.mit.edu> Date: Thu, 05 Jun 2014 13:17:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dart@ietf.org References: <53903308.60302@alvestrand.no> <7B19A8A3-EA07-47F5-8AD3-BE47D7E9881E@nostrum.com> In-Reply-To: <7B19A8A3-EA07-47F5-8AD3-BE47D7E9881E@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401988678; bh=wyoJmJ9ro1qOXvOPOO5VgsQZHFZstFriyXxu2dadWbw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mi7hjcYrOUH6mxjg7LVj9ZqEsnJsDgkCmr8QPxDxiZuHpFAD0yWLFkGdk2ltRs9Je VFWUmUEgN8G5OMCOHGoCG0GWlYTz7or7cSJ4RG4oqhT1oeJTAurARJqyKqoV1vLY6X hCmhXnxWS1OyHg5ax53MexmFnQDHM5R3filOSQBa2x8Kqv/mt9CXwOqiTveB0KzGNF bcHVoHsuLR8H8EALcv0YvL9uIe2EVpg2cDM0xPozfLkFRJCGovYcijA0xYCaKltCaG W+KPqg/uEafe3H2bN7ZzszmLuAkt7htFJWTfuta3Ch5Jtb1aOsPnLHHq4mIXPo0aJZ tjhq1GNqrL9qA== Archived-At: http://mailarchive.ietf.org/arch/msg/dart/AMVTuqtmJ_9qQj3weLqqQVYVSc8 Subject: Re: [Dart] Test, please don't ignore X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:19:16 -0000 On 6/5/14 12:28 PM, Ben Campbell wrote: > > On Jun 5, 2014, at 4:06 AM, Harald Alvestrand wrote: > >> The official DART archive shows four messages, reflecting the WG review and WG approval. Nothing since April 22. >> >> If there is a discussion elsewhere, please send the list a pointer. >> > > There has been no discussion so far, other than between co-authors working on a 00 draft. They expect to have that published shortly, then hope to see real discussion happen on this list. Who are the co-authors? Thanks, Paul From nobody Fri Jun 6 18:05:25 2014 Return-Path: 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 EF4941A027C for ; Fri, 6 Jun 2014 18:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 e-eqbw1gPUsK for ; Fri, 6 Jun 2014 18:05:20 -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 834841A0272 for ; Fri, 6 Jun 2014 18:05:20 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5715CU9001753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jun 2014 21:05:12 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5715CU9001753 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402103112; bh=B2DgM3N1eOeBY08xd7Gf1A6alDA=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=u1tRn+KInihjj7CZ6pnJnZqYPa+1mQhEtl3Rq+vITZTUIemUHIuffRQU/FxERMCWT NS6b3CUMm5m2vJ35mRdkBJeLOz6Jlzq7eYqlgiVcIqAgVI4RjYoHW1Bbqhc061HTTz QdZiMn8c6MM+g4PM5PRnbQYXNefT0lM/WR3EA+/M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5715CU9001753 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor) for ; Fri, 6 Jun 2014 21:04:55 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5714shp024524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Jun 2014 21:04:55 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Fri, 6 Jun 2014 21:04:54 -0400 From: "Black, David" To: "dart@ietf.org" Date: Fri, 6 Jun 2014 21:04:53 -0400 Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> In-Reply-To: <20140607004925.14786.21299.idtracker@ietfa.amsl.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/heHfB_XPfTiiNd-G-kxxQFFbAwo Subject: [Dart] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 01:05:23 -0000 On behalf of the author team, here's an initial -00 draft for consideration by the dart WG. Please keep in mind that this is a -00 draft, so it really is a "draft". I should be embarrassed that it appeared to take a public nudge from a past IETF Chair (Harald) to get this draft to appear, (Aside: if you'd like that ability, send your name to the NomCom this year - they're always looking for interested candidates for all positions), but the fact of the matter is that more than one of us had the experience of life being what happens while one is busy making other plans. Comments and feedback are welcome and encouraged. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, June 06, 2014 8:49 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Differentiated Services (DiffServ) and Real-time = Communication Authors : Dan York David Black Cullen Jennings Paul Jones Filename : draft-york-dart-dscp-rtp-00.txt Pages : 13 Date : 2014-06-06 Abstract: This document describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). As a result, use of different DSCPs within a single traffic flow may cause transport protocol interactions (e.g., due to reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This document covers the implications of these DiffServ aspects for real-time network communication, including RTCWEB. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jun 6 18:24:57 2014 Return-Path: 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 337EA1A02AC for ; Fri, 6 Jun 2014 18:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 UNwgJxNd_mNR for ; Fri, 6 Jun 2014 18:24:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FD91A02A3 for ; Fri, 6 Jun 2014 18:24:54 -0700 (PDT) Received: from [192.168.3.158] (pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s571Og2B028386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 20:24:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66] claimed to be [192.168.3.158] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (11D201) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> Date: Fri, 6 Jun 2014 20:22:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <88A2E363-3CDD-45ED-AFB5-0134490B2E47@nostrum.com> References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> To: "Black, David" Archived-At: http://mailarchive.ietf.org/arch/msg/dart/krd_5L3T9HL3lgvG6A--tfa9BEE Cc: "dart@ietf.org" Subject: Re: [Dart] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 01:24:56 -0000 Thanks David! > On Jun 6, 2014, at 8:04 PM, "Black, David" wrote: >=20 > On behalf of the author team, here's an initial -00 draft for > consideration by the dart WG. Please keep in mind that this is a -00 > draft, so it really is a "draft". >=20 > I should be embarrassed that it appeared to take a public nudge from a > past IETF Chair (Harald) to get this draft to appear, (Aside: if you'd > like that ability, send your name to the NomCom this year - they're > always looking for interested candidates for all positions), but the > fact of the matter is that more than one of us had the experience of > life being what happens while one is busy making other plans. >=20 > Comments and feedback are welcome and encouraged. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org > Sent: Friday, June 06, 2014 8:49 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. >=20 >=20 > Title : Differentiated Services (DiffServ) and Real-time C= ommunication > Authors : Dan York > David Black > Cullen Jennings > Paul Jones > Filename : draft-york-dart-dscp-rtp-00.txt > Pages : 13 > Date : 2014-06-06 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based on > the Real-time Transport Protocol (RTP). DiffServ is based on network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As a > result, use of different DSCPs within a single traffic flow may cause > transport protocol interactions (e.g., due to reordering). In > addition, DSCP markings may be changed or removed between the traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Sun Jun 8 21:26:12 2014 Return-Path: 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 EAF971B27D6; Sun, 8 Jun 2014 21:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 FXZ_Z-bAxqaW; Sun, 8 Jun 2014 21:26:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBB91A04AE; Sun, 8 Jun 2014 21:26:06 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s594Q3u2096521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jun 2014 23:26:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell Date: Sun, 8 Jun 2014 23:26:02 -0500 X-Mao-Original-Outgoing-Id: 423980762.897201-b2645a7bb05615547ccbc722548e50af Content-Transfer-Encoding: quoted-printable Message-Id: <26D7D69F-FFA0-442A-B151-1ADCCC972717@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> To: rtcweb@ietf.org, clue@ietf.org, mmusic@ietf.org, avtcore@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/UTtPxbxq9SM8ZaboS5a0vbshyv0 Cc: dart@ietf.org Subject: [Dart] Fwd: I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 04:26:08 -0000 Hi, The referenced draft is a start for discussion on the implicat ions of = using different DiffServ treatments for packets in the same IP flow = (that is, share the same IP 5-tuple.) This will likely be of interest to = RTCWEB, MMUSIC, AVTCORE, CLUE and possibly other groups that contemplate = the bundling of multiple media streams on a single IP flow.=20 Please take discussion to the DART working group list (copied.) Thanks! Ben. Begin forwarded message: > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Friday, June 06, 2014 8:49 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Differentiated Services (DiffServ) and = Real-time Communication > Authors : Dan York > David Black > Cullen Jennings > Paul Jones > Filename : draft-york-dart-dscp-rtp-00.txt > Pages : 13 > Date : 2014-06-06 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based = on > the Real-time Transport Protocol (RTP). DiffServ is based on = network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As = a > result, use of different DSCPs within a single traffic flow may = cause > transport protocol interactions (e.g., due to reordering). In > addition, DSCP markings may be changed or removed between the = traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, = including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 >=20 From nobody Sun Jun 8 21:27:58 2014 Return-Path: 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 D0DDF1A0658; Sun, 8 Jun 2014 21:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 AS4M6j7O9I2U; Sun, 8 Jun 2014 21:27:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788ED1B27D8; Sun, 8 Jun 2014 21:27:52 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s594RnHa096677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jun 2014 23:27:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell Date: Sun, 8 Jun 2014 23:27:49 -0500 X-Mao-Original-Outgoing-Id: 423980869.043394-a908008ed14f8b0ffbca2ad324f4c0c2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> To: rtcweb@ietf.org, clue@ietf.org, mmusic@ietf.org, avt@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/BLZh_giDlqhKpwDA2xryEjoSJfk Cc: dart@ietf.org Subject: [Dart] Fwd: I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 04:27:54 -0000 [Resending with the correct address for avtcore. Apologies for the = repeat] Hi, The referenced draft is a start for discussion on the implicat ions of = using different DiffServ treatments for packets in the same IP flow = (that is, share the same IP 5-tuple.) This will likely be of interest to = RTCWEB, MMUSIC, AVTCORE, CLUE and possibly other groups that contemplate = the bundling of multiple media streams on a single IP flow.=20 Please take discussion to the DART working group list (copied.) Thanks! Ben. Begin forwarded message: > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Friday, June 06, 2014 8:49 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Differentiated Services (DiffServ) and = Real-time Communication > Authors : Dan York > David Black > Cullen Jennings > Paul Jones > Filename : draft-york-dart-dscp-rtp-00.txt > Pages : 13 > Date : 2014-06-06 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based on > the Real-time Transport Protocol (RTP). DiffServ is based on network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As a > result, use of different DSCPs within a single traffic flow may cause > transport protocol interactions (e.g., due to reordering). In > addition, DSCP markings may be changed or removed between the traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 >=20 From nobody Mon Jun 9 11:32:23 2014 Return-Path: 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 41BF61A029A for ; Mon, 9 Jun 2014 11:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, RP_MATCHES_RCVD=-0.651] 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 sFgQFactppHg for ; Mon, 9 Jun 2014 11:32:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0201A0294 for ; Mon, 9 Jun 2014 11:32:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s59IW8Fq075501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jun 2014 13:32:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell In-Reply-To: <5390A646.3080505@alum.mit.edu> Date: Mon, 9 Jun 2014 13:32:08 -0500 X-Mao-Original-Outgoing-Id: 424031528.040477-a21dfb7dd5293ef14749e8fd4b35f5cb Content-Transfer-Encoding: quoted-printable Message-Id: References: <53903308.60302@alvestrand.no> <7B19A8A3-EA07-47F5-8AD3-BE47D7E9881E@nostrum.com> <5390A646.3080505@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/qJfZ9HhnpY2srXOqIgjoH-X5VhE Cc: dart@ietf.org Subject: Re: [Dart] Test, please don't ignore X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:32:22 -0000 On Jun 5, 2014, at 12:17 PM, Paul Kyzivat wrote: > On 6/5/14 12:28 PM, Ben Campbell wrote: >>=20 >> On Jun 5, 2014, at 4:06 AM, Harald Alvestrand = wrote: >>=20 >>> The official DART archive shows four messages, reflecting the WG = review and WG approval. Nothing since April 22. >>>=20 >>> If there is a discussion elsewhere, please send the list a pointer. >>>=20 >>=20 >> There has been no discussion so far, other than between co-authors = working on a 00 draft. They expect to have that published shortly, then = hope to see real discussion happen on this list. >=20 > Who are the co-authors? >=20 The question is probably moot now, but the now available = "draft-york-dart-dscp-rtp-00" lists Dan York, David Black,Cullen = Jennings, and Paul Jones. Keep in mind this is not a "draft-ietf-dart-..." draft, at least not = yet. I hope to see some discussion on this draft before we consider = working group adoption. Thanks! Ben.= From nobody Tue Jun 10 01:19:10 2014 Return-Path: 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 490151A0271 for ; Tue, 10 Jun 2014 01:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 BN9gj6OLd0wn for ; Tue, 10 Jun 2014 01:19:07 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EF71A0011 for ; Tue, 10 Jun 2014 01:19:06 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 10 Jun 2014 10:18:17 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([10.134.99.16]) with mapi; Tue, 10 Jun 2014 10:18:16 +0200 From: To: Date: Tue, 10 Jun 2014 10:18:15 +0200 Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQAKMdosA= Message-ID: References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/JZv2Sv5ZGbElbNN708vMCt2dPKY Cc: dart@ietf.org Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:19:09 -0000 Hi David, thanks, your team created a well written draft.=20 If a MediaStream is carried in a RTP session, the text may also explicitely= say that=20 (it says MediaStreamTrack =3D=3D media flow, which is carried in an individ= ual RTP=20 packet stream) Is the following correct: UDP_5-tuple-+--transport protocol 1----- | +--RTP session 1----- | +--RTP session 2-----+---RTP_stream_2.1 | +---RTP_stream_2.2 |... This is impressive on first sight for a non-application expert. If the numb= er of RTP (and other transport) streams is high, I doubt that DiffServ is able to support more t= han rough=20 differentiation. DiffServ is designed to aggregate traffic of similar requi= rements. Fine grained=20 differentiation should be part of the application. The question coming to my mind is, whether your team can add a statement ho= w many AF classes are=20 useful to carry different RTP sessions within one UDP flow. I'd be happier = to live without a hen=20 and egg problem (meaning app developers to wait for the transport guys to p= rovide a set of=20 defined classes and transport guys waiting for app developers to demand a n= umber of defined=20 classes). Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Black, David Gesendet: Samstag, 7. Juni 2014 03:05 An: dart@ietf.org Betreff: [Dart] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt On behalf of the author team, here's an initial -00 draft for consideration= by the dart WG. Please keep in mind that this is a -00 draft, so it reall= y is a "draft". I should be embarrassed that it appeared to take a public nudge from a past= IETF Chair (Harald) to get this draft to appear, (Aside: if you'd like tha= t ability, send your name to the NomCom this year - they're always looking = for interested candidates for all positions), but the fact of the matter is= that more than one of us had the experience of life being what happens whi= le one is busy making other plans. Comments and feedback are welcome and encouraged. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, June 06, 2014 8:49 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Differentiated Services (DiffServ) and Real-time = Communication Authors : Dan York David Black Cullen Jennings Paul Jones Filename : draft-york-dart-dscp-rtp-00.txt Pages : 13 Date : 2014-06-06 Abstract: This document describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). As a result, use of different DSCPs within a single traffic flow may cause transport protocol interactions (e.g., due to reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This document covers the implications of these DiffServ aspects for real-time network communication, including RTCWEB. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Tue Jun 10 12:45:05 2014 Return-Path: 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 DE1D31A02A6 for ; Tue, 10 Jun 2014 12:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 vVbRVTuyEjwB for ; Tue, 10 Jun 2014 12:44:42 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B4C1A028E for ; Tue, 10 Jun 2014 12:44:41 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5AJidEL013744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 15:44:40 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s5AJidEL013744 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402429480; bh=8tvqN1wmMMsdTSVjip5tOjGjnqc=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=khOJZmBD978vnnufTLN8upmMmXHXDb2EfYywz0ylk2BT5eaXNGVMaa9QFox7lILlM DoBLDkT22f1R2ngV/qbctC9pbB6FYFOBZXQfY+4rHAp/r3kvKzLyXRlBxjgWooqTsx GNyN2xeFbnVyABk2cotHgqjH3Eql1U0rzPJ9PiGQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s5AJidEL013744 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 10 Jun 2014 15:44:24 -0400 Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5AJiNlO031362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 15:44:23 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Tue, 10 Jun 2014 15:44:23 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Tue, 10 Jun 2014 15:44:22 -0400 Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQAKMdosAAGlz6kA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/IU_tRWYXRij_8ubvoqnOsxiWB2k Cc: "dart@ietf.org" Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:44:45 -0000 Hi Ruediger, > thanks, your team created a well written draft. Great - thanks for taking a look. =20 > If a MediaStream is carried in a RTP session, the text may also explicite= ly > say that (it says MediaStreamTrack =3D=3D media flow, which is carried in= an > individual RTP packet stream) As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB, that would happen only when the MediaStream contains exactly one MediaStreamTrack. The use of these terms in bullet item 1 in section 2 is intended to be specific to RTCWEB, but we could add text elsewhere to point out that non-RTCWEB usage of MediaStreams could use an RTP packet stream for each Media Stream, independent of how many MediaStreamTracks each MediaStream contains. Could you suggest a reference that could be cited for usage of an RTP packet stream for each MediaStream independent of how many MediaStreamTracks each MediaStream contains? > Is the following correct: >=20 > UDP_5-tuple-+--transport protocol 1----- > | > +--RTP session 1----- > | > +--RTP session 2-----+---RTP_stream_2.1 > | > +---RTP_stream_2.2 > |... Yes, that matches my understanding, although the author team would like to see discussion of whether it's a good idea to mix RTP and non-RTP protocols on the same 5-tuple - I'll copy your useful diagram into a separate message to start that discussion. > The question coming to my mind is, whether your team can add a statement = how > many AF classes are useful to carry different RTP sessions within one UDP > flow. See draft-ietf-tsvwg-rtcweb-qos-00, which proposes to make all four AF classes available, so we can expect that someone will try to use all of them (and everything else in that draft). OTOH, we did put this warning text in at the end of Section 2.4 of draft-yo= rk: Backbone and other carrier networks may employ a small number of DSCPs (e.g., less than half a dozen) in order to manage a small number of traffic aggregates; hosts that use a larger number of DSCPs may find that much of the intended differentiation is removed by such networks. What additional text would you suggest that we add? Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Tuesday, June 10, 2014 4:18 AM > To: Black, David > Cc: dart@ietf.org > Subject: AW: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 > Hi David, >=20 > thanks, your team created a well written draft. >=20 > If a MediaStream is carried in a RTP session, the text may also explicite= ly say that > (it says MediaStreamTrack =3D=3D media flow, which is carried in an indiv= idual RTP > packet stream) >=20 > Is the following correct: >=20 > UDP_5-tuple-+--transport protocol 1----- > | > +--RTP session 1----- > | > +--RTP session 2-----+---RTP_stream_2.1 > | > +---RTP_stream_2.2 > |... >=20 > This is impressive on first sight for a non-application expert. If the nu= mber of RTP (and other > transport) streams is high, I doubt that DiffServ is able to support more= than rough > differentiation. DiffServ is designed to aggregate traffic of similar req= uirements. Fine grained > differentiation should be part of the application. >=20 > The question coming to my mind is, whether your team can add a statement = how many AF classes are > useful to carry different RTP sessions within one UDP flow. I'd be happie= r to live without a hen > and egg problem (meaning app developers to wait for the transport guys to= provide a set of > defined classes and transport guys waiting for app developers to demand a= number of defined > classes). >=20 > Regards, >=20 > Ruediger >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Black, David > Gesendet: Samstag, 7. Juni 2014 03:05 > An: dart@ietf.org > Betreff: [Dart] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 > On behalf of the author team, here's an initial -00 draft for considerati= on by > the dart WG. Please keep in mind that this is a -00 draft, so it really = is a > "draft". >=20 > I should be embarrassed that it appeared to take a public nudge from a pa= st > IETF Chair (Harald) to get this draft to appear, (Aside: if you'd like th= at > ability, send your name to the NomCom this year - they're always looking = for > interested candidates for all positions), but the fact of the matter is t= hat > more than one of us had the experience of life being what happens while o= ne is > busy making other plans. >=20 > Comments and feedback are welcome and encouraged. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, June 06, 2014 8:49 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Differentiated Services (DiffServ) and Real-tim= e > Communication > Authors : Dan York > David Black > Cullen Jennings > Paul Jones > Filename : draft-york-dart-dscp-rtp-00.txt > Pages : 13 > Date : 2014-06-06 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based on > the Real-time Transport Protocol (RTP). DiffServ is based on network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As a > result, use of different DSCPs within a single traffic flow may cause > transport protocol interactions (e.g., due to reordering). In > addition, DSCP markings may be changed or removed between the traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Tue Jun 10 12:59:49 2014 Return-Path: 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 DEC371A0332 for ; Tue, 10 Jun 2014 12:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 cMRppPyniorx for ; Tue, 10 Jun 2014 12:59:35 -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 844551A02D0 for ; Tue, 10 Jun 2014 12:59:35 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5AJxXYc023006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2014 15:59:34 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s5AJxXYc023006 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402430374; bh=gfDleUbKFhkWwqUGjs+3D8kB5QM=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jSmBV1Rei9Rji0XXNMPafHvjLh6ampgVJJA42UDsXvN6G3CTYompfJ6dSXLqvDIJS LGdXCsvLCq2oIYoUv1XKpusZt8MGVXf5jh+/z/qbMf1yIxEf8xvys7Vp5bzI4WTetE XBKGKQaU5wwARpS9NNaxZucjfA/m6On18IdMIizM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s5AJxXYc023006 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Tue, 10 Jun 2014 15:59:23 -0400 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5AJxNC1013514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2014 15:59:23 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Tue, 10 Jun 2014 15:59:23 -0400 From: "Black, David" To: "dart@ietf.org" Date: Tue, 10 Jun 2014 15:59:22 -0400 Thread-Topic: RTP and non-RTP traffic on same UDP 5-tuple Thread-Index: Ac+E5neWY1dI9dC3TZKJ9bELRV8OTQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/9uFrO3UhSQ0qAasCq4-Wkg9YrmE Cc: "Black, David" Subject: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:59:37 -0000 In another message, Ruediger Geib asked (>), and I responded: -------------------- > Is the following correct: >=20 > UDP_5-tuple-+--transport protocol 1----- > | > +--RTP session 1----- > | > +--RTP session 2-----+---RTP_stream_2.1 > | > +---RTP_stream_2.2 > |... Yes, that matches my understanding, although the author team would like to see discussion of whether it's a good idea to mix RTP and non-RTP protocols on the same 5-tuple - I'll copy your useful diagram into a separate message to start that discussion. -------------------- This is that message, and I want to thank Ruediger for drawing that useful diagram. The author team for draft-york would like input on whether the draft should discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, vs. usin= g separate 5-tuples (probably separate UDP ports) for RTP and non-RTP traffic= . RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the same 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb-transpor= ts-04: RTCWEB implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS_SRTP specification [RFC5764], section 5.1.2. All application layer protocol payloads over this DTLS connection are SCTP packets. OTOH, concerns have been expressed about whether the not-exactly-elegant demux processing specified in the reference (RFC 5764, Section 5.1.2) ought to be recommended as a good way of doing this multiplexing. Please comment, including whether mixing SCTP and RTP on the same UDP 5-tuple is a good idea (some rationale for doing this sort of multiplexing onto a single 5-tuple can be found in Section 3 of draft-york-dart-dscp-rtp= -00). Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Wed Jun 11 01:10:30 2014 Return-Path: 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 9C3071A04C5 for ; Wed, 11 Jun 2014 01:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 kUxGLMiU_UG1 for ; Wed, 11 Jun 2014 01:10:01 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249D61A0426 for ; Wed, 11 Jun 2014 01:10:00 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jun 2014 10:09:02 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 11 Jun 2014 10:08:56 +0200 From: To: Date: Wed, 11 Jun 2014 10:08:55 +0200 Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQAKMdosAAGlz6kAAWWTOQ Message-ID: References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/IAcP7dRLfwkS17J5zkKypymqDDM Cc: dart@ietf.org Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 08:10:06 -0000 Hi David, my responses start by "RG". Regards, Ruediger > If a MediaStream is carried in a RTP session, the text may also=20 > explicitely say that (it says MediaStreamTrack =3D=3D media flow, which = is=20 > carried in an individual RTP packet stream) DB: As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB,=20 DB: that would happen only when the MediaStream contains exactly one=20 DB: MediaStreamTrack. The use of these terms in bullet item 1 in=20 DB: section 2 is intended to be specific to RTCWEB, but we could add=20 DB: text elsewhere to point out that non-RTCWEB usage of MediaStreams=20 DB: could use an RTP packet stream for each Media Stream, independent=20 DB: of how many MediaStreamTracks each MediaStream contains. DB: Could you suggest a reference that could be cited for usage of an=20 DB: RTP packet stream for each MediaStream independent of how many=20 DB: MediaStreamTracks each MediaStream contains? RG> Sorry, I can't, that above was an assumption. I'd appreciate another=20 draft line explaining how MediaStream corresponds to RTP stream or=20 RTP session. > Is the following correct: >=20 > UDP_5-tuple-+--transport protocol 1----- > | > +--RTP session 1----- > | > +--RTP session 2-----+---RTP_stream_2.1 > | > +---RTP_stream_2.2 > |... [snip] DB: See draft-ietf-tsvwg-rtcweb-qos-00, which proposes to make all four AF= =20 DB: classes available, so we can expect that someone will try to use all=20 DB: of them (and everything else in that draft). DB: OTOH, we did put this warning text in at the end of Section 2.4 of draf= t-york: Backbone and other carrier networks may employ a small number of DSCPs (e.g., less than half a dozen) in order to manage a small number of traffic aggregates; hosts that use a larger number of DSCPs may find that much of the intended differentiation is removed by such networks. DB: What additional text would you suggest that we add? RG> tsvwg-rtcweb-qos offers 4 priorities which, following the definition gi= ven=20 there, are relevant to the browser (not to forwarding, as the draft doe= sn't=20 change existing standards on that). I'd expect priorities "very low" and "low" to be produced in one queue.= I'd=20 expect each AF class to be produced in one queue. So packet reordering = may=20 occur between different priorities. Type "data" requires 3 queues, if=20 produced as I'd assume. RG> Your draft is offering good QoS related guidance, and it's not only pro= vided by the=20 above section. I would appreciate a good explanation of what to expect = within=20 a single 5 tuple flow (a single application flow or multiple ones). I'd= =20 further appreciate, if all rtcweb related drafts in the transport area = clarify=20 the concepts they support related to rtcweb transport flow types. MF ba= sed=20 classification is one mode of DiffServ operation and it's important to = note=20 whether this is applicable in future or not. For the time being, applic= ation=20 servers aren't always marking flows and the above suggests, that they w= ill=20 have to mark packets within flows individually. RG> Finally, if the QoE suffers because code points interpreted as applicat= ion=20 priorities by browsers, which at the same time are interpreted as trans= port=20 QoS marks by routers which may be changed at network boundaries, then=20 DiffServ as a whole may have to be re-thought. To better understand tha= t=20 point, I've posted a mail on the tsvwg list. Regards, Ruediger From nobody Wed Jun 11 04:10:12 2014 Return-Path: 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 9B63B1B283B for ; Wed, 11 Jun 2014 04:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 IBdZ1QApDzfH for ; Wed, 11 Jun 2014 04:09:23 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 708391A0037 for ; Wed, 11 Jun 2014 04:09:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 00AA07C377A for ; Wed, 11 Jun 2014 13:09:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ertWi967C+z2 for ; Wed, 11 Jun 2014 13:09:19 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id C8F1A7C3773 for ; Wed, 11 Jun 2014 13:09:19 +0200 (CEST) Message-ID: <539838DF.8010506@alvestrand.no> Date: Wed, 11 Jun 2014 13:09:19 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dart@ietf.org References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/pmmdDQ1Kq2pz9SL1xuGEjg43emY Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 11:09:26 -0000 On 06/10/2014 09:44 PM, Black, David wrote: > Hi Ruediger, > >> thanks, your team created a well written draft. > Great - thanks for taking a look. > >> If a MediaStream is carried in a RTP session, the text may also explicitely >> say that (it says MediaStreamTrack == media flow, which is carried in an >> individual RTP packet stream) > As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB, > that would happen only when the MediaStream contains exactly one > MediaStreamTrack. The use of these terms in bullet item 1 in section 2 > is intended to be specific to RTCWEB, but we could add text elsewhere to > point out that non-RTCWEB usage of MediaStreams could use an RTP packet > stream for each Media Stream, independent of how many MediaStreamTracks > each MediaStream contains. > > Could you suggest a reference that could be cited for usage of an RTP > packet stream for each MediaStream independent of how many > MediaStreamTracks each MediaStream contains? Careful - "RTP packet stream" is one of those concepts that can be meaningless without citing a specific definition. draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference at the moment. It says this about "Packet stream": 2.1.10. Packet Stream A stream of RTP packets containing media data, source or redundant. The Packet Stream is identified by an SSRC belonging to a particular RTP session. The RTP session is identified as discussed in Section 2.2.2. Under this definition, it's impossible to put more than one MediaStreamTrack into a packet stream. In a lot of cases (FEC, redundancy, SVC, simulcast), there will be multiple RTP packet streams associated with one MediaStreamTrack. The term is used only once in the draft, but unfortunately defines a new term to mean the same thing: The most common protocol used for real time media is the Real-Time Transport Protocol (RTP)[RFC3550]. RTP defines the mechanism by which real-time data is transmitted between hosts on the Internet. With most applications, a single media type (e.g., audio) is transmitted within a single RTP session. However, it is possible to transmit multiple, distinct media flows over the same RTP session as individual RTP packet streams. This is referred to as RTP multiplexing. For the purposes of this draft, the term "media flow" refers to a sequence of packets that is transmitted as a single RTP packet stream. The term "media flow" doesn't sound to me like a good term to use for this concept. Would the authors be willing to consider switching to "packet stream"? From nobody Wed Jun 11 07:11:13 2014 Return-Path: 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 79B2B1A0371 for ; Wed, 11 Jun 2014 07:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 GNFIf2UDh5wd for ; Wed, 11 Jun 2014 07:11:08 -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 8BFBA1A013B for ; Wed, 11 Jun 2014 07:11:08 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5BEB1WL029077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 10:11:03 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s5BEB1WL029077 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402495863; bh=VN0RQrQTe144EfrrglPKcQ+ifV4=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Yw695WC+gkufDMLTrF78LVh8szCVB1JJqMagj7Oc+CsIisqZ3+uvneRkamtSxRjVl PT7uExCoFvXhlVg6RsttzStQnk/J8cntg0CRkzldoe+kSQx2k/2IIWZIQUIaY3Z8UB N9YtlqFeb85bAE0MezqnHhL5vVzBy38plsPMHMgI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s5BEB1WL029077 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor); Wed, 11 Jun 2014 07:10:52 -0700 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5BEAlV0014760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 10:10:51 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 11 Jun 2014 10:10:46 -0400 From: "Black, David" To: Harald Alvestrand , "dart@ietf.org" Date: Wed, 11 Jun 2014 10:10:45 -0400 Thread-Topic: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+FZb1gImtXlFIcSDm/o2L3fvQJ1wAF3uCw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD347BC@MX15A.corp.emc.com> References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> <539838DF.8010506@alvestrand.no> In-Reply-To: <539838DF.8010506@alvestrand.no> 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: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/wtMm_ERoO5MUavk9tjEJzo_RS5A Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:11:11 -0000 Harald, > Careful - "RTP packet stream" is one of those concepts that can be > meaningless without citing a specific definition. +1 > draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference > at the moment. It says this about "Packet stream": Thank you for the pointer, we'll be happy to cite and use that definition. > For the purposes of this draft, the term "media flow" refers to a > sequence of packets that is transmitted as a single RTP packet > stream. >=20 > The term "media flow" doesn't sound to me like a good term to use for thi= s concept. > Would the authors be willing to consider switching to "packet stream"? Speaking only for myself, I don't think so, because there are two different concepts involved - IMHO, this draft needs two terms to refer to: a) What the application sends. b) How RTP carries that traffic. "RTP packet stream" is clearly the right RTP term for the latter, and the draft was written that way. I would've liked to have used "media stream" for the former, but W3C has defined MediaStream to not be a single stream of media (go figure ...). "media flow" seemed to be as good a term as any for that concept, and "media flow" is already used for that concept in draft-ietf-tsvwg-rtcweb-qos (i.e., it was not invented for this draft). If you have an alternative term, please suggest it ... and then the authors of any other draft that uses "media flow" (starting w/the rtcweb-qos draft) will have to go make corresponding changes. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Wednesday, June 11, 2014 7:09 AM > To: dart@ietf.org > Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 > On 06/10/2014 09:44 PM, Black, David wrote: > > Hi Ruediger, > > > >> thanks, your team created a well written draft. > > Great - thanks for taking a look. > > > >> If a MediaStream is carried in a RTP session, the text may also explic= itely > >> say that (it says MediaStreamTrack =3D=3D media flow, which is carried= in an > >> individual RTP packet stream) > > As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB, > > that would happen only when the MediaStream contains exactly one > > MediaStreamTrack. The use of these terms in bullet item 1 in section 2 > > is intended to be specific to RTCWEB, but we could add text elsewhere t= o > > point out that non-RTCWEB usage of MediaStreams could use an RTP packet > > stream for each Media Stream, independent of how many MediaStreamTracks > > each MediaStream contains. > > > > Could you suggest a reference that could be cited for usage of an RTP > > packet stream for each MediaStream independent of how many > > MediaStreamTracks each MediaStream contains? >=20 > Careful - "RTP packet stream" is one of those concepts that can be > meaningless without citing a specific definition. >=20 > draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference > at the moment. It says this about "Packet stream": >=20 > 2.1.10. Packet Stream >=20 > A stream of RTP packets containing media data, source or redundant. > The Packet Stream is identified by an SSRC belonging to a particular > RTP session. The RTP session is identified as discussed in > Section 2.2.2. >=20 > Under this definition, it's impossible to put more than one > MediaStreamTrack into a packet stream. > In a lot of cases (FEC, redundancy, SVC, simulcast), there will be > multiple RTP packet streams associated with one MediaStreamTrack. >=20 > The term is used only once in the draft, but unfortunately defines a new > term to mean the same thing: >=20 > The most common protocol used for real time media is the Real-Time > Transport Protocol (RTP)[RFC3550]. RTP defines the mechanism by > which real-time data is transmitted between hosts on the Internet. > With most applications, a single media type (e.g., audio) is > transmitted within a single RTP session. However, it is possible to > transmit multiple, distinct media flows over the same RTP session as > individual RTP packet streams. This is referred to as RTP > multiplexing. >=20 > For the purposes of this draft, the term "media flow" refers to a > sequence of packets that is transmitted as a single RTP packet > stream. >=20 > The term "media flow" doesn't sound to me like a good term to use for > this concept. > Would the authors be willing to consider switching to "packet stream"? >=20 >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Wed Jun 11 07:22:04 2014 Return-Path: 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 4B40F1A0649 for ; Wed, 11 Jun 2014 07:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 TI3AgVLoQMAj for ; Wed, 11 Jun 2014 07:21:57 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id A49851A0601 for ; Wed, 11 Jun 2014 07:21:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B56637C3780 for ; Wed, 11 Jun 2014 16:21:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrJFZFWrTnxo for ; Wed, 11 Jun 2014 16:21:54 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9E54E7C375C for ; Wed, 11 Jun 2014 16:21:54 +0200 (CEST) Message-ID: <53986602.1050204@alvestrand.no> Date: Wed, 11 Jun 2014 16:21:54 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dart@ietf.org References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> <539838DF.8010506@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712076FD347BC@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD347BC@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/-p4V-hEIhAwhEnYBdIRIQcN_3yU Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:22:03 -0000 On 06/11/2014 04:10 PM, Black, David wrote: > Harald, > >> Careful - "RTP packet stream" is one of those concepts that can be >> meaningless without citing a specific definition. > +1 > >> draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference >> at the moment. It says this about "Packet stream": > Thank you for the pointer, we'll be happy to cite and use that definition. > >> For the purposes of this draft, the term "media flow" refers to a >> sequence of packets that is transmitted as a single RTP packet >> stream. >> >> The term "media flow" doesn't sound to me like a good term to use for this concept. >> Would the authors be willing to consider switching to "packet stream"? > Speaking only for myself, I don't think so, because there are two > different concepts involved - IMHO, this draft needs two terms to refer to: > > a) What the application sends. > b) How RTP carries that traffic. > > "RTP packet stream" is clearly the right RTP term for the latter, and the > draft was written that way. I would've liked to have used "media stream" > for the former, but W3C has defined MediaStream to not be a single stream > of media (go figure ...). "media flow" seemed to be as good a term as > any for that concept, and "media flow" is already used for that concept > in draft-ietf-tsvwg-rtcweb-qos (i.e., it was not invented for this draft). Yes - except that every time it's used in draft-york, including in the place it is defined, it means "RTP packet stream". If you are trying to use it for the stuff that's inside the RTP packets instead of the RTP packet streams, the definition needs to say so. "Media source" is the term I think you're thinking of in -taxonomy- that corresponds more closely to the term - the complexifier is all the cases where a single media source is carried over multiple packet streams. > > If you have an alternative term, please suggest it ... and then the authors > of any other draft that uses "media flow" (starting w/the rtcweb-qos draft) > will have to go make corresponding changes. > > Thanks, > --David > >> -----Original Message----- >> From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: Wednesday, June 11, 2014 7:09 AM >> To: dart@ietf.org >> Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt >> >> On 06/10/2014 09:44 PM, Black, David wrote: >>> Hi Ruediger, >>> >>>> thanks, your team created a well written draft. >>> Great - thanks for taking a look. >>> >>>> If a MediaStream is carried in a RTP session, the text may also explicitely >>>> say that (it says MediaStreamTrack == media flow, which is carried in an >>>> individual RTP packet stream) >>> As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB, >>> that would happen only when the MediaStream contains exactly one >>> MediaStreamTrack. The use of these terms in bullet item 1 in section 2 >>> is intended to be specific to RTCWEB, but we could add text elsewhere to >>> point out that non-RTCWEB usage of MediaStreams could use an RTP packet >>> stream for each Media Stream, independent of how many MediaStreamTracks >>> each MediaStream contains. >>> >>> Could you suggest a reference that could be cited for usage of an RTP >>> packet stream for each MediaStream independent of how many >>> MediaStreamTracks each MediaStream contains? >> Careful - "RTP packet stream" is one of those concepts that can be >> meaningless without citing a specific definition. >> >> draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference >> at the moment. It says this about "Packet stream": >> >> 2.1.10. Packet Stream >> >> A stream of RTP packets containing media data, source or redundant. >> The Packet Stream is identified by an SSRC belonging to a particular >> RTP session. The RTP session is identified as discussed in >> Section 2.2.2. >> >> Under this definition, it's impossible to put more than one >> MediaStreamTrack into a packet stream. >> In a lot of cases (FEC, redundancy, SVC, simulcast), there will be >> multiple RTP packet streams associated with one MediaStreamTrack. >> >> The term is used only once in the draft, but unfortunately defines a new >> term to mean the same thing: >> >> The most common protocol used for real time media is the Real-Time >> Transport Protocol (RTP)[RFC3550]. RTP defines the mechanism by >> which real-time data is transmitted between hosts on the Internet. >> With most applications, a single media type (e.g., audio) is >> transmitted within a single RTP session. However, it is possible to >> transmit multiple, distinct media flows over the same RTP session as >> individual RTP packet streams. This is referred to as RTP >> multiplexing. >> >> For the purposes of this draft, the term "media flow" refers to a >> sequence of packets that is transmitted as a single RTP packet >> stream. >> >> The term "media flow" doesn't sound to me like a good term to use for >> this concept. >> Would the authors be willing to consider switching to "packet stream"? >> >> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Wed Jun 11 07:43:52 2014 Return-Path: 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 204251A0151 for ; Wed, 11 Jun 2014 07:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 Zqr15-oqTKt8 for ; Wed, 11 Jun 2014 07:43:41 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29091A0141 for ; Wed, 11 Jun 2014 07:43:36 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5BEhVjh001895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 10:43:33 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s5BEhVjh001895 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402497813; bh=QxGAHO+n3bTFCtiB3lqT6EUKyH0=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=FF0iBbUYrG5En3gKHuYU/gItbXnANywXAWO0K2EgCqqT8pl/iM7Z6FAavAURX3Fw/ G5+51nSBpYnYH0PQoZkZHiW0HWBy3ywiNxtyW6yPXKqgVrPowZRAVAW26aWNeFYWp3 M6BPoFL/56c7meR0HxYx+l2NTc5TJmtLo90tL1aM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s5BEhVjh001895 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 11 Jun 2014 10:43:26 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5BEhO07001833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 10:43:25 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Wed, 11 Jun 2014 10:43:24 -0400 From: "Black, David" To: Harald Alvestrand , "dart@ietf.org" Date: Wed, 11 Jun 2014 10:43:22 -0400 Thread-Topic: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+FgIn4WFr30uaCTw62XHdxL5TcgAAAlo0w Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD347E3@MX15A.corp.emc.com> References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> <539838DF.8010506@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712076FD347BC@MX15A.corp.emc.com> <53986602.1050204@alvestrand.no> In-Reply-To: <53986602.1050204@alvestrand.no> 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: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/PwJs8JCB2rNYlD1O8lUAkqhEA3Q Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:43:46 -0000 > Yes - except that every time it's used in draft-york, including in the > place it is defined, it means "RTP packet stream". If you are trying to > use it for the stuff that's inside the RTP packets instead of the RTP > packet streams, the definition needs to say so. Ok, will try to clarify - I'll put this on the list of things to do in the -01 version, including making sure it lines up well with the rtcweb-qos draft. > "Media source" is the term I think you're thinking of in -taxonomy- that > corresponds more closely to the term - the complexifier is all the cases > where a single media source is carried over multiple packet streams. IMHO, "Media source" sounds like the sender, not what is sent. MediaStream seems to be a term for that what is sent that could be carried as multiple RTP packet streams. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Wednesday, June 11, 2014 10:22 AM > To: dart@ietf.org > Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 > On 06/11/2014 04:10 PM, Black, David wrote: > > Harald, > > > >> Careful - "RTP packet stream" is one of those concepts that can be > >> meaningless without citing a specific definition. > > +1 > > > >> draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference > >> at the moment. It says this about "Packet stream": > > Thank you for the pointer, we'll be happy to cite and use that definiti= on. > > > >> For the purposes of this draft, the term "media flow" refers to a > >> sequence of packets that is transmitted as a single RTP packet > >> stream. > >> > >> The term "media flow" doesn't sound to me like a good term to use for = this > concept. > >> Would the authors be willing to consider switching to "packet stream"? > > Speaking only for myself, I don't think so, because there are two > > different concepts involved - IMHO, this draft needs two terms to refer= to: > > > > a) What the application sends. > > b) How RTP carries that traffic. > > > > "RTP packet stream" is clearly the right RTP term for the latter, and t= he > > draft was written that way. I would've liked to have used "media strea= m" > > for the former, but W3C has defined MediaStream to not be a single stre= am > > of media (go figure ...). "media flow" seemed to be as good a term as > > any for that concept, and "media flow" is already used for that concept > > in draft-ietf-tsvwg-rtcweb-qos (i.e., it was not invented for this draf= t). > Yes - except that every time it's used in draft-york, including in the > place it is defined, it means "RTP packet stream". If you are trying to > use it for the stuff that's inside the RTP packets instead of the RTP > packet streams, the definition needs to say so. >=20 > "Media source" is the term I think you're thinking of in -taxonomy- that > corresponds more closely to the term - the complexifier is all the cases > where a single media source is carried over multiple packet streams. >=20 > > > > If you have an alternative term, please suggest it ... and then the aut= hors > > of any other draft that uses "media flow" (starting w/the rtcweb-qos dr= aft) > > will have to go make corresponding changes. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Harald Alvestra= nd > >> Sent: Wednesday, June 11, 2014 7:09 AM > >> To: dart@ietf.org > >> Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt > >> > >> On 06/10/2014 09:44 PM, Black, David wrote: > >>> Hi Ruediger, > >>> > >>>> thanks, your team created a well written draft. > >>> Great - thanks for taking a look. > >>> > >>>> If a MediaStream is carried in a RTP session, the text may also > explicitely > >>>> say that (it says MediaStreamTrack =3D=3D media flow, which is carri= ed in an > >>>> individual RTP packet stream) > >>> As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB, > >>> that would happen only when the MediaStream contains exactly one > >>> MediaStreamTrack. The use of these terms in bullet item 1 in section= 2 > >>> is intended to be specific to RTCWEB, but we could add text elsewhere= to > >>> point out that non-RTCWEB usage of MediaStreams could use an RTP pack= et > >>> stream for each Media Stream, independent of how many MediaStreamTrac= ks > >>> each MediaStream contains. > >>> > >>> Could you suggest a reference that could be cited for usage of an RTP > >>> packet stream for each MediaStream independent of how many > >>> MediaStreamTracks each MediaStream contains? > >> Careful - "RTP packet stream" is one of those concepts that can be > >> meaningless without citing a specific definition. > >> > >> draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference > >> at the moment. It says this about "Packet stream": > >> > >> 2.1.10. Packet Stream > >> > >> A stream of RTP packets containing media data, source or redundan= t. > >> The Packet Stream is identified by an SSRC belonging to a particu= lar > >> RTP session. The RTP session is identified as discussed in > >> Section 2.2.2. > >> > >> Under this definition, it's impossible to put more than one > >> MediaStreamTrack into a packet stream. > >> In a lot of cases (FEC, redundancy, SVC, simulcast), there will be > >> multiple RTP packet streams associated with one MediaStreamTrack. > >> > >> The term is used only once in the draft, but unfortunately defines a n= ew > >> term to mean the same thing: > >> > >> The most common protocol used for real time media is the Real-Tim= e > >> Transport Protocol (RTP)[RFC3550]. RTP defines the mechanism by > >> which real-time data is transmitted between hosts on the Internet= . > >> With most applications, a single media type (e.g., audio) is > >> transmitted within a single RTP session. However, it is possible= to > >> transmit multiple, distinct media flows over the same RTP session= as > >> individual RTP packet streams. This is referred to as RTP > >> multiplexing. > >> > >> For the purposes of this draft, the term "media flow" refers to a > >> sequence of packets that is transmitted as a single RTP packet > >> stream. > >> > >> The term "media flow" doesn't sound to me like a good term to use for > >> this concept. > >> Would the authors be willing to consider switching to "packet stream"? > >> > >> > >> _______________________________________________ > >> Dart mailing list > >> Dart@ietf.org > >> https://www.ietf.org/mailman/listinfo/dart > > _______________________________________________ > > Dart mailing list > > Dart@ietf.org > > https://www.ietf.org/mailman/listinfo/dart >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Wed Jun 11 13:42:57 2014 Return-Path: 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 1BCBE1A029D for ; Wed, 11 Jun 2014 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 OnQWQb5Ew4v4 for ; Wed, 11 Jun 2014 13:42:53 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD0E1A0298 for ; Wed, 11 Jun 2014 13:42:53 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id um1so192752pbc.18 for ; Wed, 11 Jun 2014 13:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2oFnMkdT7sjAoJXK49HzvmqwJNlM5dqJyAARLkQQeL4=; b=WWrUEot9NRpPR8DkCTYlX3kQrki7MlVn0C1JuAEhRx9U7rhNjhBi3txQr+qzJTToyA vyVGcIwfCJU7qrsYSgsYvcVLk/pactb5CInlsZsMLyx7c97nSmwhN0iXBYmHF3d3Etqt 9dHDctaanq914zKhZbkYRLYLZGT+SbM/TgLL/kJX5lupued+cIMrvUqaiqrz6hFVBS+B JyNOiI8H1T72w8OT5DgwxVPRI+YnxG8+YUTyqItj14sg+4YJX2YGHUn9PDct19B5VCeg rsjDBGfa9GbpfobjRwTaptbmIAfjR9AnfaCrpYKD6rWFJtvFDePBEBHSkP+4bYpYZhwY yCCA== X-Received: by 10.66.231.237 with SMTP id tj13mr16458075pac.136.1402519372814; Wed, 11 Jun 2014 13:42:52 -0700 (PDT) Received: from [192.168.178.23] (68.195.69.111.dynamic.snap.net.nz. [111.69.195.68]) by mx.google.com with ESMTPSA id is5sm76638191pbb.8.2014.06.11.13.42.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 13:42:52 -0700 (PDT) Message-ID: <5398BF50.5040604@gmail.com> Date: Thu, 12 Jun 2014 08:42:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/DbJTNRcq3rDS1zj2LMS2Q0e4WnE Cc: "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 20:42:55 -0000 On 11/06/2014 07:59, Black, David wrote: > In another message, Ruediger Geib asked (>), and I responded: > > -------------------- > >> Is the following correct: >> >> UDP_5-tuple-+--transport protocol 1----- >> | >> +--RTP session 1----- >> | >> +--RTP session 2-----+---RTP_stream_2.1 >> | >> +---RTP_stream_2.2 >> |... > > Yes, that matches my understanding, although the author team would like to > see discussion of whether it's a good idea to mix RTP and non-RTP protocols > on the same 5-tuple - I'll copy your useful diagram into a separate message > to start that discussion. > > -------------------- > > This is that message, and I want to thank Ruediger for drawing that useful > diagram. > > The author team for draft-york would like input on whether the draft should > discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, vs. using > separate 5-tuples (probably separate UDP ports) for RTP and non-RTP traffic. One observation is that we should be thinking about a 6-tuple these days (see RFC 6437). I don't think it makes much difference to the argument. Another observation is when load balancing is in play, things get a bit more complicated, but to a first approximation using the same 5-tuple or 6-tuple will usually ensure that all the packets reach the same load-balanced destination, which is probably a good thing. Third, reverting to the diffserv discussion, the same 5-tuple should ensure that all the packets would be classified the same (if they cross a diffserv domain boundary and get reclassified). Brian > > RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the same > 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb-transports-04: > > RTCWEB implementations MUST support multiplexing of DTLS and RTP over > the same port pair, as described in the DTLS_SRTP specification > [RFC5764], section 5.1.2. All application layer protocol payloads > over this DTLS connection are SCTP packets. > > OTOH, concerns have been expressed about whether the not-exactly-elegant > demux processing specified in the reference (RFC 5764, Section 5.1.2) ought > to be recommended as a good way of doing this multiplexing. > > Please comment, including whether mixing SCTP and RTP on the same UDP > 5-tuple is a good idea (some rationale for doing this sort of multiplexing > onto a single 5-tuple can be found in Section 3 of draft-york-dart-dscp-rtp-00). > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart > From nobody Wed Jun 11 17:32:22 2014 Return-Path: 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 8AF241B28FC for ; Wed, 11 Jun 2014 17:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 CLBGQNjspNlA for ; Wed, 11 Jun 2014 17:32:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCAE1B28F0 for ; Wed, 11 Jun 2014 17:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3898; q=dns/txt; s=iport; t=1402533138; x=1403742738; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EcUgau9UatxmefnYwAoO5YWMDhjwYDvHtY1vqCb1gGQ=; b=iGMNU7203ppLDm3bM3kQ/99Fx8UXluBTOwBMeaSOhR1roCqelyD8xoJy nsMbQt9jsFrNLcWsjMdtGOPxaOlTmu4NER7D+SW9I8BqotWs8WYSGdpdH QX7KEN1sODqH9Qyu9lHBoCg9uh+QMRnfZcz6D5TF1meNB/wdnKtrzeoZo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMFAKfzmFOtJV2U/2dsb2JhbABXA4MNUlapQwEBAQEBAQUBkV+HPAGBCBZ1hAMBAQEDAQEBATcrCQsFCwsYLiEGMAYTiC4DCQgNygcNhhMTBIVchlqBQDAjEAcRgxqBFgSJR3KNfIF5hnaGWoV7g1wdLw X-IronPort-AV: E=Sophos;i="5.01,461,1400025600"; d="scan'208";a="332553962" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP; 12 Jun 2014 00:32:17 +0000 Received: from [10.21.103.3] ([10.21.103.3]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5C0WH0q025228; Thu, 12 Jun 2014 00:32:17 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dan Wing In-Reply-To: <5398BF50.5040604@gmail.com> Date: Wed, 11 Jun 2014 17:32:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/TDTyX7dTuarXI5NBk2nnn2kLUFk Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 00:32:20 -0000 On Jun 11, 2014, at 1:42 PM, Brian E Carpenter = wrote: > On 11/06/2014 07:59, Black, David wrote: >> In another message, Ruediger Geib asked (>), and I responded: >>=20 >> -------------------- >>=20 >>> Is the following correct: >>>=20 >>> UDP_5-tuple-+--transport protocol 1----- >>> | >>> +--RTP session 1----- >>> | >>> +--RTP session 2-----+---RTP_stream_2.1 >>> | >>> +---RTP_stream_2.2 >>> |... >>=20 >> Yes, that matches my understanding, although the author team would = like to >> see discussion of whether it's a good idea to mix RTP and non-RTP = protocols >> on the same 5-tuple - I'll copy your useful diagram into a separate = message >> to start that discussion. >>=20 >> -------------------- >>=20 >> This is that message, and I want to thank Ruediger for drawing that = useful >> diagram. >>=20 >> The author team for draft-york would like input on whether the draft = should >> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, = vs. using >> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP = traffic. >=20 > One observation is that we should be thinking about a 6-tuple these > days (see RFC 6437). I don't think it makes much difference to the = argument. >=20 > Another observation is when load balancing is in play, things get a = bit > more complicated, but to a first approximation using the same 5-tuple > or 6-tuple will usually ensure that all the packets reach the same > load-balanced destination, which is probably a good thing. >=20 > Third, reverting to the diffserv discussion, the same 5-tuple > should ensure that all the packets would be classified the same > (if they cross a diffserv domain boundary and get reclassified). What do you mean by 'all the packets would be classified the same'? If = you mean all the packets in a 5-tuple would get the same differentiated = treatment, that is not desirable, because there are lots of folks = wanting to send video i-frames or packets with FEC or other stuff with = lower drop precedence than other packets. -d >=20 > Brian >=20 >>=20 >> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the = same >> 5-tuple see the last paragraph of Section 3.5 of = draft-ietf-rtcweb-transports-04: >>=20 >> RTCWEB implementations MUST support multiplexing of DTLS and RTP = over >> the same port pair, as described in the DTLS_SRTP specification >> [RFC5764], section 5.1.2. All application layer protocol payloads >> over this DTLS connection are SCTP packets. >>=20 >> OTOH, concerns have been expressed about whether the = not-exactly-elegant >> demux processing specified in the reference (RFC 5764, Section 5.1.2) = ought >> to be recommended as a good way of doing this multiplexing. >>=20 >> Please comment, including whether mixing SCTP and RTP on the same UDP >> 5-tuple is a good idea (some rationale for doing this sort of = multiplexing >> onto a single 5-tuple can be found in Section 3 of = draft-york-dart-dscp-rtp-00). >>=20 >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >>=20 >>=20 >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart >>=20 >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Wed Jun 11 17:58:29 2014 Return-Path: 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 0CB181B291C for ; Wed, 11 Jun 2014 17:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 krsUx9shc-yY for ; Wed, 11 Jun 2014 17:58:25 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11AB1B291B for ; Wed, 11 Jun 2014 17:58:24 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C0wMjg026916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 20:58:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s5C0wMjg026916 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402534702; bh=t8AWShyR5gIeL8VmFJDp/II7EuI=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KQEgKTvFZ+Of87tBr6SpJ9ow27yx933mRDROcuwaHcIj0fyKz/wclwHByRaISTUH3 rdg3l7GZCIAl0gEIornis75ElbdjmWhUbzzP17hvrrZpzbgWVAF585e2AAuPD/BaSq XMHUQ7GwrPFrqE+oMtNqzxrAEB9RWakod/OMRarg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s5C0wMjg026916 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 11 Jun 2014 20:58:05 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C0w5vd010744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 20:58:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Wed, 11 Jun 2014 20:58:05 -0400 From: "Black, David" To: Dan Wing Date: Wed, 11 Jun 2014 20:58:01 -0400 Thread-Topic: [Dart] RTP and non-RTP traffic on same UDP 5-tuple Thread-Index: Ac+F1ccOpgg5pb3yTwm0Q/a3uaAIBAAApt0Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> In-Reply-To: <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.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: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/B3jruYUPrtwRtSASa6kRtt4sNII Cc: "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 00:58:28 -0000 > What do you mean by 'all the packets would be classified the same'? If y= ou > mean all the packets in a 5-tuple would get the same differentiated treat= ment, > that is not desirable, because there are lots of folks wanting to send vi= deo > i-frames or packets with FEC or other stuff with lower drop precedence th= an > other packets. That would most likely be within an AF class; the entire set of packets mar= ked w/different drop precedences within an AF class should be classified the sa= me. Beyond that, one can hope that any AF remarker (e.g., for traffic shaping) = is running in Color-Aware mode and hence tries to preserve source drop precede= nce distinctions, but this cannot be relied upon. Thanks, --David > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, June 11, 2014 8:32 PM > To: Brian E Carpenter > Cc: Black, David; dart@ietf.org > Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >=20 >=20 > On Jun 11, 2014, at 1:42 PM, Brian E Carpenter > wrote: >=20 > > On 11/06/2014 07:59, Black, David wrote: > >> In another message, Ruediger Geib asked (>), and I responded: > >> > >> -------------------- > >> > >>> Is the following correct: > >>> > >>> UDP_5-tuple-+--transport protocol 1----- > >>> | > >>> +--RTP session 1----- > >>> | > >>> +--RTP session 2-----+---RTP_stream_2.1 > >>> | > >>> +---RTP_stream_2.2 > >>> |... > >> > >> Yes, that matches my understanding, although the author team would lik= e to > >> see discussion of whether it's a good idea to mix RTP and non-RTP prot= ocols > >> on the same 5-tuple - I'll copy your useful diagram into a separate me= ssage > >> to start that discussion. > >> > >> -------------------- > >> > >> This is that message, and I want to thank Ruediger for drawing that us= eful > >> diagram. > >> > >> The author team for draft-york would like input on whether the draft s= hould > >> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, vs. > using > >> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP > traffic. > > > > One observation is that we should be thinking about a 6-tuple these > > days (see RFC 6437). I don't think it makes much difference to the argu= ment. > > > > Another observation is when load balancing is in play, things get a bit > > more complicated, but to a first approximation using the same 5-tuple > > or 6-tuple will usually ensure that all the packets reach the same > > load-balanced destination, which is probably a good thing. > > > > Third, reverting to the diffserv discussion, the same 5-tuple > > should ensure that all the packets would be classified the same > > (if they cross a diffserv domain boundary and get reclassified). >=20 > What do you mean by 'all the packets would be classified the same'? If y= ou > mean all the packets in a 5-tuple would get the same differentiated treat= ment, > that is not desirable, because there are lots of folks wanting to send vi= deo > i-frames or packets with FEC or other stuff with lower drop precedence th= an > other packets. >=20 > -d >=20 >=20 > > > > Brian > > > >> > >> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the s= ame > >> 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb- > transports-04: > >> > >> RTCWEB implementations MUST support multiplexing of DTLS and RTP ove= r > >> the same port pair, as described in the DTLS_SRTP specification > >> [RFC5764], section 5.1.2. All application layer protocol payloads > >> over this DTLS connection are SCTP packets. > >> > >> OTOH, concerns have been expressed about whether the not-exactly-elega= nt > >> demux processing specified in the reference (RFC 5764, Section 5.1.2) = ought > >> to be recommended as a good way of doing this multiplexing. > >> > >> Please comment, including whether mixing SCTP and RTP on the same UDP > >> 5-tuple is a good idea (some rationale for doing this sort of multiple= xing > >> onto a single 5-tuple can be found in Section 3 of draft-york-dart-dsc= p- > rtp-00). > >> > >> Thanks, > >> --David > >> ---------------------------------------------------- > >> David L. Black, Distinguished Engineer > >> EMC Corporation, 176 South St., Hopkinton, MA 01748 > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >> david.black@emc.com Mobile: +1 (978) 394-7754 > >> ---------------------------------------------------- > >> > >> > >> _______________________________________________ > >> Dart mailing list > >> Dart@ietf.org > >> https://www.ietf.org/mailman/listinfo/dart > >> > > > > _______________________________________________ > > Dart mailing list > > Dart@ietf.org > > https://www.ietf.org/mailman/listinfo/dart From nobody Wed Jun 11 18:39:03 2014 Return-Path: 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 6C8E81B294B for ; Wed, 11 Jun 2014 18:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 WguMfIuMafeV for ; Wed, 11 Jun 2014 18:38:58 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764121B2946 for ; Wed, 11 Jun 2014 18:38:58 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id kq14so423804pab.0 for ; Wed, 11 Jun 2014 18:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kmuV+hrOPQUbMp4+o/mV2sNAJ6+F9Ob+TbhDZAt/jHw=; b=ng4n8JuJuhOeMt97GprMdaQ2AtxD2NUwUKkb6TlwTVS0QAzR+fVjx3nZu+r7L2aYAF f9c/MAPKMj/9qq0Ut1BiB0VJ8746vqZJ+osQ822ncBIbqjpB8vpQxtTE7orQahmdD2ou /xZwckf5T1kqK7C0Dv1KysORRZJ5Biz2DqNFKpNAxCYOTDvMKdqpA/FM+ALIrgJDk+Kd iWbvdg/tVsFNE/hbldMlV+sPrdPyZ555lHvbAEDysIOqXBDz94Ne9T/KyzSxg8XjxpHL yir5jA47iAvZUoui5sOJM09Tp4VjZLontxvYVpT0QEEPA5GGSk/HtuiaawS1T95JYdFr M9cg== X-Received: by 10.68.189.137 with SMTP id gi9mr9214969pbc.79.1402537138013; Wed, 11 Jun 2014 18:38:58 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id it4sm77298463pbc.39.2014.06.11.18.38.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 18:38:57 -0700 (PDT) Message-ID: <539904B6.4050803@gmail.com> Date: Thu, 12 Jun 2014 13:39:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> In-Reply-To: <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Sp9Fr1sxQXwxUeSr2X80ZYstKAc Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 01:39:00 -0000 On 12/06/2014 12:32, Dan Wing wrote: > On Jun 11, 2014, at 1:42 PM, Brian E Carpenter wrote: > >> On 11/06/2014 07:59, Black, David wrote: >>> In another message, Ruediger Geib asked (>), and I responded: >>> >>> -------------------- >>> >>>> Is the following correct: >>>> >>>> UDP_5-tuple-+--transport protocol 1----- >>>> | >>>> +--RTP session 1----- >>>> | >>>> +--RTP session 2-----+---RTP_stream_2.1 >>>> | >>>> +---RTP_stream_2.2 >>>> |... >>> Yes, that matches my understanding, although the author team would like to >>> see discussion of whether it's a good idea to mix RTP and non-RTP protocols >>> on the same 5-tuple - I'll copy your useful diagram into a separate message >>> to start that discussion. >>> >>> -------------------- >>> >>> This is that message, and I want to thank Ruediger for drawing that useful >>> diagram. >>> >>> The author team for draft-york would like input on whether the draft should >>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, vs. using >>> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP traffic. >> One observation is that we should be thinking about a 6-tuple these >> days (see RFC 6437). I don't think it makes much difference to the argument. >> >> Another observation is when load balancing is in play, things get a bit >> more complicated, but to a first approximation using the same 5-tuple >> or 6-tuple will usually ensure that all the packets reach the same >> load-balanced destination, which is probably a good thing. >> >> Third, reverting to the diffserv discussion, the same 5-tuple >> should ensure that all the packets would be classified the same >> (if they cross a diffserv domain boundary and get reclassified). > > What do you mean by 'all the packets would be classified the same'? If you mean all the packets in a 5-tuple would get the same differentiated treatment, that is not desirable, because there are lots of folks wanting to send video i-frames or packets with FEC or other stuff with lower drop precedence than other packets. Dan, if a packet crosses a diffserv domain boundary, the assumption is that (absent a specific SLA) its DSCP *will* be rewritten in whatever way the classifier of the receiving domain desires. DSCPs don't have end to end semantics, unless there is a string of SLAs along the path that all provide the same DSCP semantics. Not everybody likes this, but it was what the operators in the diffserv WG wanted at the time. If all operators agree to implement a common subset of the DSCPs suggested in various TSVWG documents, there would be a de facto end to end SLA for those DSCPs. But today, that's a bit of a dream world. So, for two arbitrary RTCweb users, there's certainly no assurance that the DSCP set at the source will be preserved until the destination. On the contrary, it's quite likely to be set to zero (at the boundary of an operator that distrusts the DSCP field) or to a value deemed suitable by an ingress classifier for whatever 5-tuple it carries. It seems unlikely that a classifier will look further into the payload than the port numbers. Brian > -d > > >> Brian >> >>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the same >>> 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb-transports-04: >>> >>> RTCWEB implementations MUST support multiplexing of DTLS and RTP over >>> the same port pair, as described in the DTLS_SRTP specification >>> [RFC5764], section 5.1.2. All application layer protocol payloads >>> over this DTLS connection are SCTP packets. >>> >>> OTOH, concerns have been expressed about whether the not-exactly-elegant >>> demux processing specified in the reference (RFC 5764, Section 5.1.2) ought >>> to be recommended as a good way of doing this multiplexing. >>> >>> Please comment, including whether mixing SCTP and RTP on the same UDP >>> 5-tuple is a good idea (some rationale for doing this sort of multiplexing >>> onto a single 5-tuple can be found in Section 3 of draft-york-dart-dscp-rtp-00). >>> >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> david.black@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>> >>> >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart >>> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart > > From nobody Wed Jun 11 18:46:44 2014 Return-Path: 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 848761B2964 for ; Wed, 11 Jun 2014 18:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 JfMy_7YjtKPo for ; Wed, 11 Jun 2014 18:46:39 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3B81B2962 for ; Wed, 11 Jun 2014 18:46:39 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id eu11so424359pac.39 for ; Wed, 11 Jun 2014 18:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gj6DNifVS0VWVVFqkxyworpCRmE5GAt+YAotZJwuSIU=; b=r67K7CDqJGs7KEdQFc7Smnw9xottrxIeBgXiuJtAiBNG2mXFp6PQU0S6kZiihpbfu5 BfutMnH7/x85zD7gUFVP9/yCt5hybUQ6fByYO43t3E6X91pJDiOPd+BvO4HLlhCPpR4w Yhc8eYQX1fjPly1n3IPSAZ7ia/89xZzZbElsvEgFEHBP1sH7smFJ/ptcX1XXKVnin7eD 0xlssjk+CFISOgIqUuqcT9c3gVnl9Efxe7wVSHhBdlWR7W28hU8dZ4sggtr/Njt8TIhB /rX8X2K0CDELa/OJforLtpNdWeEeTSReLVISo8U1nBS1JX+8l5dWTssSQ4cfD455RRTr k6Hw== X-Received: by 10.66.66.12 with SMTP id b12mr17132812pat.147.1402537599254; Wed, 11 Jun 2014 18:46:39 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id fv2sm77358855pbd.11.2014.06.11.18.46.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 18:46:38 -0700 (PDT) Message-ID: <53990684.8050900@gmail.com> Date: Thu, 12 Jun 2014 13:46:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Uv6su35xmUzAdqjZ4YmR-x1P370 Cc: "dart@ietf.org" , Dan Wing Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 01:46:41 -0000 On 12/06/2014 12:58, Black, David wrote: >> What do you mean by 'all the packets would be classified the same'? If you >> mean all the packets in a 5-tuple would get the same differentiated treatment, >> that is not desirable, because there are lots of folks wanting to send video >> i-frames or packets with FEC or other stuff with lower drop precedence than >> other packets. > > That would most likely be within an AF class; the entire set of packets marked > w/different drop precedences within an AF class should be classified the same. > > Beyond that, one can hope that any AF remarker (e.g., for traffic shaping) is > running in Color-Aware mode and hence tries to preserve source drop precedence > distinctions, but this cannot be relied upon. Indeed not, and that's on the assumption that the receiving domain even operates an AF service class. The worst case assumption is that everything reverts to best effort somewhere along the path. For some of the reasons behind this situation, I suggest reading http://tools.ietf.org/html/rfc2475#section-6.1 Brian > > Thanks, > --David > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Wednesday, June 11, 2014 8:32 PM >> To: Brian E Carpenter >> Cc: Black, David; dart@ietf.org >> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >> >> >> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter >> wrote: >> >>> On 11/06/2014 07:59, Black, David wrote: >>>> In another message, Ruediger Geib asked (>), and I responded: >>>> >>>> -------------------- >>>> >>>>> Is the following correct: >>>>> >>>>> UDP_5-tuple-+--transport protocol 1----- >>>>> | >>>>> +--RTP session 1----- >>>>> | >>>>> +--RTP session 2-----+---RTP_stream_2.1 >>>>> | >>>>> +---RTP_stream_2.2 >>>>> |... >>>> Yes, that matches my understanding, although the author team would like to >>>> see discussion of whether it's a good idea to mix RTP and non-RTP protocols >>>> on the same 5-tuple - I'll copy your useful diagram into a separate message >>>> to start that discussion. >>>> >>>> -------------------- >>>> >>>> This is that message, and I want to thank Ruediger for drawing that useful >>>> diagram. >>>> >>>> The author team for draft-york would like input on whether the draft should >>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, vs. >> using >>>> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP >> traffic. >>> One observation is that we should be thinking about a 6-tuple these >>> days (see RFC 6437). I don't think it makes much difference to the argument. >>> >>> Another observation is when load balancing is in play, things get a bit >>> more complicated, but to a first approximation using the same 5-tuple >>> or 6-tuple will usually ensure that all the packets reach the same >>> load-balanced destination, which is probably a good thing. >>> >>> Third, reverting to the diffserv discussion, the same 5-tuple >>> should ensure that all the packets would be classified the same >>> (if they cross a diffserv domain boundary and get reclassified). >> What do you mean by 'all the packets would be classified the same'? If you >> mean all the packets in a 5-tuple would get the same differentiated treatment, >> that is not desirable, because there are lots of folks wanting to send video >> i-frames or packets with FEC or other stuff with lower drop precedence than >> other packets. >> >> -d >> >> >>> Brian >>> >>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the same >>>> 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb- >> transports-04: >>>> RTCWEB implementations MUST support multiplexing of DTLS and RTP over >>>> the same port pair, as described in the DTLS_SRTP specification >>>> [RFC5764], section 5.1.2. All application layer protocol payloads >>>> over this DTLS connection are SCTP packets. >>>> >>>> OTOH, concerns have been expressed about whether the not-exactly-elegant >>>> demux processing specified in the reference (RFC 5764, Section 5.1.2) ought >>>> to be recommended as a good way of doing this multiplexing. >>>> >>>> Please comment, including whether mixing SCTP and RTP on the same UDP >>>> 5-tuple is a good idea (some rationale for doing this sort of multiplexing >>>> onto a single 5-tuple can be found in Section 3 of draft-york-dart-dscp- >> rtp-00). >>>> Thanks, >>>> --David >>>> ---------------------------------------------------- >>>> David L. Black, Distinguished Engineer >>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>> ---------------------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> Dart mailing list >>>> Dart@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dart >>>> >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart > > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart > From nobody Wed Jun 11 19:04:15 2014 Return-Path: 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 5A64C1B2970 for ; Wed, 11 Jun 2014 19:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 E6QQPqwrQGHO for ; Wed, 11 Jun 2014 19:04:11 -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 810681A0264 for ; Wed, 11 Jun 2014 19:04:10 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C246Eb018593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 22:04:06 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s5C246Eb018593 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402538646; bh=aC+CoT2OA/FhPDKHzsFZQoM71yg=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=dHM0rHhuoGd+KK+LSB6yR0muhGX0YWz37ccGDIF4662SYTngyxcc9dRYFWxD6+AtS LQaWRm5kQbNFOxDW7kpxTBMun39DqC32wtbTeDfw0NW7M3nDXSybY+dwkdv1/yqTaS m8bu8RA5ITK7Z7PK6+xbLNMzdxxOobuphjHmip0U= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s5C246Eb018593 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd01.lss.emc.com (RSA Interceptor); Wed, 11 Jun 2014 22:03:55 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C23snR024499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 22:03:54 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Wed, 11 Jun 2014 22:03:54 -0400 From: "Black, David" To: Brian E Carpenter Date: Wed, 11 Jun 2014 22:03:52 -0400 Thread-Topic: [Dart] RTP and non-RTP traffic on same UDP 5-tuple Thread-Index: Ac+F3xcdBGQnfHjGRyWv/GSclu/FsQAAkLtA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD34905@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <539904B6.4050803@gmail.com> In-Reply-To: <539904B6.4050803@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/bRWjay-8wNl4Q05S0JHAK6Yvm2s Cc: "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 02:04:13 -0000 PiBEYW4sIGlmIGEgcGFja2V0IGNyb3NzZXMgYSBkaWZmc2VydiBkb21haW4gYm91bmRhcnksDQo+ IHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgKGFic2VudCBhIHNwZWNpZmljIFNMQSkgaXRzDQo+IERT Q1AgKndpbGwqIGJlIHJld3JpdHRlbiBpbiB3aGF0ZXZlciB3YXkgdGhlIGNsYXNzaWZpZXINCj4g b2YgdGhlIHJlY2VpdmluZyBkb21haW4gZGVzaXJlcy4gRFNDUHMgZG9uJ3QgaGF2ZSBlbmQgdG8N Cj4gZW5kIHNlbWFudGljcywgdW5sZXNzIHRoZXJlIGlzIGEgc3RyaW5nIG9mIFNMQXMgYWxvbmcN Cj4gdGhlIHBhdGggdGhhdCBhbGwgcHJvdmlkZSB0aGUgc2FtZSBEU0NQIHNlbWFudGljcy4NCg0K U2VjdGlvbiAyLjQgaW4gZHJhZnQteW9yayBzdGFydHMgd2l0aDoNCg0KICAgRFNDUCBtYXJraW5n cyBhcmUgbm90IGVuZC10by1lbmQgaW4gZ2VuZXJhbC4NCg0KR2l2ZW4gdGhhdCB3ZSdyZSBoYXZp bmcgdGhpcyBkaXNjdXNzaW9uLCBpdCBzb3VuZHMgbGlrZSBzZWN0aW9uDQoyLjQgc2hvdWxkIGJl IGJsdW50ZXIgaW4gZGlzY3Vzc2luZyBob3cgZGlmZmVyZW50aWF0aW9uIG1heQ0KYmUgbG9zdCB2 aWEgcmVtYXJraW5nLg0KDQo+IElmIGFsbCBvcGVyYXRvcnMgYWdyZWUgdG8gaW1wbGVtZW50IGEg Y29tbW9uIHN1YnNldCBvZg0KPiB0aGUgRFNDUHMgc3VnZ2VzdGVkIGluIHZhcmlvdXMgVFNWV0cg ZG9jdW1lbnRzLCB0aGVyZSB3b3VsZA0KPiBiZSBhIGRlIGZhY3RvIGVuZCB0byBlbmQgU0xBIGZv ciB0aG9zZSBEU0NQcy4gQnV0IHRvZGF5LA0KPiB0aGF0J3MgYSBiaXQgb2YgYSBkcmVhbSB3b3Js ZC4gU28sIGZvciB0d28gYXJiaXRyYXJ5DQo+IFJUQ3dlYiB1c2VycywgdGhlcmUncyBjZXJ0YWlu bHkgbm8gYXNzdXJhbmNlIHRoYXQgdGhlDQo+IERTQ1Agc2V0IGF0IHRoZSBzb3VyY2Ugd2lsbCBi ZSBwcmVzZXJ2ZWQgdW50aWwgdGhlDQo+IGRlc3RpbmF0aW9uLiBPbiB0aGUgY29udHJhcnksIGl0 J3MgcXVpdGUgbGlrZWx5IHRvDQo+IGJlIHNldCB0byB6ZXJvIChhdCB0aGUgYm91bmRhcnkgb2Yg YW4gb3BlcmF0b3IgdGhhdA0KPiBkaXN0cnVzdHMgdGhlIERTQ1AgZmllbGQpIG9yIHRvIGEgdmFs dWUgZGVlbWVkIHN1aXRhYmxlDQo+IGJ5IGFuIGluZ3Jlc3MgY2xhc3NpZmllciBmb3Igd2hhdGV2 ZXIgNS10dXBsZSBpdCBjYXJyaWVzLg0KPiBJdCBzZWVtcyB1bmxpa2VseSB0aGF0IGEgY2xhc3Np ZmllciB3aWxsIGxvb2sgZnVydGhlcg0KPiBpbnRvIHRoZSBwYXlsb2FkIHRoYW4gdGhlIHBvcnQg bnVtYmVycy4NCg0KVGhhdCBsb29rcyBsaWtlIHNvbWUgYmx1bnRlciB0ZXh0IHRvIHN0YXJ0IGZy b20gLi4uDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDExLCAyMDE0IDk6MzkgUE0NCj4gVG86 IERhbiBXaW5nDQo+IENjOiBCbGFjaywgRGF2aWQ7IGRhcnRAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFtEYXJ0XSBSVFAgYW5kIG5vbi1SVFAgdHJhZmZpYyBvbiBzYW1lIFVEUCA1LXR1cGxlDQo+ IA0KPiBPbiAxMi8wNi8yMDE0IDEyOjMyLCBEYW4gV2luZyB3cm90ZToNCj4gPiBPbiBKdW4gMTEs IDIwMTQsIGF0IDE6NDIgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBn bWFpbC5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4+IE9uIDExLzA2LzIwMTQgMDc6NTksIEJsYWNr LCBEYXZpZCB3cm90ZToNCj4gPj4+IEluIGFub3RoZXIgbWVzc2FnZSwgUnVlZGlnZXIgR2VpYiBh c2tlZCAoPiksIGFuZCBJIHJlc3BvbmRlZDoNCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+Pj4NCj4gPj4+PiBJcyB0aGUgZm9sbG93aW5nIGNvcnJlY3Q6DQo+ID4+Pj4NCj4g Pj4+PiBVRFBfNS10dXBsZS0rLS10cmFuc3BvcnQgcHJvdG9jb2wgMS0tLS0tDQo+ID4+Pj4gICAg ICAgICAgICB8DQo+ID4+Pj4gICAgICAgICAgICArLS1SVFAgc2Vzc2lvbiAxLS0tLS0NCj4gPj4+ PiAgICAgICAgICAgIHwNCj4gPj4+PiAgICAgICAgICAgICstLVJUUCBzZXNzaW9uIDItLS0tLSst LS1SVFBfc3RyZWFtXzIuMQ0KPiA+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KPiA+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLVJUUF9zdHJlYW1f Mi4yDQo+ID4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Li4uDQo+ID4+PiBZ ZXMsIHRoYXQgbWF0Y2hlcyBteSB1bmRlcnN0YW5kaW5nLCBhbHRob3VnaCB0aGUgYXV0aG9yIHRl YW0gd291bGQgbGlrZSB0bw0KPiA+Pj4gc2VlIGRpc2N1c3Npb24gb2Ygd2hldGhlciBpdCdzIGEg Z29vZCBpZGVhIHRvIG1peCBSVFAgYW5kIG5vbi1SVFAgcHJvdG9jb2xzDQo+ID4+PiBvbiB0aGUg c2FtZSA1LXR1cGxlIC0gSSdsbCBjb3B5IHlvdXIgdXNlZnVsIGRpYWdyYW0gaW50byBhIHNlcGFy YXRlIG1lc3NhZ2UNCj4gPj4+IHRvIHN0YXJ0IHRoYXQgZGlzY3Vzc2lvbi4NCj4gPj4+DQo+ID4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4NCj4gPj4+IFRoaXMgaXMgdGhhdCBtZXNzYWdl LCBhbmQgSSB3YW50IHRvIHRoYW5rIFJ1ZWRpZ2VyIGZvciBkcmF3aW5nIHRoYXQgdXNlZnVsDQo+ ID4+PiBkaWFncmFtLg0KPiA+Pj4NCj4gPj4+IFRoZSBhdXRob3IgdGVhbSBmb3IgZHJhZnQteW9y ayB3b3VsZCBsaWtlIGlucHV0IG9uIHdoZXRoZXIgdGhlIGRyYWZ0IHNob3VsZA0KPiA+Pj4gZGlz Y3VzcyBtaXhpbmcgb2YgUlRQIGFuZCBub24tUlRQIHRyYWZmaWMgb24gdGhlIHNhbWUgVURQIDUt dHVwbGUsIHZzLiB1c2luZw0KPiA+Pj4gc2VwYXJhdGUgNS10dXBsZXMgKHByb2JhYmx5IHNlcGFy YXRlIFVEUCBwb3J0cykgZm9yIFJUUCBhbmQgbm9uLVJUUCB0cmFmZmljLg0KPiA+PiBPbmUgb2Jz ZXJ2YXRpb24gaXMgdGhhdCB3ZSBzaG91bGQgYmUgdGhpbmtpbmcgYWJvdXQgYSA2LXR1cGxlIHRo ZXNlDQo+ID4+IGRheXMgKHNlZSBSRkMgNjQzNykuIEkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgbXVj aCBkaWZmZXJlbmNlIHRvIHRoZSBhcmd1bWVudC4NCj4gPj4NCj4gPj4gQW5vdGhlciBvYnNlcnZh dGlvbiBpcyB3aGVuIGxvYWQgYmFsYW5jaW5nIGlzIGluIHBsYXksIHRoaW5ncyBnZXQgYSBiaXQN Cj4gPj4gbW9yZSBjb21wbGljYXRlZCwgYnV0IHRvIGEgZmlyc3QgYXBwcm94aW1hdGlvbiB1c2lu ZyB0aGUgc2FtZSA1LXR1cGxlDQo+ID4+IG9yIDYtdHVwbGUgd2lsbCB1c3VhbGx5IGVuc3VyZSB0 aGF0IGFsbCB0aGUgcGFja2V0cyByZWFjaCB0aGUgc2FtZQ0KPiA+PiBsb2FkLWJhbGFuY2VkIGRl c3RpbmF0aW9uLCB3aGljaCBpcyBwcm9iYWJseSBhIGdvb2QgdGhpbmcuDQo+ID4+DQo+ID4+IFRo aXJkLCByZXZlcnRpbmcgdG8gdGhlIGRpZmZzZXJ2IGRpc2N1c3Npb24sIHRoZSBzYW1lIDUtdHVw bGUNCj4gPj4gc2hvdWxkIGVuc3VyZSB0aGF0IGFsbCB0aGUgcGFja2V0cyB3b3VsZCBiZSBjbGFz c2lmaWVkIHRoZSBzYW1lDQo+ID4+IChpZiB0aGV5IGNyb3NzIGEgZGlmZnNlcnYgZG9tYWluIGJv dW5kYXJ5IGFuZCBnZXQgcmVjbGFzc2lmaWVkKS4NCj4gPg0KPiA+IFdoYXQgZG8geW91IG1lYW4g YnkgJ2FsbCB0aGUgcGFja2V0cyB3b3VsZCBiZSBjbGFzc2lmaWVkIHRoZSBzYW1lJz8gIElmIHlv dQ0KPiBtZWFuIGFsbCB0aGUgcGFja2V0cyBpbiBhIDUtdHVwbGUgd291bGQgZ2V0IHRoZSBzYW1l IGRpZmZlcmVudGlhdGVkIHRyZWF0bWVudCwNCj4gdGhhdCBpcyBub3QgZGVzaXJhYmxlLCBiZWNh dXNlIHRoZXJlIGFyZSBsb3RzIG9mIGZvbGtzIHdhbnRpbmcgdG8gc2VuZCB2aWRlbw0KPiBpLWZy YW1lcyBvciBwYWNrZXRzIHdpdGggRkVDIG9yIG90aGVyIHN0dWZmIHdpdGggbG93ZXIgZHJvcCBw cmVjZWRlbmNlIHRoYW4NCj4gb3RoZXIgcGFja2V0cy4NCj4gDQo+IERhbiwgaWYgYSBwYWNrZXQg Y3Jvc3NlcyBhIGRpZmZzZXJ2IGRvbWFpbiBib3VuZGFyeSwNCj4gdGhlIGFzc3VtcHRpb24gaXMg dGhhdCAoYWJzZW50IGEgc3BlY2lmaWMgU0xBKSBpdHMNCj4gRFNDUCAqd2lsbCogYmUgcmV3cml0 dGVuIGluIHdoYXRldmVyIHdheSB0aGUgY2xhc3NpZmllcg0KPiBvZiB0aGUgcmVjZWl2aW5nIGRv bWFpbiBkZXNpcmVzLiBEU0NQcyBkb24ndCBoYXZlIGVuZCB0bw0KPiBlbmQgc2VtYW50aWNzLCB1 bmxlc3MgdGhlcmUgaXMgYSBzdHJpbmcgb2YgU0xBcyBhbG9uZw0KPiB0aGUgcGF0aCB0aGF0IGFs bCBwcm92aWRlIHRoZSBzYW1lIERTQ1Agc2VtYW50aWNzLg0KPiANCj4gTm90IGV2ZXJ5Ym9keSBs aWtlcyB0aGlzLCBidXQgaXQgd2FzIHdoYXQgdGhlIG9wZXJhdG9ycw0KPiBpbiB0aGUgZGlmZnNl cnYgV0cgd2FudGVkIGF0IHRoZSB0aW1lLg0KPiANCj4gSWYgYWxsIG9wZXJhdG9ycyBhZ3JlZSB0 byBpbXBsZW1lbnQgYSBjb21tb24gc3Vic2V0IG9mDQo+IHRoZSBEU0NQcyBzdWdnZXN0ZWQgaW4g dmFyaW91cyBUU1ZXRyBkb2N1bWVudHMsIHRoZXJlIHdvdWxkDQo+IGJlIGEgZGUgZmFjdG8gZW5k IHRvIGVuZCBTTEEgZm9yIHRob3NlIERTQ1BzLiBCdXQgdG9kYXksDQo+IHRoYXQncyBhIGJpdCBv ZiBhIGRyZWFtIHdvcmxkLiBTbywgZm9yIHR3byBhcmJpdHJhcnkNCj4gUlRDd2ViIHVzZXJzLCB0 aGVyZSdzIGNlcnRhaW5seSBubyBhc3N1cmFuY2UgdGhhdCB0aGUNCj4gRFNDUCBzZXQgYXQgdGhl IHNvdXJjZSB3aWxsIGJlIHByZXNlcnZlZCB1bnRpbCB0aGUNCj4gZGVzdGluYXRpb24uIE9uIHRo ZSBjb250cmFyeSwgaXQncyBxdWl0ZSBsaWtlbHkgdG8NCj4gYmUgc2V0IHRvIHplcm8gKGF0IHRo ZSBib3VuZGFyeSBvZiBhbiBvcGVyYXRvciB0aGF0DQo+IGRpc3RydXN0cyB0aGUgRFNDUCBmaWVs ZCkgb3IgdG8gYSB2YWx1ZSBkZWVtZWQgc3VpdGFibGUNCj4gYnkgYW4gaW5ncmVzcyBjbGFzc2lm aWVyIGZvciB3aGF0ZXZlciA1LXR1cGxlIGl0IGNhcnJpZXMuDQo+IEl0IHNlZW1zIHVubGlrZWx5 IHRoYXQgYSBjbGFzc2lmaWVyIHdpbGwgbG9vayBmdXJ0aGVyDQo+IGludG8gdGhlIHBheWxvYWQg dGhhbiB0aGUgcG9ydCBudW1iZXJzLg0KPiANCj4gICAgIEJyaWFuDQo+IA0KPiA+IC1kDQo+ID4N Cj4gPg0KPiA+PiAgICBCcmlhbg0KPiA+Pg0KPiA+Pj4gUlRDV0VCIGNsZWFybHkgaW50ZW5kcyB0 byBtaXggU0NUUCAodmlhIERUTFMpIGFuZCBSVFAgdHJhZmZpYyBvbiB0aGUgc2FtZQ0KPiA+Pj4g NS10dXBsZSBzZWUgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gMy41IG9mIGRyYWZ0LWll dGYtcnRjd2ViLQ0KPiB0cmFuc3BvcnRzLTA0Og0KPiA+Pj4NCj4gPj4+ICAgUlRDV0VCIGltcGxl bWVudGF0aW9ucyBNVVNUIHN1cHBvcnQgbXVsdGlwbGV4aW5nIG9mIERUTFMgYW5kIFJUUCBvdmVy DQo+ID4+PiAgIHRoZSBzYW1lIHBvcnQgcGFpciwgYXMgZGVzY3JpYmVkIGluIHRoZSBEVExTX1NS VFAgc3BlY2lmaWNhdGlvbg0KPiA+Pj4gICBbUkZDNTc2NF0sIHNlY3Rpb24gNS4xLjIuICBBbGwg YXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgcGF5bG9hZHMNCj4gPj4+ICAgb3ZlciB0aGlzIERU TFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNrZXRzLg0KPiA+Pj4NCj4gPj4+IE9UT0gsIGNvbmNl cm5zIGhhdmUgYmVlbiBleHByZXNzZWQgYWJvdXQgd2hldGhlciB0aGUgbm90LWV4YWN0bHktZWxl Z2FudA0KPiA+Pj4gZGVtdXggcHJvY2Vzc2luZyBzcGVjaWZpZWQgaW4gdGhlIHJlZmVyZW5jZSAo UkZDIDU3NjQsIFNlY3Rpb24gNS4xLjIpDQo+IG91Z2h0DQo+ID4+PiB0byBiZSByZWNvbW1lbmRl ZCBhcyBhIGdvb2Qgd2F5IG9mIGRvaW5nIHRoaXMgbXVsdGlwbGV4aW5nLg0KPiA+Pj4NCj4gPj4+ IFBsZWFzZSBjb21tZW50LCBpbmNsdWRpbmcgd2hldGhlciBtaXhpbmcgU0NUUCBhbmQgUlRQIG9u IHRoZSBzYW1lIFVEUA0KPiA+Pj4gNS10dXBsZSBpcyBhIGdvb2QgaWRlYSAoc29tZSByYXRpb25h bGUgZm9yIGRvaW5nIHRoaXMgc29ydCBvZiBtdWx0aXBsZXhpbmcNCj4gPj4+IG9udG8gYSBzaW5n bGUgNS10dXBsZSBjYW4gYmUgZm91bmQgaW4gU2VjdGlvbiAzIG9mIGRyYWZ0LXlvcmstZGFydC1k c2NwLQ0KPiBydHAtMDApLg0KPiA+Pj4NCj4gPj4+IFRoYW5rcywNCj4gPj4+IC0tRGF2aWQNCj4g Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4+IERhdmlkIEwuIEJsYWNrLCBEaXN0aW5ndWlzaGVkIEVuZ2luZWVyDQo+ID4+PiBFTUMg Q29ycG9yYXRpb24sIDE3NiBTb3V0aCBTdC4sIEhvcGtpbnRvbiwgTUEgIDAxNzQ4DQo+ID4+PiAr MSAoNTA4KSAyOTMtNzk1MyAgICAgICAgICAgICBGQVg6ICsxICg1MDgpIDI5My03Nzg2DQo+ID4+ PiBkYXZpZC5ibGFja0BlbWMuY29tICAgICAgICBNb2JpbGU6ICsxICg5NzgpIDM5NC03NzU0DQo+ ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+PiBEYXJ0IG1haWxpbmcgbGlzdA0KPiA+Pj4gRGFydEBpZXRmLm9y Zw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYXJ0DQo+ID4+ Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBEYXJ0IG1haWxpbmcgbGlzdA0KPiA+PiBEYXJ0QGlldGYub3JnDQo+ID4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGFydA0KPiA+DQo+ID4NCg== From nobody Wed Jun 11 19:23:46 2014 Return-Path: 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 5D61D1A0300 for ; Wed, 11 Jun 2014 19:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 99HoXeHe_Jwk for ; Wed, 11 Jun 2014 19:23:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525701A02F9 for ; Wed, 11 Jun 2014 19:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5396; q=dns/txt; s=iport; t=1402539818; x=1403749418; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=e6cwKwrgTF3tGCNIgnXhgT9VCXFewMwIMlkxITim1k8=; b=jvnzDbPxoPmELuxIgXJM+ykXuXAt0lnG6n+dONKVEJoPqzxDTtkTjzVL 8omyr8PovvvUySPS+/kn66him4H4KPZCawXLM2GKvo6nrsf22mClNtCpf CnAozx6GweN5JUEB0KesNSqYWj8xbNFnD91v9abMZGs/BH8JNao+0ejfR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFAK4NmVOtJA2G/2dsb2JhbABXA4MNUlapSgEBAQEBAQUBkV+HPAGBCRZ1hAMBAQEDAQEBATcrCQsFBwQLEQQBAQEnByEGHwkIBhOILgMJCA3KBQ2GExMEhVyGWoFAMCMQBwYLgxqBFgSJR3KNfIF5jVCFe4NcHS8 X-IronPort-AV: E=Sophos;i="5.01,461,1400025600"; d="scan'208";a="332506387" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jun 2014 02:23:37 +0000 Received: from sjc-vpn7-933.cisco.com (sjc-vpn7-933.cisco.com [10.21.147.165]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5C2NV6o000841; Thu, 12 Jun 2014 02:23:37 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dan Wing In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> Date: Wed, 11 Jun 2014 18:59:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <94627BFD-C142-4092-BC9D-920B802C01D5@cisco.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/wPZIH18b5U8CR3fOl9AFm88PU_A Cc: "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 02:23:44 -0000 On Jun 11, 2014, at 5:58 PM, Black, David wrote: >> What do you mean by 'all the packets would be classified the same'? = If you >> mean all the packets in a 5-tuple would get the same differentiated = treatment, >> that is not desirable, because there are lots of folks wanting to = send video >> i-frames or packets with FEC or other stuff with lower drop = precedence than >> other packets. >=20 > That would most likely be within an AF class; the entire set of = packets marked > w/different drop precedences within an AF class should be classified = the same. >=20 > Beyond that, one can hope that any AF remarker (e.g., for traffic = shaping) is > running in Color-Aware mode and hence tries to preserve source drop = precedence > distinctions, but this cannot be relied upon. Is the problem lack of color awareness in the AF remarker, or that AF = remarkers assume all packets in the 5-tuple have the same color? -d > Thanks, > --David >=20 >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Wednesday, June 11, 2014 8:32 PM >> To: Brian E Carpenter >> Cc: Black, David; dart@ietf.org >> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >>=20 >>=20 >> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter = >> wrote: >>=20 >>> On 11/06/2014 07:59, Black, David wrote: >>>> In another message, Ruediger Geib asked (>), and I responded: >>>>=20 >>>> -------------------- >>>>=20 >>>>> Is the following correct: >>>>>=20 >>>>> UDP_5-tuple-+--transport protocol 1----- >>>>> | >>>>> +--RTP session 1----- >>>>> | >>>>> +--RTP session 2-----+---RTP_stream_2.1 >>>>> | >>>>> +---RTP_stream_2.2 >>>>> |... >>>>=20 >>>> Yes, that matches my understanding, although the author team would = like to >>>> see discussion of whether it's a good idea to mix RTP and non-RTP = protocols >>>> on the same 5-tuple - I'll copy your useful diagram into a separate = message >>>> to start that discussion. >>>>=20 >>>> -------------------- >>>>=20 >>>> This is that message, and I want to thank Ruediger for drawing that = useful >>>> diagram. >>>>=20 >>>> The author team for draft-york would like input on whether the = draft should >>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, = vs. >> using >>>> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP >> traffic. >>>=20 >>> One observation is that we should be thinking about a 6-tuple these >>> days (see RFC 6437). I don't think it makes much difference to the = argument. >>>=20 >>> Another observation is when load balancing is in play, things get a = bit >>> more complicated, but to a first approximation using the same = 5-tuple >>> or 6-tuple will usually ensure that all the packets reach the same >>> load-balanced destination, which is probably a good thing. >>>=20 >>> Third, reverting to the diffserv discussion, the same 5-tuple >>> should ensure that all the packets would be classified the same >>> (if they cross a diffserv domain boundary and get reclassified). >>=20 >> What do you mean by 'all the packets would be classified the same'? = If you >> mean all the packets in a 5-tuple would get the same differentiated = treatment, >> that is not desirable, because there are lots of folks wanting to = send video >> i-frames or packets with FEC or other stuff with lower drop = precedence than >> other packets. >>=20 >> -d >>=20 >>=20 >>>=20 >>> Brian >>>=20 >>>>=20 >>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on = the same >>>> 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb- >> transports-04: >>>>=20 >>>> RTCWEB implementations MUST support multiplexing of DTLS and RTP = over >>>> the same port pair, as described in the DTLS_SRTP specification >>>> [RFC5764], section 5.1.2. All application layer protocol payloads >>>> over this DTLS connection are SCTP packets. >>>>=20 >>>> OTOH, concerns have been expressed about whether the = not-exactly-elegant >>>> demux processing specified in the reference (RFC 5764, Section = 5.1.2) ought >>>> to be recommended as a good way of doing this multiplexing. >>>>=20 >>>> Please comment, including whether mixing SCTP and RTP on the same = UDP >>>> 5-tuple is a good idea (some rationale for doing this sort of = multiplexing >>>> onto a single 5-tuple can be found in Section 3 of = draft-york-dart-dscp- >> rtp-00). >>>>=20 >>>> Thanks, >>>> --David >>>> ---------------------------------------------------- >>>> David L. Black, Distinguished Engineer >>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>> ---------------------------------------------------- >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Dart mailing list >>>> Dart@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dart >>>>=20 >>>=20 >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart >=20 From nobody Wed Jun 11 19:31:55 2014 Return-Path: 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 A9BA31B2970 for ; Wed, 11 Jun 2014 19:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 n3NbYxTVasEi for ; Wed, 11 Jun 2014 19:31:52 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B451A0261 for ; Wed, 11 Jun 2014 19:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5574; q=dns/txt; s=iport; t=1402540312; x=1403749912; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=if1revgAMIcX9W0SQSWYwgFqtZTuvCle6c0XltoJrMo=; b=Wb9SN+QABrvdQnqir7z1RWJI/43nemBVtJz63yeb8GT8tI7M1Wbj5x1G 1HQXmncdQO0I1lu6fmOzPVHo+gbApUgrWN6BKgafxLRLTYe/in9sQ+pcT Mqpwam381DERlFNKlwPqweMzBl6/SGg4P1iJXAqZSFChHNUm+7y3TMegM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMFAGcQmVOtJA2N/2dsb2JhbABXA4MNUlapSwEBAQEBAQUBkV+HPAGBCRZ1hAMBAQEDAQEBATcrAgcLBQsLGC4hBjAGE4guAwkIDcoFDYYTEwSFXIZagUAwIxAHEYMagRYEiUdyjXyBeY1QhXuDXB0v X-IronPort-AV: E=Sophos;i="5.01,462,1400025600"; d="scan'208";a="52364932" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 12 Jun 2014 02:31:51 +0000 Received: from sjc-vpn7-933.cisco.com (sjc-vpn7-933.cisco.com [10.21.147.165]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5C2Vocx020043; Thu, 12 Jun 2014 02:31:50 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dan Wing In-Reply-To: <539904B6.4050803@gmail.com> Date: Wed, 11 Jun 2014 19:31:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <539904B6.4050803@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/HnIauFH9HhwyeOt-R2IsejSoXm8 Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 02:31:53 -0000 On Jun 11, 2014, at 6:39 PM, Brian E Carpenter = wrote: > On 12/06/2014 12:32, Dan Wing wrote: >> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter = wrote: >>=20 >>> On 11/06/2014 07:59, Black, David wrote: >>>> In another message, Ruediger Geib asked (>), and I responded: >>>>=20 >>>> -------------------- >>>>=20 >>>>> Is the following correct: >>>>>=20 >>>>> UDP_5-tuple-+--transport protocol 1----- >>>>> | >>>>> +--RTP session 1----- >>>>> | >>>>> +--RTP session 2-----+---RTP_stream_2.1 >>>>> | >>>>> +---RTP_stream_2.2 >>>>> |... >>>> Yes, that matches my understanding, although the author team would = like to >>>> see discussion of whether it's a good idea to mix RTP and non-RTP = protocols >>>> on the same 5-tuple - I'll copy your useful diagram into a separate = message >>>> to start that discussion. >>>>=20 >>>> -------------------- >>>>=20 >>>> This is that message, and I want to thank Ruediger for drawing that = useful >>>> diagram. >>>>=20 >>>> The author team for draft-york would like input on whether the = draft should >>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, = vs. using >>>> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP = traffic. >>> One observation is that we should be thinking about a 6-tuple these >>> days (see RFC 6437). I don't think it makes much difference to the = argument. >>>=20 >>> Another observation is when load balancing is in play, things get a = bit >>> more complicated, but to a first approximation using the same = 5-tuple >>> or 6-tuple will usually ensure that all the packets reach the same >>> load-balanced destination, which is probably a good thing. >>>=20 >>> Third, reverting to the diffserv discussion, the same 5-tuple >>> should ensure that all the packets would be classified the same >>> (if they cross a diffserv domain boundary and get reclassified). >>=20 >> What do you mean by 'all the packets would be classified the same'? = If you mean all the packets in a 5-tuple would get the same = differentiated treatment, that is not desirable, because there are lots = of folks wanting to send video i-frames or packets with FEC or other = stuff with lower drop precedence than other packets. >=20 > Dan, if a packet crosses a diffserv domain boundary, > the assumption is that (absent a specific SLA) its > DSCP *will* be rewritten in whatever way the classifier > of the receiving domain desires. DSCPs don't have end to > end semantics, unless there is a string of SLAs along > the path that all provide the same DSCP semantics. >=20 > Not everybody likes this, but it was what the operators > in the diffserv WG wanted at the time. >=20 > If all operators agree to implement a common subset of > the DSCPs suggested in various TSVWG documents, there would > be a de facto end to end SLA for those DSCPs. But today, > that's a bit of a dream world. So, for two arbitrary > RTCweb users, there's certainly no assurance that the > DSCP set at the source will be preserved until the > destination. On the contrary, it's quite likely to > be set to zero (at the boundary of an operator that > distrusts the DSCP field) or to a value deemed suitable > by an ingress classifier for whatever 5-tuple it carries. > It seems unlikely that a classifier will look further > into the payload than the port numbers. So, by "all packets will be classified the same", you mean reset to = zero. -d >=20 > Brian >=20 >> -d >>=20 >>=20 >>> Brian >>>=20 >>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on = the same >>>> 5-tuple see the last paragraph of Section 3.5 of = draft-ietf-rtcweb-transports-04: >>>>=20 >>>> RTCWEB implementations MUST support multiplexing of DTLS and RTP = over >>>> the same port pair, as described in the DTLS_SRTP specification >>>> [RFC5764], section 5.1.2. All application layer protocol payloads >>>> over this DTLS connection are SCTP packets. >>>>=20 >>>> OTOH, concerns have been expressed about whether the = not-exactly-elegant >>>> demux processing specified in the reference (RFC 5764, Section = 5.1.2) ought >>>> to be recommended as a good way of doing this multiplexing. >>>>=20 >>>> Please comment, including whether mixing SCTP and RTP on the same = UDP >>>> 5-tuple is a good idea (some rationale for doing this sort of = multiplexing >>>> onto a single 5-tuple can be found in Section 3 of = draft-york-dart-dscp-rtp-00). >>>>=20 >>>> Thanks, >>>> --David >>>> ---------------------------------------------------- >>>> David L. Black, Distinguished Engineer >>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>> ---------------------------------------------------- >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Dart mailing list >>>> Dart@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dart >>>>=20 >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart >>=20 >>=20 >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Wed Jun 11 19:34:59 2014 Return-Path: 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 61F2F1B298A for ; Wed, 11 Jun 2014 19:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 cCnuxS36k4A7 for ; Wed, 11 Jun 2014 19:34:56 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388941B2986 for ; Wed, 11 Jun 2014 19:34:55 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C2Ysw6013833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 22:34:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s5C2Ysw6013833 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402540494; bh=i6V2tF0yeoWeUsq6ST7MufpZmlw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Lzl7wXwVDY43YnkviP+HNQm4NGrdweBzbLHbY8p217Xtt9qMzwDee3uhlOjyRyYmk 5FmMVDprJBQc74sWR2mvsmSHh0Jo5X0I5NXRIkO/yHsa7bm6UJjsELpJraxb9I/VHY y5bxDpMS55vHG3pLYUMBD+Y202hBd8F6UaRC29qI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s5C2Ysw6013833 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 11 Jun 2014 22:34:35 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C2Xhth016939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 22:34:34 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Wed, 11 Jun 2014 22:34:23 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Wed, 11 Jun 2014 22:34:22 -0400 Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQAKMdosAAGlz6kAAWWTOQACqOmHA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD34911@MX15A.corp.emc.com> References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com> In-Reply-To: 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/vkl2qTROCcWuP1Bhmf9Z0CD9gOs Cc: "dart@ietf.org" Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 02:34:58 -0000 Hi Ruediger, Extracting text on a couple of points: > I'd appreciate another > draft line explaining how MediaStream corresponds to RTP stream or > RTP session. Sure. The parenthetical text on MediaStream and MediaStreamTrack can be pulled out of item 1, moved a bit later in the section and expanded. > RG> Your draft is offering good QoS related guidance, and it's not only > provided by the above section. I would appreciate a good explanation > of what to expect within a single 5 tuple flow (a single application > flow or multiple ones). That expectation may not be what you're looking for - it's likely to be a longer version of "everything depends on the network(s)", i.e., nothing can be assured in general, depending on how the networks involved are configured for DiffServ. See Brian Carpenter's recent emails to the list and my comment on strengthening the text in Section 2.4 about how differentiation can be lost (e.g., all traffic in a 5-tuple could be remarked to DF [best effort] at some intermediate network boundary node). Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Wednesday, June 11, 2014 4:09 AM > To: Black, David > Cc: dart@ietf.org > Subject: AW: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 > Hi David, >=20 > my responses start by "RG". >=20 > Regards, Ruediger >=20 > > If a MediaStream is carried in a RTP session, the text may also > > explicitely say that (it says MediaStreamTrack =3D=3D media flow, whic= h is > > carried in an individual RTP packet stream) >=20 > DB: As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB, > DB: that would happen only when the MediaStream contains exactly one > DB: MediaStreamTrack. The use of these terms in bullet item 1 in > DB: section 2 is intended to be specific to RTCWEB, but we could add > DB: text elsewhere to point out that non-RTCWEB usage of MediaStreams > DB: could use an RTP packet stream for each Media Stream, independent > DB: of how many MediaStreamTracks each MediaStream contains. >=20 > DB: Could you suggest a reference that could be cited for usage of an > DB: RTP packet stream for each MediaStream independent of how many > DB: MediaStreamTracks each MediaStream contains? >=20 > RG> Sorry, I can't, that above was an assumption. I'd appreciate another > draft line explaining how MediaStream corresponds to RTP stream or > RTP session. >=20 > > Is the following correct: > > > > UDP_5-tuple-+--transport protocol 1----- > > | > > +--RTP session 1----- > > | > > +--RTP session 2-----+---RTP_stream_2.1 > > | > > +---RTP_stream_2.2 > > |... >=20 > [snip] >=20 > DB: See draft-ietf-tsvwg-rtcweb-qos-00, which proposes to make all four A= F > DB: classes available, so we can expect that someone will try to use all > DB: of them (and everything else in that draft). >=20 > DB: OTOH, we did put this warning text in at the end of Section 2.4 of dr= aft- > york: >=20 > Backbone and other carrier networks may employ a small number of > DSCPs (e.g., less than half a dozen) in order to manage a small > number of traffic aggregates; hosts that use a larger number of DSCP= s > may find that much of the intended differentiation is removed by suc= h > networks. >=20 > DB: What additional text would you suggest that we add? >=20 > RG> tsvwg-rtcweb-qos offers 4 priorities which, following the definition = given > there, are relevant to the browser (not to forwarding, as the draft d= oesn't > change existing standards on that). > I'd expect priorities "very low" and "low" to be produced in one queu= e. I'd > expect each AF class to be produced in one queue. So packet reorderin= g may > occur between different priorities. Type "data" requires 3 queues, if > produced as I'd assume. >=20 > RG> Your draft is offering good QoS related guidance, and it's not only p= rovided by the > above section. I would appreciate a good explanation of what to expec= t within > a single 5 tuple flow (a single application flow or multiple ones). I= 'd > further appreciate, if all rtcweb related drafts in the transport are= a clarify > the concepts they support related to rtcweb transport flow types. MF = based > classification is one mode of DiffServ operation and it's important t= o note > whether this is applicable in future or not. For the time being, appl= ication > servers aren't always marking flows and the above suggests, that they= will > have to mark packets within flows individually. >=20 > RG> Finally, if the QoE suffers because code points interpreted as applic= ation > priorities by browsers, which at the same time are interpreted as tra= nsport > QoS marks by routers which may be changed at network boundaries, then > DiffServ as a whole may have to be re-thought. To better understand t= hat > point, I've posted a mail on the tsvwg list. >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 From nobody Wed Jun 11 19:37:55 2014 Return-Path: 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 080541B2995 for ; Wed, 11 Jun 2014 19:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 0mM1ILuQr8yZ for ; Wed, 11 Jun 2014 19:37:52 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E391B2997 for ; Wed, 11 Jun 2014 19:37:51 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C2bmD1006691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 22:37:49 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s5C2bmD1006691 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402540670; bh=+bRQBbkh/P0VPaBa8Psa03WREOM=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=dB3mS4zIvjW9fbRkYr8gGrWCUWcta+5UBL/6M2Jrf2d4YB0kTgM6uzxovXQjVrH89 QrMF07h+wdhNbY4V2+lNNtuXZ5kRbuhZ5K6wJQ5AVJK2k4Lpk8g/Hev7eOn6R+mZR2 ltoMFf/4ldAhs22Oka+7T6bhnBPxiKyrSebSIjyI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s5C2bmD1006691 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd53.lss.emc.com (RSA Interceptor); Wed, 11 Jun 2014 22:37:37 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C2balH009174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 22:37:36 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Wed, 11 Jun 2014 22:37:36 -0400 From: "Black, David" To: Dan Wing Date: Wed, 11 Jun 2014 22:37:34 -0400 Thread-Topic: [Dart] RTP and non-RTP traffic on same UDP 5-tuple Thread-Index: Ac+F5VUx/Dft8pAiRpeNeFwa4B4oRAAAZ76w Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD34914@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> <94627BFD-C142-4092-BC9D-920B802C01D5@cisco.com> In-Reply-To: <94627BFD-C142-4092-BC9D-920B802C01D5@cisco.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: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/BlY1XqRzBYUcjLQJtq4hb_JWCw0 Cc: "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 02:37:54 -0000 > Is the problem lack of color awareness in the AF remarker, or that AF > remarkers assume all packets in the 5-tuple have the same color? The former, quoting from Section 2.4 of the draft: In addition, remarking may remove application-level distinctions in forwarding behavior - e.g., if multiple PHBs within an AF class are used to distinguish different types of frames within a video flow, token-bucket-based remarkers operating in Color-Blind mode (see [RFC2697] and [RFC2698] for examples) may remark solely based on flow rate and burst behavior, removing the drop precedence distinctions specified by the source. Beyond that, if the network that the traffic is entering does not support the AF class involved on that ingress, DSCP remarking to zero (best effort) is a likely behavior. Thanks, --David > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, June 11, 2014 10:00 PM > To: Black, David > Cc: dart@ietf.org > Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >=20 >=20 > On Jun 11, 2014, at 5:58 PM, Black, David wrote: >=20 > >> What do you mean by 'all the packets would be classified the same'? I= f you > >> mean all the packets in a 5-tuple would get the same differentiated > treatment, > >> that is not desirable, because there are lots of folks wanting to send > video > >> i-frames or packets with FEC or other stuff with lower drop precedence= than > >> other packets. > > > > That would most likely be within an AF class; the entire set of packets > marked > > w/different drop precedences within an AF class should be classified th= e > same. > > > > Beyond that, one can hope that any AF remarker (e.g., for traffic shapi= ng) > is > > running in Color-Aware mode and hence tries to preserve source drop > precedence > > distinctions, but this cannot be relied upon. >=20 > Is the problem lack of color awareness in the AF remarker, or that AF > remarkers assume all packets in the 5-tuple have the same color? >=20 > -d >=20 >=20 > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Dan Wing [mailto:dwing@cisco.com] > >> Sent: Wednesday, June 11, 2014 8:32 PM > >> To: Brian E Carpenter > >> Cc: Black, David; dart@ietf.org > >> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple > >> > >> > >> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter > > >> wrote: > >> > >>> On 11/06/2014 07:59, Black, David wrote: > >>>> In another message, Ruediger Geib asked (>), and I responded: > >>>> > >>>> -------------------- > >>>> > >>>>> Is the following correct: > >>>>> > >>>>> UDP_5-tuple-+--transport protocol 1----- > >>>>> | > >>>>> +--RTP session 1----- > >>>>> | > >>>>> +--RTP session 2-----+---RTP_stream_2.1 > >>>>> | > >>>>> +---RTP_stream_2.2 > >>>>> |... > >>>> > >>>> Yes, that matches my understanding, although the author team would l= ike > to > >>>> see discussion of whether it's a good idea to mix RTP and non-RTP > protocols > >>>> on the same 5-tuple - I'll copy your useful diagram into a separate > message > >>>> to start that discussion. > >>>> > >>>> -------------------- > >>>> > >>>> This is that message, and I want to thank Ruediger for drawing that > useful > >>>> diagram. > >>>> > >>>> The author team for draft-york would like input on whether the draft > should > >>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, v= s. > >> using > >>>> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP > >> traffic. > >>> > >>> One observation is that we should be thinking about a 6-tuple these > >>> days (see RFC 6437). I don't think it makes much difference to the > argument. > >>> > >>> Another observation is when load balancing is in play, things get a b= it > >>> more complicated, but to a first approximation using the same 5-tuple > >>> or 6-tuple will usually ensure that all the packets reach the same > >>> load-balanced destination, which is probably a good thing. > >>> > >>> Third, reverting to the diffserv discussion, the same 5-tuple > >>> should ensure that all the packets would be classified the same > >>> (if they cross a diffserv domain boundary and get reclassified). > >> > >> What do you mean by 'all the packets would be classified the same'? I= f you > >> mean all the packets in a 5-tuple would get the same differentiated > treatment, > >> that is not desirable, because there are lots of folks wanting to send > video > >> i-frames or packets with FEC or other stuff with lower drop precedence= than > >> other packets. > >> > >> -d > >> > >> > >>> > >>> Brian > >>> > >>>> > >>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the= same > >>>> 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb- > >> transports-04: > >>>> > >>>> RTCWEB implementations MUST support multiplexing of DTLS and RTP ov= er > >>>> the same port pair, as described in the DTLS_SRTP specification > >>>> [RFC5764], section 5.1.2. All application layer protocol payloads > >>>> over this DTLS connection are SCTP packets. > >>>> > >>>> OTOH, concerns have been expressed about whether the not-exactly-ele= gant > >>>> demux processing specified in the reference (RFC 5764, Section 5.1.2= ) > ought > >>>> to be recommended as a good way of doing this multiplexing. > >>>> > >>>> Please comment, including whether mixing SCTP and RTP on the same UD= P > >>>> 5-tuple is a good idea (some rationale for doing this sort of > multiplexing > >>>> onto a single 5-tuple can be found in Section 3 of draft-york-dart-d= scp- > >> rtp-00). > >>>> > >>>> Thanks, > >>>> --David > >>>> ---------------------------------------------------- > >>>> David L. Black, Distinguished Engineer > >>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 > >>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >>>> david.black@emc.com Mobile: +1 (978) 394-7754 > >>>> ---------------------------------------------------- > >>>> > >>>> > >>>> _______________________________________________ > >>>> Dart mailing list > >>>> Dart@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dart > >>>> > >>> > >>> _______________________________________________ > >>> Dart mailing list > >>> Dart@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dart > > From nobody Wed Jun 11 21:54:42 2014 Return-Path: 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 9ED271A036C for ; Wed, 11 Jun 2014 21:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 n5JBCZmCjd_u for ; Wed, 11 Jun 2014 21:54:39 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE691A035F for ; Wed, 11 Jun 2014 21:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7923; q=dns/txt; s=iport; t=1402548879; x=1403758479; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bqDX6NchLskCR5TKo40/5/vKNzs8sU/8dAVd9hDstJs=; b=RNkaSuUd4AG+vlejwNQHujYncDt4Pn4ekeHgHHGMbQm2BBRwg9GHq7rN XmPa9Lgzf6sXKCdJKczr/9WFrLMBZvo+YvNQ8OOcljl8KnfKlhzkYUclB qIY8HWP5Iin+fCWHmx+sUH50Zt+FZM9YVtsQrlAcxjQX6rMRWFUuvXmhm 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFAIgxmVOtJV2d/2dsb2JhbABQBwODDVJWqU4BAQEBAQEFAZFfhzwBgQoWdYQDAQEBAwEBAQE3KwkLBQcECxEEAQEBJwchBh8JCAYTG4gTAwkIDcoVDYYTEwSFXIZagUAHKSMQBwYLgxqBFgSJR3KNfIF5jVCFe4NcHS8 X-IronPort-AV: E=Sophos;i="5.01,462,1400025600"; d="scan'208";a="52340203" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 12 Jun 2014 04:54:38 +0000 Received: from sjc-vpn7-721.cisco.com (sjc-vpn7-721.cisco.com [10.21.146.209]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5C4sbB5004093; Thu, 12 Jun 2014 04:54:38 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dan Wing In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD34914@MX15A.corp.emc.com> Date: Wed, 11 Jun 2014 21:54:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6FCE9946-352C-4174-8760-88BE6A16373C@cisco.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> <94627BFD-C142-4092-BC9D-920B802C01D5@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD34914@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/LnNbfjcoYpFw06ipecUon1WF6w4 Cc: "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 04:54:41 -0000 On Jun 11, 2014, at 7:37 PM, Black, David wrote: >> Is the problem lack of color awareness in the AF remarker, or that AF >> remarkers assume all packets in the 5-tuple have the same color? >=20 > The former, quoting from Section 2.4 of the draft: >=20 > In addition, remarking may remove application-level distinctions in > forwarding behavior - e.g., if multiple PHBs within an AF class are > used to distinguish different types of frames within a video flow, > token-bucket-based remarkers operating in Color-Blind mode (see > [RFC2697] and [RFC2698] for examples) may remark solely based on = flow > rate and burst behavior, removing the drop precedence distinctions > specified by the source. So, from a DSCP perspective, there won't be a problem mixing traffic = needing different DSCP in the same 5-tuple. > Beyond that, if the network that the traffic is entering does not = support > the AF class involved on that ingress, DSCP remarking to zero (best = effort) > is a likely behavior. Sure. Only fix there is to restore the DSCP by some other sort of = signaling. Which means separate 5-tuples (to make such signaling = straight forward) or requiring network gear to peek deeper into the = packets to restore the DSCP bits, such as distinguish STUN/DTLS/RTP = packets from each other, and if RTP to use the solution-de-jour for how = to identify more-important RTP packets from less-important RTP packets = (such as RTP header extension which has been bantered about, or DPI). =20= Hoping DSCP is preserved or re-written without semantic loss seems a = long-dead pipe dream. I would like to work towards solutions that allow = the receiver to indicate their desired behavior for treatment on the = receiver's network, rather than the sender specifying. But probably out = of scope of DART, I suppose. -d >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Wednesday, June 11, 2014 10:00 PM >> To: Black, David >> Cc: dart@ietf.org >> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >>=20 >>=20 >> On Jun 11, 2014, at 5:58 PM, Black, David = wrote: >>=20 >>>> What do you mean by 'all the packets would be classified the same'? = If you >>>> mean all the packets in a 5-tuple would get the same differentiated >> treatment, >>>> that is not desirable, because there are lots of folks wanting to = send >> video >>>> i-frames or packets with FEC or other stuff with lower drop = precedence than >>>> other packets. >>>=20 >>> That would most likely be within an AF class; the entire set of = packets >> marked >>> w/different drop precedences within an AF class should be classified = the >> same. >>>=20 >>> Beyond that, one can hope that any AF remarker (e.g., for traffic = shaping) >> is >>> running in Color-Aware mode and hence tries to preserve source drop >> precedence >>> distinctions, but this cannot be relied upon. >>=20 >> Is the problem lack of color awareness in the AF remarker, or that AF >> remarkers assume all packets in the 5-tuple have the same color? >>=20 >> -d >>=20 >>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Dan Wing [mailto:dwing@cisco.com] >>>> Sent: Wednesday, June 11, 2014 8:32 PM >>>> To: Brian E Carpenter >>>> Cc: Black, David; dart@ietf.org >>>> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >>>>=20 >>>>=20 >>>> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter >> >>>> wrote: >>>>=20 >>>>> On 11/06/2014 07:59, Black, David wrote: >>>>>> In another message, Ruediger Geib asked (>), and I responded: >>>>>>=20 >>>>>> -------------------- >>>>>>=20 >>>>>>> Is the following correct: >>>>>>>=20 >>>>>>> UDP_5-tuple-+--transport protocol 1----- >>>>>>> | >>>>>>> +--RTP session 1----- >>>>>>> | >>>>>>> +--RTP session 2-----+---RTP_stream_2.1 >>>>>>> | >>>>>>> +---RTP_stream_2.2 >>>>>>> |... >>>>>>=20 >>>>>> Yes, that matches my understanding, although the author team = would like >> to >>>>>> see discussion of whether it's a good idea to mix RTP and non-RTP >> protocols >>>>>> on the same 5-tuple - I'll copy your useful diagram into a = separate >> message >>>>>> to start that discussion. >>>>>>=20 >>>>>> -------------------- >>>>>>=20 >>>>>> This is that message, and I want to thank Ruediger for drawing = that >> useful >>>>>> diagram. >>>>>>=20 >>>>>> The author team for draft-york would like input on whether the = draft >> should >>>>>> discuss mixing of RTP and non-RTP traffic on the same UDP = 5-tuple, vs. >>>> using >>>>>> separate 5-tuples (probably separate UDP ports) for RTP and = non-RTP >>>> traffic. >>>>>=20 >>>>> One observation is that we should be thinking about a 6-tuple = these >>>>> days (see RFC 6437). I don't think it makes much difference to the >> argument. >>>>>=20 >>>>> Another observation is when load balancing is in play, things get = a bit >>>>> more complicated, but to a first approximation using the same = 5-tuple >>>>> or 6-tuple will usually ensure that all the packets reach the same >>>>> load-balanced destination, which is probably a good thing. >>>>>=20 >>>>> Third, reverting to the diffserv discussion, the same 5-tuple >>>>> should ensure that all the packets would be classified the same >>>>> (if they cross a diffserv domain boundary and get reclassified). >>>>=20 >>>> What do you mean by 'all the packets would be classified the same'? = If you >>>> mean all the packets in a 5-tuple would get the same differentiated >> treatment, >>>> that is not desirable, because there are lots of folks wanting to = send >> video >>>> i-frames or packets with FEC or other stuff with lower drop = precedence than >>>> other packets. >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>>>=20 >>>>> Brian >>>>>=20 >>>>>>=20 >>>>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on = the same >>>>>> 5-tuple see the last paragraph of Section 3.5 of = draft-ietf-rtcweb- >>>> transports-04: >>>>>>=20 >>>>>> RTCWEB implementations MUST support multiplexing of DTLS and RTP = over >>>>>> the same port pair, as described in the DTLS_SRTP specification >>>>>> [RFC5764], section 5.1.2. All application layer protocol = payloads >>>>>> over this DTLS connection are SCTP packets. >>>>>>=20 >>>>>> OTOH, concerns have been expressed about whether the = not-exactly-elegant >>>>>> demux processing specified in the reference (RFC 5764, Section = 5.1.2) >> ought >>>>>> to be recommended as a good way of doing this multiplexing. >>>>>>=20 >>>>>> Please comment, including whether mixing SCTP and RTP on the same = UDP >>>>>> 5-tuple is a good idea (some rationale for doing this sort of >> multiplexing >>>>>> onto a single 5-tuple can be found in Section 3 of = draft-york-dart-dscp- >>>> rtp-00). >>>>>>=20 >>>>>> Thanks, >>>>>> --David >>>>>> ---------------------------------------------------- >>>>>> David L. Black, Distinguished Engineer >>>>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>>>> ---------------------------------------------------- >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Dart mailing list >>>>>> Dart@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dart >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Dart mailing list >>>>> Dart@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dart >>>=20 >=20 From nobody Thu Jun 12 03:08:26 2014 Return-Path: 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 860A51A0286 for ; Thu, 12 Jun 2014 03:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 1-U2wjDnjBmc for ; Thu, 12 Jun 2014 03:08:21 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435A41B2830 for ; Thu, 12 Jun 2014 03:08:20 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 12 Jun 2014 12:08:07 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 12 Jun 2014 12:08:07 +0200 From: To: , Date: Thu, 12 Jun 2014 12:08:05 +0200 Thread-Topic: [Dart] RTP and non-RTP traffic on same UDP 5-tuple Thread-Index: Ac+F+m/mSow1rHq3Tni8QbdOzYy6eAAGgMcA Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> <94627BFD-C142-4092-BC9D-920B802C01D5@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD34914@MX15A.corp.emc.com> <6FCE9946-352C-4174-8760-88BE6A16373C@cisco.com> In-Reply-To: <6FCE9946-352C-4174-8760-88BE6A16373C@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/i7zt5iqrSwUOyCehZPMEbXQoIEM Cc: dart@ietf.org Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 10:08:24 -0000 Dan, David, as David and Brian pointed out, there are hardly any reliable=20 e2e PHBs/codepoints. To me the DART discussion indicates that we may have to review how we=20 use DiffServ or whether it is currently suitable to serve carrier, service= =20 provider and enterprise network requirements as well as application designe= r=20 requirements simultaneously and deliver useful end to end service. I think= =20 if flexibility is king, then there will be no simple end to end solution=20 (unless tunneling is regarded as simple - and outer header DSCPs still=20 have to make sense then). If we desire e2e QoS and want to have simple=20 solutions, then we need to standardize DiffServ along the full end to end=20 chain to a higher degree than today - but of course respecting the existing= =20 deployments. That means accepting some constraints, but I'd be happy to=20 try that. Regards, Ruediger -----Original Message----- From: Dart [mailto:dart-bounces@ietf.org] on behalf of Dan Wing Sent: Thursday, 12. June 2014 06:55 To: Black, David Cc: dart@ietf.org Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple On Jun 11, 2014, at 7:37 PM, Black, David wrote: >> Is the problem lack of color awareness in the AF remarker, or that AF=20 >> remarkers assume all packets in the 5-tuple have the same color? >=20 > The former, quoting from Section 2.4 of the draft: >=20 > In addition, remarking may remove application-level distinctions in > forwarding behavior - e.g., if multiple PHBs within an AF class are > used to distinguish different types of frames within a video flow, > token-bucket-based remarkers operating in Color-Blind mode (see > [RFC2697] and [RFC2698] for examples) may remark solely based on flow > rate and burst behavior, removing the drop precedence distinctions > specified by the source. So, from a DSCP perspective, there won't be a problem mixing traffic needin= g different DSCP in the same 5-tuple. > Beyond that, if the network that the traffic is entering does not=20 > support the AF class involved on that ingress, DSCP remarking to zero=20 > (best effort) is a likely behavior. Sure. Only fix there is to restore the DSCP by some other sort of signalin= g. Which means separate 5-tuples (to make such signaling straight forward)= or requiring network gear to peek deeper into the packets to restore the D= SCP bits, such as distinguish STUN/DTLS/RTP packets from each other, and if= RTP to use the solution-de-jour for how to identify more-important RTP pac= kets from less-important RTP packets (such as RTP header extension which ha= s been bantered about, or DPI). =20 Hoping DSCP is preserved or re-written without semantic loss seems a long-d= ead pipe dream. I would like to work towards solutions that allow the rece= iver to indicate their desired behavior for treatment on the receiver's net= work, rather than the sender specifying. But probably out of scope of DART= , I suppose. -d >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Wednesday, June 11, 2014 10:00 PM >> To: Black, David >> Cc: dart@ietf.org >> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >>=20 >>=20 >> On Jun 11, 2014, at 5:58 PM, Black, David wrote: >>=20 >>>> What do you mean by 'all the packets would be classified the same'? =20 >>>> If you mean all the packets in a 5-tuple would get the same=20 >>>> differentiated >> treatment, >>>> that is not desirable, because there are lots of folks wanting to=20 >>>> send >> video >>>> i-frames or packets with FEC or other stuff with lower drop=20 >>>> precedence than other packets. >>>=20 >>> That would most likely be within an AF class; the entire set of=20 >>> packets >> marked >>> w/different drop precedences within an AF class should be classified=20 >>> the >> same. >>>=20 >>> Beyond that, one can hope that any AF remarker (e.g., for traffic=20 >>> shaping) >> is >>> running in Color-Aware mode and hence tries to preserve source drop >> precedence >>> distinctions, but this cannot be relied upon. >>=20 >> Is the problem lack of color awareness in the AF remarker, or that AF=20 >> remarkers assume all packets in the 5-tuple have the same color? >>=20 >> -d >>=20 >>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Dan Wing [mailto:dwing@cisco.com] >>>> Sent: Wednesday, June 11, 2014 8:32 PM >>>> To: Brian E Carpenter >>>> Cc: Black, David; dart@ietf.org >>>> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >>>>=20 >>>>=20 >>>> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter >> >>>> wrote: >>>>=20 >>>>> On 11/06/2014 07:59, Black, David wrote: >>>>>> In another message, Ruediger Geib asked (>), and I responded: >>>>>>=20 >>>>>> -------------------- >>>>>>=20 >>>>>>> Is the following correct: >>>>>>>=20 >>>>>>> UDP_5-tuple-+--transport protocol 1----- >>>>>>> | >>>>>>> +--RTP session 1----- >>>>>>> | >>>>>>> +--RTP session 2-----+---RTP_stream_2.1 >>>>>>> | >>>>>>> +---RTP_stream_2.2 >>>>>>> |... >>>>>>=20 >>>>>> Yes, that matches my understanding, although the author team=20 >>>>>> would like >> to >>>>>> see discussion of whether it's a good idea to mix RTP and non-RTP >> protocols >>>>>> on the same 5-tuple - I'll copy your useful diagram into a=20 >>>>>> separate >> message >>>>>> to start that discussion. >>>>>>=20 >>>>>> -------------------- >>>>>>=20 >>>>>> This is that message, and I want to thank Ruediger for drawing=20 >>>>>> that >> useful >>>>>> diagram. >>>>>>=20 >>>>>> The author team for draft-york would like input on whether the=20 >>>>>> draft >> should >>>>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, v= s. >>>> using >>>>>> separate 5-tuples (probably separate UDP ports) for RTP and=20 >>>>>> non-RTP >>>> traffic. >>>>>=20 >>>>> One observation is that we should be thinking about a 6-tuple=20 >>>>> these days (see RFC 6437). I don't think it makes much difference=20 >>>>> to the >> argument. >>>>>=20 >>>>> Another observation is when load balancing is in play, things get=20 >>>>> a bit more complicated, but to a first approximation using the=20 >>>>> same 5-tuple or 6-tuple will usually ensure that all the packets=20 >>>>> reach the same load-balanced destination, which is probably a good th= ing. >>>>>=20 >>>>> Third, reverting to the diffserv discussion, the same 5-tuple=20 >>>>> should ensure that all the packets would be classified the same=20 >>>>> (if they cross a diffserv domain boundary and get reclassified). >>>>=20 >>>> What do you mean by 'all the packets would be classified the same'? =20 >>>> If you mean all the packets in a 5-tuple would get the same=20 >>>> differentiated >> treatment, >>>> that is not desirable, because there are lots of folks wanting to=20 >>>> send >> video >>>> i-frames or packets with FEC or other stuff with lower drop=20 >>>> precedence than other packets. >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>>>=20 >>>>> Brian >>>>>=20 >>>>>>=20 >>>>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on=20 >>>>>> the same 5-tuple see the last paragraph of Section 3.5 of=20 >>>>>> draft-ietf-rtcweb- >>>> transports-04: >>>>>>=20 >>>>>> RTCWEB implementations MUST support multiplexing of DTLS and RTP=20 >>>>>> over the same port pair, as described in the DTLS_SRTP=20 >>>>>> specification [RFC5764], section 5.1.2. All application layer=20 >>>>>> protocol payloads over this DTLS connection are SCTP packets. >>>>>>=20 >>>>>> OTOH, concerns have been expressed about whether the=20 >>>>>> not-exactly-elegant demux processing specified in the reference=20 >>>>>> (RFC 5764, Section 5.1.2) >> ought >>>>>> to be recommended as a good way of doing this multiplexing. >>>>>>=20 >>>>>> Please comment, including whether mixing SCTP and RTP on the same=20 >>>>>> UDP 5-tuple is a good idea (some rationale for doing this sort of >> multiplexing >>>>>> onto a single 5-tuple can be found in Section 3 of=20 >>>>>> draft-york-dart-dscp- >>>> rtp-00). >>>>>>=20 >>>>>> Thanks, >>>>>> --David >>>>>> ---------------------------------------------------- >>>>>> David L. Black, Distinguished Engineer EMC Corporation, 176 South=20 >>>>>> St., Hopkinton, MA 01748 >>>>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>>>> ---------------------------------------------------- >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Dart mailing list >>>>>> Dart@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dart >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Dart mailing list >>>>> Dart@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dart >>>=20 >=20 _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Thu Jun 12 03:47:26 2014 Return-Path: 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 63A281B29E5 for ; Thu, 12 Jun 2014 03:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 0piNiBIohCqn for ; Thu, 12 Jun 2014 03:47:21 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7915A1A0390 for ; Thu, 12 Jun 2014 03:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C92877C3811 for ; Thu, 12 Jun 2014 12:47:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2kSIwsIdWMl for ; Thu, 12 Jun 2014 12:47:20 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0C5D97C3804 for ; Thu, 12 Jun 2014 12:47:20 +0200 (CEST) Message-ID: <53998537.6080700@alvestrand.no> Date: Thu, 12 Jun 2014 12:47:19 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dart@ietf.org References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> <53990684.8050900@gmail.com> In-Reply-To: <53990684.8050900@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/EtUItjXk8HSzcvI3ffGDVinP7Xk Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 10:47:24 -0000 On 06/12/2014 03:46 AM, Brian E Carpenter wrote: > On 12/06/2014 12:58, Black, David wrote: >>> What do you mean by 'all the packets would be classified the same'? If you >>> mean all the packets in a 5-tuple would get the same differentiated treatment, >>> that is not desirable, because there are lots of folks wanting to send video >>> i-frames or packets with FEC or other stuff with lower drop precedence than >>> other packets. >> That would most likely be within an AF class; the entire set of packets marked >> w/different drop precedences within an AF class should be classified the same. >> >> Beyond that, one can hope that any AF remarker (e.g., for traffic shaping) is >> running in Color-Aware mode and hence tries to preserve source drop precedence >> distinctions, but this cannot be relied upon. > Indeed not, and that's on the assumption that the receiving domain > even operates an AF service class. The worst case assumption is > that everything reverts to best effort somewhere along the path. That's a fairly benign case, actually. The worst case is that DSCP priorities get remapped in a way that inverts drop precedence (see the draft's discussion about less-than-best-effort). I hope that's not a case that's so frequent that we have to worry over-much about it. From nobody Thu Jun 12 03:56:10 2014 Return-Path: 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 443C41B29E7 for ; Thu, 12 Jun 2014 03:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 zhe2M1c09k5x for ; Thu, 12 Jun 2014 03:56:06 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541791A0340 for ; Thu, 12 Jun 2014 03:56:06 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 12 Jun 2014 12:56:04 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 12 Jun 2014 12:56:03 +0200 From: To: , Date: Thu, 12 Jun 2014 12:56:03 +0200 Thread-Topic: [Dart] RTP and non-RTP traffic on same UDP 5-tuple Thread-Index: Ac+F+m/mSow1rHq3Tni8QbdOzYy6eAAGgMcA Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> <94627BFD-C142-4092-BC9D-920B802C01D5@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD34914@MX15A.corp.emc.com> <6FCE9946-352C-4174-8760-88BE6A16373C@cisco.com> In-Reply-To: <6FCE9946-352C-4174-8760-88BE6A16373C@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/bfwXpkwW3Y6wBVBwlPPgUiiFPnk Cc: dart@ietf.org Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 10:56:09 -0000 Dan, David, to be a bit more specific about the constraints: if certain PHBs=20 and may be DSCPs are desired, then we will have to standardize=20 them and pay attention to the way they are produced in different=20 network sections along an end to end path. It came to my mind that your draft deals with some DiffServ related=20 constraints and my other mail wasn't explicit. Regards, Ruediger -----Original Message----- From: Dart [mailto:dart-bounces@ietf.org] on behalf of Dan Wing Sent: Thursday, 12. June 2014 06:55 To: Black, David Cc: dart@ietf.org Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple On Jun 11, 2014, at 7:37 PM, Black, David wrote: >> Is the problem lack of color awareness in the AF remarker, or that AF=20 >> remarkers assume all packets in the 5-tuple have the same color? >=20 > The former, quoting from Section 2.4 of the draft: >=20 > In addition, remarking may remove application-level distinctions in > forwarding behavior - e.g., if multiple PHBs within an AF class are > used to distinguish different types of frames within a video flow, > token-bucket-based remarkers operating in Color-Blind mode (see > [RFC2697] and [RFC2698] for examples) may remark solely based on flow > rate and burst behavior, removing the drop precedence distinctions > specified by the source. So, from a DSCP perspective, there won't be a problem mixing traffic needin= g different DSCP in the same 5-tuple. > Beyond that, if the network that the traffic is entering does not=20 > support the AF class involved on that ingress, DSCP remarking to zero=20 > (best effort) is a likely behavior. Sure. Only fix there is to restore the DSCP by some other sort of signalin= g. Which means separate 5-tuples (to make such signaling straight forward)= or requiring network gear to peek deeper into the packets to restore the D= SCP bits, such as distinguish STUN/DTLS/RTP packets from each other, and if= RTP to use the solution-de-jour for how to identify more-important RTP pac= kets from less-important RTP packets (such as RTP header extension which ha= s been bantered about, or DPI). =20 Hoping DSCP is preserved or re-written without semantic loss seems a long-d= ead pipe dream. I would like to work towards solutions that allow the rece= iver to indicate their desired behavior for treatment on the receiver's net= work, rather than the sender specifying. But probably out of scope of DART= , I suppose. -d >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Wednesday, June 11, 2014 10:00 PM >> To: Black, David >> Cc: dart@ietf.org >> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >>=20 >>=20 >> On Jun 11, 2014, at 5:58 PM, Black, David wrote: >>=20 >>>> What do you mean by 'all the packets would be classified the same'? =20 >>>> If you mean all the packets in a 5-tuple would get the same=20 >>>> differentiated >> treatment, >>>> that is not desirable, because there are lots of folks wanting to=20 >>>> send >> video >>>> i-frames or packets with FEC or other stuff with lower drop=20 >>>> precedence than other packets. >>>=20 >>> That would most likely be within an AF class; the entire set of=20 >>> packets >> marked >>> w/different drop precedences within an AF class should be classified=20 >>> the >> same. >>>=20 >>> Beyond that, one can hope that any AF remarker (e.g., for traffic=20 >>> shaping) >> is >>> running in Color-Aware mode and hence tries to preserve source drop >> precedence >>> distinctions, but this cannot be relied upon. >>=20 >> Is the problem lack of color awareness in the AF remarker, or that AF=20 >> remarkers assume all packets in the 5-tuple have the same color? >>=20 >> -d >>=20 >>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Dan Wing [mailto:dwing@cisco.com] >>>> Sent: Wednesday, June 11, 2014 8:32 PM >>>> To: Brian E Carpenter >>>> Cc: Black, David; dart@ietf.org >>>> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >>>>=20 >>>>=20 >>>> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter >> >>>> wrote: >>>>=20 >>>>> On 11/06/2014 07:59, Black, David wrote: >>>>>> In another message, Ruediger Geib asked (>), and I responded: >>>>>>=20 >>>>>> -------------------- >>>>>>=20 >>>>>>> Is the following correct: >>>>>>>=20 >>>>>>> UDP_5-tuple-+--transport protocol 1----- >>>>>>> | >>>>>>> +--RTP session 1----- >>>>>>> | >>>>>>> +--RTP session 2-----+---RTP_stream_2.1 >>>>>>> | >>>>>>> +---RTP_stream_2.2 >>>>>>> |... >>>>>>=20 >>>>>> Yes, that matches my understanding, although the author team=20 >>>>>> would like >> to >>>>>> see discussion of whether it's a good idea to mix RTP and non-RTP >> protocols >>>>>> on the same 5-tuple - I'll copy your useful diagram into a=20 >>>>>> separate >> message >>>>>> to start that discussion. >>>>>>=20 >>>>>> -------------------- >>>>>>=20 >>>>>> This is that message, and I want to thank Ruediger for drawing=20 >>>>>> that >> useful >>>>>> diagram. >>>>>>=20 >>>>>> The author team for draft-york would like input on whether the=20 >>>>>> draft >> should >>>>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, v= s. >>>> using >>>>>> separate 5-tuples (probably separate UDP ports) for RTP and=20 >>>>>> non-RTP >>>> traffic. >>>>>=20 >>>>> One observation is that we should be thinking about a 6-tuple=20 >>>>> these days (see RFC 6437). I don't think it makes much difference=20 >>>>> to the >> argument. >>>>>=20 >>>>> Another observation is when load balancing is in play, things get=20 >>>>> a bit more complicated, but to a first approximation using the=20 >>>>> same 5-tuple or 6-tuple will usually ensure that all the packets=20 >>>>> reach the same load-balanced destination, which is probably a good th= ing. >>>>>=20 >>>>> Third, reverting to the diffserv discussion, the same 5-tuple=20 >>>>> should ensure that all the packets would be classified the same=20 >>>>> (if they cross a diffserv domain boundary and get reclassified). >>>>=20 >>>> What do you mean by 'all the packets would be classified the same'? =20 >>>> If you mean all the packets in a 5-tuple would get the same=20 >>>> differentiated >> treatment, >>>> that is not desirable, because there are lots of folks wanting to=20 >>>> send >> video >>>> i-frames or packets with FEC or other stuff with lower drop=20 >>>> precedence than other packets. >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>>>=20 >>>>> Brian >>>>>=20 >>>>>>=20 >>>>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on=20 >>>>>> the same 5-tuple see the last paragraph of Section 3.5 of=20 >>>>>> draft-ietf-rtcweb- >>>> transports-04: >>>>>>=20 >>>>>> RTCWEB implementations MUST support multiplexing of DTLS and RTP=20 >>>>>> over the same port pair, as described in the DTLS_SRTP=20 >>>>>> specification [RFC5764], section 5.1.2. All application layer=20 >>>>>> protocol payloads over this DTLS connection are SCTP packets. >>>>>>=20 >>>>>> OTOH, concerns have been expressed about whether the=20 >>>>>> not-exactly-elegant demux processing specified in the reference=20 >>>>>> (RFC 5764, Section 5.1.2) >> ought >>>>>> to be recommended as a good way of doing this multiplexing. >>>>>>=20 >>>>>> Please comment, including whether mixing SCTP and RTP on the same=20 >>>>>> UDP 5-tuple is a good idea (some rationale for doing this sort of >> multiplexing >>>>>> onto a single 5-tuple can be found in Section 3 of=20 >>>>>> draft-york-dart-dscp- >>>> rtp-00). >>>>>>=20 >>>>>> Thanks, >>>>>> --David >>>>>> ---------------------------------------------------- >>>>>> David L. Black, Distinguished Engineer EMC Corporation, 176 South=20 >>>>>> St., Hopkinton, MA 01748 >>>>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>>>> ---------------------------------------------------- >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Dart mailing list >>>>>> Dart@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dart >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Dart mailing list >>>>> Dart@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dart >>>=20 >=20 _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Thu Jun 12 04:41:01 2014 Return-Path: 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 088921B2854 for ; Thu, 12 Jun 2014 04:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 cMfgj1BGGYFj for ; Thu, 12 Jun 2014 04:40:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id F1F5E1B2848 for ; Thu, 12 Jun 2014 04:40:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4EC107C3815 for ; Thu, 12 Jun 2014 13:40:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mMLLZy0K12P for ; Thu, 12 Jun 2014 13:40:34 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 50AB47C37F8 for ; Thu, 12 Jun 2014 13:40:34 +0200 (CEST) Message-ID: <539991B1.1020000@alvestrand.no> Date: Thu, 12 Jun 2014 13:40:33 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dart@ietf.org References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> In-Reply-To: <5398BF50.5040604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/jF-7O-STnluWnJdcWV-VZb9K_i0 Subject: [Dart] IPv6 Flow labels? (Re: RTP and non-RTP traffic on same UDP 5-tuple) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 11:40:38 -0000 Brian, you mentioned 6-tuples - with the link you gave, I assume you're talking about IPv6 flow labels. Apart from the issues with remapping, the use of flow labels should have many of the same aspects as the use of DSCP codepoints. Can you give us some idea of how the use (or not) of multiple flow labels within a 5-tuple has been thought about in the IPv6 context? Harald On 06/11/2014 10:42 PM, Brian E Carpenter wrote: > On 11/06/2014 07:59, Black, David wrote: >> In another message, Ruediger Geib asked (>), and I responded: >> >> -------------------- >> >>> Is the following correct: >>> >>> UDP_5-tuple-+--transport protocol 1----- >>> | >>> +--RTP session 1----- >>> | >>> +--RTP session 2-----+---RTP_stream_2.1 >>> | >>> +---RTP_stream_2.2 >>> |... >> Yes, that matches my understanding, although the author team would like to >> see discussion of whether it's a good idea to mix RTP and non-RTP protocols >> on the same 5-tuple - I'll copy your useful diagram into a separate message >> to start that discussion. >> >> -------------------- >> >> This is that message, and I want to thank Ruediger for drawing that useful >> diagram. >> >> The author team for draft-york would like input on whether the draft should >> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, vs. using >> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP traffic. > One observation is that we should be thinking about a 6-tuple these > days (see RFC 6437). I don't think it makes much difference to the argument. > > Another observation is when load balancing is in play, things get a bit > more complicated, but to a first approximation using the same 5-tuple > or 6-tuple will usually ensure that all the packets reach the same > load-balanced destination, which is probably a good thing. > > Third, reverting to the diffserv discussion, the same 5-tuple > should ensure that all the packets would be classified the same > (if they cross a diffserv domain boundary and get reclassified). > > Brian > >> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the same >> 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb-transports-04: >> >> RTCWEB implementations MUST support multiplexing of DTLS and RTP over >> the same port pair, as described in the DTLS_SRTP specification >> [RFC5764], section 5.1.2. All application layer protocol payloads >> over this DTLS connection are SCTP packets. >> >> OTOH, concerns have been expressed about whether the not-exactly-elegant >> demux processing specified in the reference (RFC 5764, Section 5.1.2) ought >> to be recommended as a good way of doing this multiplexing. >> >> Please comment, including whether mixing SCTP and RTP on the same UDP >> 5-tuple is a good idea (some rationale for doing this sort of multiplexing >> onto a single 5-tuple can be found in Section 3 of draft-york-dart-dscp-rtp-00). >> >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> >> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart >> > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Thu Jun 12 05:49:21 2014 Return-Path: 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 DE0681B2A02 for ; Thu, 12 Jun 2014 05:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 kn23kZt9kXze for ; Thu, 12 Jun 2014 05:49:17 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id AB3ED1B29FA for ; Thu, 12 Jun 2014 05:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B88F97C3810 for ; Thu, 12 Jun 2014 14:49:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxLysp7WooDv for ; Thu, 12 Jun 2014 14:49:14 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8B4CE7C380B for ; Thu, 12 Jun 2014 14:49:14 +0200 (CEST) Message-ID: <5399A1C8.7080407@alvestrand.no> Date: Thu, 12 Jun 2014 14:49:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dart@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/E0PsU9zyly41Uwg56pbJzr559Lk Subject: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:49:20 -0000 This message contains running notes made during my initial review of draft-york-dart-dscp-rtp-00. Apologies for lack of organization; it seems better to get them out soon than to polish them. 2 Background "any one or more modalities" -> "one or more modalities" would read better. "RTP defines the mechanism by which real-time data is transmitted" seems like an overreach. "RTP defines a common encapsulation format and handling rules for real-time data transmitted over the Internet" would be more appropriate. "With most applications, a single..." - this is true for legacy. It seems likely not to remain true. The definition of "media flow" needs to be in a "definitions" section. It's too important to be hiding in the "background" section - see much other mail. "SCTP ... can be multiplexed with one or more RTP sessions". Actually we can only multiplex SCTP with a single RTP session. There have been proposals that would allow multiplexing of multiple RTP sessions (each containing multiple media flows) over a single 5-tuple, but these were not accepted. The mention of MediaStream should be removed from bullet 1. It just confuses. In bullet 2, only one RTP session can be multiplexed with another transport protocol (again). The last paragraph is where distinguishing between and is very desirable. As it stands now, it seems simple, but when you start asking what all these flows "are", more precisely, it gets very confusing. 2.1 DiffServ bullet 1, first list: grammar nit - "classify traffic and setting bits" -> "classify traffic and set bits" "In this context, "forwarding behavior" is a general - for example" .... is a general what, exactly? "to allocates resources" -> "to allocate resources" Nit: the all-zero DSCP seems to have only five zeroes. 2.2 Diffserv PHBs do you want to mention what the difference between the 4 AF classes is? Is it just isolation, or is there a ranking between them (in theory or in practice)? 2.3 Diffserv and transport protocols The last paragraph is true but irrelevant - we're not using UDP here, we're using other protocols carried inside UDP. And the stuff that's carried inside UDP may be sensitive to reordering or may be insensitive to reordering - we just can't tell purely from the fact that it's UDP. Suggest deleting the paragraph. IMPORTANT: There is a huge missing section here - which is about sensitivity of real time communications to packet reordering. I'm not sure how much can be said here, but I think this is quite complex: - Packet reordering may lead to spurious NACK generation and unneeded retransmission, just as for the data flow case. How sensitive it is to that depends on timers. - Packet reordering that can be accomodated within an existing jitter buffer will not lead to any quality issues. - Packet reordering that causes jitter buffers to extend is bad news for delay sensitive communication, such as interactive conversations. Interactive implementations may choose to discard late data - but this is a matter of meeting the deadline, not a matter of whether it's reordered. For replay of recorded media, it doesn't matter much. - Packet loss is dealt with differently on interactive media than on reliable data delivery: Instead of retransmissing all lost data, one finds a reference point that new data can be based on, and continues to transmit media relative to that. One does not attempt to recover lost frames that are history. How that affects this discussion ... I'm not too sure. 2.4 DSCP remarking The discussion of token-bucket-based remarkers leaves me a bit confused. To me, it's obvious (?) that token-bucket-based remarkers would operate in color-blind mode on a network boundary, and in color-sensitive mode only when they had assurance that incoming markings were already indicating color. Thus, flows from an end-user system should only hit color-blind remarkers; the real question is: will a color-blind remarker use the incoming DSCP codepoint to decide which of a group of remarking treatments it chooses for the packets? It seems to me that the section should tell me, and it doesn't. 3 RTP Multiplexing Background Repeating the story about "only one RTP session per 5-tuple, please".... 4 Recommendations As discussed above, the first SHOULD NOT (reordering within a media flow) is not sufficiently founded in discussion of media properties. Reordering may be a problem, or it may not be a problem. I don't see any issues with the other recommendations (the second seems like an obvious thing to say, for well documented reasons; the three others seem like no-ops from a practical standpoint). Thanks for getting this out the door! From nobody Thu Jun 12 06:37:37 2014 Return-Path: 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 52A131B2A1C for ; Thu, 12 Jun 2014 06:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 yeQhZ2yUk7An for ; Thu, 12 Jun 2014 06:37:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE3A1A0086 for ; Thu, 12 Jun 2014 06:37:31 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB241.namprd06.prod.outlook.com (10.242.191.148) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 12 Jun 2014 13:37:29 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.221]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.221]) with mapi id 15.00.0954.000; Thu, 12 Jun 2014 13:37:29 +0000 From: Dan York To: Harald Alvestrand Thread-Topic: [Dart] Commentary on draft-york-00 Thread-Index: AQHPhjy9xRFOEIZVUES0uV+hBtb+2ZttenGA Date: Thu, 12 Jun 2014 13:37:28 +0000 Message-ID: <49192580-32A1-4B0A-851C-D139745D97A7@isoc.org> References: <5399A1C8.7080407@alvestrand.no> In-Reply-To: <5399A1C8.7080407@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2604:6000:9fc0:53:801e:5527:2cfe:8df6] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377454003)(24454002)(52604005)(189002)(199002)(164054003)(15975445006)(87936001)(85852003)(4396001)(86362001)(74662001)(64706001)(99286001)(74502001)(31966008)(77982001)(20776003)(46102001)(83072002)(92726001)(92566001)(79102001)(15395725005)(16236675004)(33656002)(2656002)(82746002)(76482001)(15202345003)(81542001)(19580405001)(83322001)(21056001)(19580395003)(76176999)(54356999)(36756003)(50986999)(83716003)(80022001)(99396002)(101416001)(81342001)(104396001)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB241; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: isoc.org does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; Content-Type: multipart/alternative; boundary="_000_4919258032A14B0A851CD139745D97A7isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dart/XcdaAq0R5Q56RgV1HyLONhdxvjE Cc: "dart@ietf.org" Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:37:35 -0000 --_000_4919258032A14B0A851CD139745D97A7isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, Thank you for all the editorial nits and other readability suggestions. I'= ll incorporate those as I make a readability pass through the document. I = agree that a paragraph around the impact of packet re-ordering on RTCWEB wo= uld be useful and I can work on something using your bullets as a base. I will leave responses to your other points to members of the author team w= ho are more knowledgable in those areas than I. Thanks, Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ On Jun 12, 2014, at 8:49 AM, Harald Alvestrand > wrote: This message contains running notes made during my initial review of draft-= york-dart-dscp-rtp-00. Apologies for lack of organization; it seems better to get them out soon th= an to polish them. 2 Background "any one or more modalities" -> "one or more modalities" would read better. "RTP defines the mechanism by which real-time data is transmitted" seems li= ke an overreach. "RTP defines a common encapsulation format and handling ru= les for real-time data transmitted over the Internet" would be more appropr= iate. "With most applications, a single..." - this is true for legacy. It seems l= ikely not to remain true. The definition of "media flow" needs to be in a "definitions" section. It's= too important to be hiding in the "background" section - see much other ma= il. "SCTP ... can be multiplexed with one or more RTP sessions". Actually we ca= n only multiplex SCTP with a single RTP session. There have been proposals = that would allow multiplexing of multiple RTP sessions (each containing mul= tiple media flows) over a single 5-tuple, but these were not accepted. The mention of MediaStream should be removed from bullet 1. It just confuse= s. In bullet 2, only one RTP session can be multiplexed with another transport= protocol (again). The last paragraph is where distinguishing between and is very desirable. As it stands now, it see= ms simple, but when you start asking what all these flows "are", more preci= sely, it gets very confusing. 2.1 DiffServ bullet 1, first list: grammar nit - "classify traffic and setting bits" -> = "classify traffic and set bits" "In this context, "forwarding behavior" is a general - for example" .... is= a general what, exactly? "to allocates resources" -> "to allocate resources" Nit: the all-zero DSCP seems to have only five zeroes. 2.2 Diffserv PHBs do you want to mention what the difference between the 4 AF classes is? Is = it just isolation, or is there a ranking between them (in theory or in prac= tice)? 2.3 Diffserv and transport protocols The last paragraph is true but irrelevant - we're not using UDP here, we're= using other protocols carried inside UDP. And the stuff that's carried ins= ide UDP may be sensitive to reordering or may be insensitive to reordering = - we just can't tell purely from the fact that it's UDP. Suggest deleting the paragraph. IMPORTANT: There is a huge missing section here - which is about sensitivit= y of real time communications to packet reordering. I'm not sure how much can be said here, but I think this is quite complex: - Packet reordering may lead to spurious NACK generation and unneeded retra= nsmission, just as for the data flow case. How sensitive it is to that depe= nds on timers. - Packet reordering that can be accomodated within an existing jitter buffe= r will not lead to any quality issues. - Packet reordering that causes jitter buffers to extend is bad news for de= lay sensitive communication, such as interactive conversations. Interactive= implementations may choose to discard late data - but this is a matter of = meeting the deadline, not a matter of whether it's reordered. For replay of recorded media, it doesn't matter much. - Packet loss is dealt with differently on interactive media than on reliab= le data delivery: Instead of retransmissing all lost data, one finds a refe= rence point that new data can be based on, and continues to transmit media = relative to that. One does not attempt to recover lost frames that are hist= ory. How that affects this discussion ... I'm not too sure. 2.4 DSCP remarking The discussion of token-bucket-based remarkers leaves me a bit confused. To me, it's obvious (?) that token-bucket-based remarkers would operate in = color-blind mode on a network boundary, and in color-sensitive mode only wh= en they had assurance that incoming markings were already indicating color.= Thus, flows from an end-user system should only hit color-blind remarkers;= the real question is: will a color-blind remarker use the incoming DSCP co= depoint to decide which of a group of remarking treatments it chooses for t= he packets? It seems to me that the section should tell me, and it doesn't. 3 RTP Multiplexing Background Repeating the story about "only one RTP session per 5-tuple, please".... 4 Recommendations As discussed above, the first SHOULD NOT (reordering within a media flow) i= s not sufficiently founded in discussion of media properties. Reordering ma= y be a problem, or it may not be a problem. I don't see any issues with the other recommendations (the second seems lik= e an obvious thing to say, for well documented reasons; the three others se= em like no-ops from a practical standpoint). Thanks for getting this out the door! _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart --_000_4919258032A14B0A851CD139745D97A7isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <1E3748495D3CBA45B4F1F67DF67F9BFB@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Harald,

Thank you for all the editorial nits and other readability suggestions= .  I'll incorporate those as I make a readability pass through the doc= ument.  I agree that a paragraph around the impact of packet re-orderi= ng on RTCWEB would be useful and I can work on something using your bullets as a base.

I will leave responses to your other points to members of the author t= eam who are more knowledgable in those areas than I.

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet Socie= ty
york@iso= c.org   +1-802-735-1624
Skype: danyork   http://twitter.com/danyork


On Jun 12, 2014, at 8:49 AM, Harald Alvestrand <harald@alvestrand.no>
 wrote:

This message contains running notes made during m= y initial review of draft-york-dart-dscp-rtp-00.
Apologies for lack of organization; it seems better to get them out soon th= an to polish them.

2 Background

"any one or more modalities" -> "one or more modalities&q= uot; would read better.

"RTP defines the mechanism by which real-time data is transmitted"= ; seems like an overreach. "RTP defines a common encapsulation format = and handling rules for real-time data transmitted over the Internet" w= ould be more appropriate.

"With most applications, a single..." - this is true for legacy. = It seems likely not to remain true.

The definition of "media flow" needs to be in a "definitions= " section. It's too important to be hiding in the "background&quo= t; section - see much other mail.

"SCTP ... can be multiplexed with one or more RTP sessions". Actu= ally we can only multiplex SCTP with a single RTP session. There have been = proposals that would allow multiplexing of multiple RTP sessions (each cont= aining multiple media flows) over a single 5-tuple, but these were not accepted.

The mention of MediaStream should be removed from bullet 1. It just confuse= s.

In bullet 2, only one RTP session can be multiplexed with another transport= protocol (again).

The last paragraph is where distinguishing between <some kind of media r= elated name> and <RTP packet flow> is very desirable. As it stands= now, it seems simple, but when you start asking what all these flows "= ;are", more precisely, it gets very confusing.

2.1 DiffServ

bullet 1, first list: grammar nit - "classify traffic and setting bits= " -> "classify traffic and set bits"

"In this context, "forwarding behavior" is a general - for e= xample" .... is a general what, exactly?

"to allocates resources" -> "to allocate resources"<= br>
Nit: the all-zero DSCP seems to have only five zeroes.

2.2 Diffserv PHBs

do you want to mention what the difference between the 4 AF classes is? Is = it just isolation, or is there a ranking between them (in theory or in prac= tice)?

2.3 Diffserv and transport protocols

The last paragraph is true but irrelevant - we're not using UDP here, we're= using other protocols carried inside UDP. And the stuff that's carried ins= ide UDP may be sensitive to reordering or may be insensitive to reordering = - we just can't tell purely from the fact that it's UDP.

Suggest deleting the paragraph.

IMPORTANT: There is a huge missing section here - which is about sensitivit= y of real time communications to packet reordering.

I'm not sure how much can be said here, but I think this is quite complex:<= br>
- Packet reordering may lead to spurious NACK generation and unneeded retra= nsmission, just as for the data flow case. How sensitive it is to that depe= nds on timers.

- Packet reordering that can be accomodated within an existing jitter buffe= r will not lead to any quality issues.

- Packet reordering that causes jitter buffers to extend is bad news for de= lay sensitive communication, such as interactive conversations. Interactive= implementations may choose to discard late data - but this is a matter of = meeting the deadline, not a matter of whether it's reordered.
For replay of recorded media, it doesn't matter much.

- Packet loss is dealt with differently on interactive media than on reliab= le data delivery: Instead of retransmissing all lost data, one finds a refe= rence point that new data can be based on, and continues to transmit media = relative to that. One does not attempt to recover lost frames that are history.
How that affects this discussion ... I'm not too sure.


2.4 DSCP remarking

The discussion of token-bucket-based remarkers leaves me a bit confused. To me, it's obvious (?) that token-bucket-based remarkers would operate in = color-blind mode on a network boundary, and in color-sensitive mode only wh= en they had assurance that incoming markings were already indicating color.= Thus, flows from an end-user system should only hit color-blind remarkers; the real question is: will a color-= blind remarker use the incoming DSCP codepoint to decide which of a group o= f remarking treatments it chooses for the packets?

It seems to me that the section should tell me, and it doesn't.

3 RTP Multiplexing Background

Repeating the story about "only one RTP session per 5-tuple, please&qu= ot;....

4 Recommendations

As discussed above, the first SHOULD NOT (reordering within a media flow) i= s not sufficiently founded in discussion of media properties. Reordering ma= y be a problem, or it may not be a problem.

I don't see any issues with the other recommendations (the second seems lik= e an obvious thing to say, for well documented reasons; the three others se= em like no-ops from a practical standpoint).

Thanks for getting this out the door!

_______________________________________________
Dart mailing list
Dart@ietf.org
https://www.ietf.org/mailman/listinfo/dart

--_000_4919258032A14B0A851CD139745D97A7isocorg_-- From nobody Thu Jun 12 06:39:19 2014 Return-Path: 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 719A21B2A1C; Thu, 12 Jun 2014 06:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 BqieqdTW9YJ3; Thu, 12 Jun 2014 06:39:14 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A9C1B2A2C; Thu, 12 Jun 2014 06:39:13 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1Wv5Dh-00070y-Jp; Thu, 12 Jun 2014 15:39:09 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id CA6FEA808C0; Thu, 12 Jun 2014 15:39:11 +0200 (CEST) Message-ID: <5399AD7F.20805@kit.edu> Date: Thu, 12 Jun 2014 15:39:11 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1402580349. Archived-At: http://mailarchive.ietf.org/arch/msg/dart/_Hp2TyUupTpLC55NdsSvnFflYuA Cc: dart@ietf.org Subject: [Dart] Comments on draft-ietf-tsvwg-rtcweb-qos-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:39:16 -0000 Hi, some remarks on draft-ietf-tsvwg-rtcweb-qos-00: Sec. 2: The mitigation for such action is through an authorization mechanism. An authorization mechanism alone is probably not sufficient, because DS boundary nodes may need to police (e.g., remark/drop) incoming traffic according to some agreed/negotiated traffic profile for some of the PHBs, e.g., the EF PHB does not work properly if its traffic class is overloaded (see below). Sec. 4: The below uses the concept of a media flow, however these are commonly not equivalent to a transport flow, i.e. as defined by a 5-tuple (source address, destination address, source port, destination port, and protocol). I think one should try to use definitions that do not depend on the classifier type like 5-tuple, because as Brian already mentioned, for IPv6 a 3-tuple (IPsrc, IPdst, Flow Label) may be sufficient and header fields of the 5-tuple are not always accessible. I liked the definition of microflow in DiffServ as being an application-to-application flow of packets, usually being identified by that well known 5-tuple. For elements within the network microflows are usually the most fine grained distinction level for flows (except when you apply multi-field classifier that do some DPI and add the SSRC etc.). (nit: is probably a word like "text" missing in the first cited sentence above?) Proper definitions for media flow, RTP session, transport flow etc. may help to avoid confusion, so maybe one could try to combine efforts with draft-york-dart-dscp-rtp-00? Sec. 5: SHOULD use these values to mark the appropriate media packets. More information on EF can be found in [RFC3246]. More information on AF can be found in [RFC2597]. The problem with using EF is that if too many EF marked packets are injected into a DS domain, they probably void the EF properties for other users within this domain (background is that the service rate of EF packets on a given output interface must exceed their arrival rate at that interface over long and short time intervals - this is usually checked by admission control before use and policing at DS boundary nodes during use). Therefore, maybe some discussion w.r.t. RFC5865 http://tools.ietf.org/html/rfc5865 may be useful. The above table assumes that packets marked with CS1 is treated as "less than best effort". However, the treatment of CS1 is implementation dependent. If an implementation treats CS1 as other than "less than best effort", then the priority of the packets may be changed from what is intended. BTW, there is no "less than best effort" PHB defined, but a Lower Effort Per-Domain Behavior (PDB) in RFC 3662 (http://tools.ietf.org /html/rfc3662). This RFC is also the source for the recommendation of using the CS-1 codepoint for that purpose, so you may considering referencing it. If a packet enters a QoS domain that has no support for the above defined Data Types/Application (service) classes, then the network node at the edge will remark the DSCP value based on policies. Yes, but even if there is support for these classes traffic conditioning (e.g., remarking/dropping etc.) may be necessary and applied. Remarking to different PHBs may also lead to packet reordering within a media flow?! Regards, Roland From nobody Thu Jun 12 07:26:20 2014 Return-Path: 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 EDB9A1A01EB for ; Thu, 12 Jun 2014 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 1eywgtHEmq1y for ; Thu, 12 Jun 2014 07:26:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAF31B29A9 for ; Thu, 12 Jun 2014 07:26:15 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5CEPsvu044619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jun 2014 09:25:57 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell In-Reply-To: <5399A1C8.7080407@alvestrand.no> Date: Thu, 12 Jun 2014 09:25:53 -0500 X-Mao-Original-Outgoing-Id: 424275953.4938-51f376a6275dd767217305bb4dd052ee Content-Transfer-Encoding: quoted-printable Message-Id: <2996CB73-E2E5-4AE9-B602-A5466FD8C445@nostrum.com> References: <5399A1C8.7080407@alvestrand.no> To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/2YNX1nrN_OX3_BR_KqoF3h97fxI Cc: dart@ietf.org Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:26:17 -0000 Thanks Harald! I want to hit one particular comment: On Jun 12, 2014, at 7:49 AM, Harald Alvestrand = wrote: [...] > "SCTP ... can be multiplexed with one or more RTP sessions". Actually = we can only multiplex SCTP with a single RTP session. There have been = proposals that would allow multiplexing of multiple RTP sessions (each = containing multiple media flows) over a single 5-tuple, but these were = not accepted. >=20 >=20 [...] > In bullet 2, only one RTP session can be multiplexed with another = transport protocol (again). [...] Is this a matter of proper definitions of "RTP Session" vs "Media Flow"? = (i.e. properly naming the thing that can be multiplexed?) Or is there a = technical misunderstanding? Ben.= From nobody Thu Jun 12 07:38:57 2014 Return-Path: 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 ACB731A0285 for ; Thu, 12 Jun 2014 07:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no 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 qfpzw89v04i1 for ; Thu, 12 Jun 2014 07:38:52 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D70031B2A5D for ; Thu, 12 Jun 2014 07:38:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 07B967C3813; Thu, 12 Jun 2014 16:38:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kjQUhPltGda; Thu, 12 Jun 2014 16:38:49 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id AF0A67C00DD; Thu, 12 Jun 2014 16:38:49 +0200 (CEST) Message-ID: <5399BB79.9010900@alvestrand.no> Date: Thu, 12 Jun 2014 16:38:49 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ben Campbell References: <5399A1C8.7080407@alvestrand.no> <2996CB73-E2E5-4AE9-B602-A5466FD8C445@nostrum.com> In-Reply-To: <2996CB73-E2E5-4AE9-B602-A5466FD8C445@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/PeXrzbXbbkC9i81Y3qYPK4n_z5Q Cc: dart@ietf.org Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:38:55 -0000 On 06/12/2014 04:25 PM, Ben Campbell wrote: > Thanks Harald! I want to hit one particular comment: > > On Jun 12, 2014, at 7:49 AM, Harald Alvestrand wrote: > > [...] > >> "SCTP ... can be multiplexed with one or more RTP sessions". Actually we can only multiplex SCTP with a single RTP session. There have been proposals that would allow multiplexing of multiple RTP sessions (each containing multiple media flows) over a single 5-tuple, but these were not accepted. >> >> > [...] > >> In bullet 2, only one RTP session can be multiplexed with another transport protocol (again). > [...] > > Is this a matter of proper definitions of "RTP Session" vs "Media Flow"? (i.e. properly naming the thing that can be multiplexed?) Or is there a technical misunderstanding? > > Ben. The word "session" is one of the most horrible words in the vocabulary..... RTP packet streams that are in the same RTP session can be multiplexed over the same 5-tuple. RTP packet streams that are from different RTP sessions cannot. A media flow as you've defined it here (="packet stream" from -taxonomy-) is identified by its SSRC. About "RTP Session", -taxonomy- has this definition: 2.2.2. RTP Session An RTP session is an association among a group of participants communicating with RTP. It is a group communications channel which can potentially carry a number of Packet Streams. Within an RTP session, every participant can find meta-data and control information (over RTCP) about all the Packet Streams in the RTP session. The bandwidth of the RTCP control channel is shared between all participants within an RTP Session. Alternate usages: o Within the context of SDP, a singe m=line can map to a single RTP Session or multiple m=lines can map to a single RTP Session. The latter is enabled via multiplexing schemes such as BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which allows mapping of multiple m=lines to a single RTP Session. Characteristics: o Typically, an RTP Session can carry one ore more Packet Streams. o An RTP Session shares a single SSRC space as defined in RFC3550 [RFC3550]. That is, the End Points participating in an RTP Session can see an SSRC identifier transmitted by any of the other End Points. An End Point can receive an SSRC either as SSRC or as a Contributing source (CSRC) in RTP and RTCP packets, as defined by the endpoints' network interconnection topology. o An RTP Session uses at least two Media Transports (Section 2.1.13), one for sending and one for receiving. Commonly, the receiving one is the reverse direction of the same one as used for sending. An RTP Session may use many Media Transports and these define the session's network interconnection topology. A single Media Transport can normally not transport more than one RTP Session, unless a solution for multiplexing multiple RTP sessions over a single Media Transport is used. One example of such a scheme is Multiple RTP Sessions on a Single Lower-Layer Transport [I-D.westerlund-avtcore-transport-multiplexing]. o Multiple RTP Sessions can be related. About the possibility of putting multiple sessions on a single media transport, -taxonomy- says: 3.4. Multiple RTP Sessions over one Media Transport [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism that allow several RTP Sessions to be carried over a single underlying Media Transport. The main reasons for doing this are related to the impact of using one or more Media Transports. Thus using a common network path or potentially have different ones. There is reduced need for NAT/FW traversal resources and no need for flow based QoS. However, Multiple RTP Sessions over one Media Transport makes it clear that a single Media Transport 5-tuple is not sufficient to express which RTP Session context a particular Packet Stream exists in. Complexities in the relationship between Media Transports and RTP Session already exist as one RTP Session contains multiple Media Transports, e.g. even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing requires two Media Transports, one in each direction. The relationship between Media Transports and RTP Sessions as well as additional levels of identifiers need to be considered in both signaling design and when defining terminology. This is, in my opinion, a very longwinded way of saying "this doesn't exist". The -westerlund- draft expired this April. I have not heard of anyone pursuing it. From nobody Thu Jun 12 07:41:38 2014 Return-Path: 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 1D9E21B2A6B for ; Thu, 12 Jun 2014 07:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 klwVP3olyRea for ; Thu, 12 Jun 2014 07:41:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AE11B2A6A for ; Thu, 12 Jun 2014 07:41:35 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5CEfLt4045881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jun 2014 09:41:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell In-Reply-To: <539904B6.4050803@gmail.com> Date: Thu, 12 Jun 2014 09:41:21 -0500 X-Mao-Original-Outgoing-Id: 424276881.504328-9c38469682cec4988bb1254e8f164469 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <539904B6.4050803@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/a5lJXnXECnk5R8ICGqsT8UcCfWw Cc: "Black, David" , "dart@ietf.org" , Dan Wing Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:41:37 -0000 On Jun 11, 2014, at 8:39 PM, Brian E Carpenter = wrote: >> What do you mean by 'all the packets would be classified the same'? = If you mean all the packets in a 5-tuple would get the same = differentiated treatment, that is not desirable, because there are lots = of folks wanting to send video i-frames or packets with FEC or other = stuff with lower drop precedence than other packets. >=20 > Dan, if a packet crosses a diffserv domain boundary, > the assumption is that (absent a specific SLA) its > DSCP *will* be rewritten in whatever way the classifier > of the receiving domain desires. DSCPs don't have end to > end semantics, unless there is a string of SLAs along > the path that all provide the same DSCP semantics. >=20 > Not everybody likes this, but it was what the operators > in the diffserv WG wanted at the time. >=20 > If all operators agree to implement a common subset of > the DSCPs suggested in various TSVWG documents, there would > be a de facto end to end SLA for those DSCPs. But today, > that's a bit of a dream world. So, for two arbitrary > RTCweb users, there's certainly no assurance that the > DSCP set at the source will be preserved until the > destination. On the contrary, it's quite likely to > be set to zero (at the boundary of an operator that > distrusts the DSCP field) or to a value deemed suitable > by an ingress classifier for whatever 5-tuple it carries. > It seems unlikely that a classifier will look further > into the payload than the port numbers. I think I understand your meaning, but just to be sure: Even if the packets with the same 5-tuple have different DSCPs, the are = likely to get reset to the same DSCP (probably zero) at a boundary, = because the classifier either ignores or distrusts the original markings = entirely? (As opposed to remapping any given DSCP to a different DSCP, = but maintaining some distinction within the flow.) Thanks! Ben.= From nobody Thu Jun 12 08:25:01 2014 Return-Path: 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 2A7D01B2A75 for ; Thu, 12 Jun 2014 08:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 F-EtCMhonAqS for ; Thu, 12 Jun 2014 08:24:48 -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 0E9981B2A24 for ; Thu, 12 Jun 2014 08:24:47 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5CFOjqK029715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 11:24:46 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s5CFOjqK029715 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402586686; bh=7VUTWjIpyw83BAafca9hc8+HxUo=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IVdCp/nVu4CAj2ESliyV3iwMO7k1VFGL7f5GSQy81ijWUcUPEgEPvw+tYrA7z4kdB UlUNxiNDlM9NZpslh1ORpHK0cpGG7s3GApA9clFn9BMbP1rlbE1DBPCG8bD+XDLGfX XOeNuomLi2GIbdGvVn4+BrYvs0nvg1kkXLKy8X7I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s5CFOjqK029715 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 12 Jun 2014 08:24:29 -0700 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5CFOSCv013855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 11:24:28 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Thu, 12 Jun 2014 11:24:28 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Thu, 12 Jun 2014 11:24:25 -0400 Thread-Topic: [Dart] RTP and non-RTP traffic on same UDP 5-tuple Thread-Index: Ac+F+m/mSow1rHq3Tni8QbdOzYy6eAAGgMcAAA9LGWA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FF2664B@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> <94627BFD-C142-4092-BC9D-920B802C01D5@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD34914@MX15A.corp.emc.com> <6FCE9946-352C-4174-8760-88BE6A16373C@cisco.com> In-Reply-To: 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: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public, GIS Solicitation Archived-At: http://mailarchive.ietf.org/arch/msg/dart/a09BvUOy7DD28MStI_uMJFto5Gs Cc: "dart@ietf.org" Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:24:55 -0000 Ruediger, > to be a bit more specific about the constraints: if certain PHBs > and may be DSCPs are desired, then we will have to standardize > them and pay attention to the way they are produced in different > network sections along an end to end path. I agree, but that's not going to happen as part of this dart work - PHBs and DSCPs are not end-to-end as things stand, and the dart WG goal as I understand it is to describe how things work today and provide guidance on what to do and not do in using PHBs/DSCPs at endpoints to minimize surprises. In preliminary discussions in London that lead to forming the dart WG, some of the RAI & RTCWEB folks were ok with the QoS differentiation getting removed by the network (e.g., by a diffserv edge node that remarks all of the traffic involved to best effort (DF)) - if the original differentiation survives a hop or a few hops from a residential subscriber, their view was that it probably provides some benefits.=20 Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of > Ruediger.Geib@telekom.de > Sent: Thursday, June 12, 2014 6:56 AM > To: dwing@cisco.com; Black, David > Cc: dart@ietf.org > Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >=20 > Dan, David, >=20 > to be a bit more specific about the constraints: if certain PHBs > and may be DSCPs are desired, then we will have to standardize > them and pay attention to the way they are produced in different > network sections along an end to end path. >=20 > It came to my mind that your draft deals with some DiffServ related > constraints and my other mail wasn't explicit. >=20 > Regards, >=20 > Ruediger >=20 >=20 > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] on behalf of Dan Wing > Sent: Thursday, 12. June 2014 06:55 > To: Black, David > Cc: dart@ietf.org > Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple >=20 >=20 > On Jun 11, 2014, at 7:37 PM, Black, David wrote: >=20 > >> Is the problem lack of color awareness in the AF remarker, or that AF > >> remarkers assume all packets in the 5-tuple have the same color? > > > > The former, quoting from Section 2.4 of the draft: > > > > In addition, remarking may remove application-level distinctions in > > forwarding behavior - e.g., if multiple PHBs within an AF class are > > used to distinguish different types of frames within a video flow, > > token-bucket-based remarkers operating in Color-Blind mode (see > > [RFC2697] and [RFC2698] for examples) may remark solely based on flow > > rate and burst behavior, removing the drop precedence distinctions > > specified by the source. >=20 > So, from a DSCP perspective, there won't be a problem mixing traffic need= ing > different DSCP in the same 5-tuple. >=20 > > Beyond that, if the network that the traffic is entering does not > > support the AF class involved on that ingress, DSCP remarking to zero > > (best effort) is a likely behavior. >=20 > Sure. Only fix there is to restore the DSCP by some other sort of signal= ing. > Which means separate 5-tuples (to make such signaling straight forward) o= r > requiring network gear to peek deeper into the packets to restore the DSC= P > bits, such as distinguish STUN/DTLS/RTP packets from each other, and if R= TP to > use the solution-de-jour for how to identify more-important RTP packets f= rom > less-important RTP packets (such as RTP header extension which has been > bantered about, or DPI). >=20 > Hoping DSCP is preserved or re-written without semantic loss seems a long= -dead > pipe dream. I would like to work towards solutions that allow the receiv= er to > indicate their desired behavior for treatment on the receiver's network, > rather than the sender specifying. But probably out of scope of DART, I > suppose. >=20 > -d >=20 >=20 >=20 > > > > Thanks, > > --David > > > > > >> -----Original Message----- > >> From: Dan Wing [mailto:dwing@cisco.com] > >> Sent: Wednesday, June 11, 2014 10:00 PM > >> To: Black, David > >> Cc: dart@ietf.org > >> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple > >> > >> > >> On Jun 11, 2014, at 5:58 PM, Black, David wrote: > >> > >>>> What do you mean by 'all the packets would be classified the same'? > >>>> If you mean all the packets in a 5-tuple would get the same > >>>> differentiated > >> treatment, > >>>> that is not desirable, because there are lots of folks wanting to > >>>> send > >> video > >>>> i-frames or packets with FEC or other stuff with lower drop > >>>> precedence than other packets. > >>> > >>> That would most likely be within an AF class; the entire set of > >>> packets > >> marked > >>> w/different drop precedences within an AF class should be classified > >>> the > >> same. > >>> > >>> Beyond that, one can hope that any AF remarker (e.g., for traffic > >>> shaping) > >> is > >>> running in Color-Aware mode and hence tries to preserve source drop > >> precedence > >>> distinctions, but this cannot be relied upon. > >> > >> Is the problem lack of color awareness in the AF remarker, or that AF > >> remarkers assume all packets in the 5-tuple have the same color? > >> > >> -d > >> > >> > >>> Thanks, > >>> --David > >>> > >>>> -----Original Message----- > >>>> From: Dan Wing [mailto:dwing@cisco.com] > >>>> Sent: Wednesday, June 11, 2014 8:32 PM > >>>> To: Brian E Carpenter > >>>> Cc: Black, David; dart@ietf.org > >>>> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple > >>>> > >>>> > >>>> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter > >> > >>>> wrote: > >>>> > >>>>> On 11/06/2014 07:59, Black, David wrote: > >>>>>> In another message, Ruediger Geib asked (>), and I responded: > >>>>>> > >>>>>> -------------------- > >>>>>> > >>>>>>> Is the following correct: > >>>>>>> > >>>>>>> UDP_5-tuple-+--transport protocol 1----- > >>>>>>> | > >>>>>>> +--RTP session 1----- > >>>>>>> | > >>>>>>> +--RTP session 2-----+---RTP_stream_2.1 > >>>>>>> | > >>>>>>> +---RTP_stream_2.2 > >>>>>>> |... > >>>>>> > >>>>>> Yes, that matches my understanding, although the author team > >>>>>> would like > >> to > >>>>>> see discussion of whether it's a good idea to mix RTP and non-RTP > >> protocols > >>>>>> on the same 5-tuple - I'll copy your useful diagram into a > >>>>>> separate > >> message > >>>>>> to start that discussion. > >>>>>> > >>>>>> -------------------- > >>>>>> > >>>>>> This is that message, and I want to thank Ruediger for drawing > >>>>>> that > >> useful > >>>>>> diagram. > >>>>>> > >>>>>> The author team for draft-york would like input on whether the > >>>>>> draft > >> should > >>>>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple,= vs. > >>>> using > >>>>>> separate 5-tuples (probably separate UDP ports) for RTP and > >>>>>> non-RTP > >>>> traffic. > >>>>> > >>>>> One observation is that we should be thinking about a 6-tuple > >>>>> these days (see RFC 6437). I don't think it makes much difference > >>>>> to the > >> argument. > >>>>> > >>>>> Another observation is when load balancing is in play, things get > >>>>> a bit more complicated, but to a first approximation using the > >>>>> same 5-tuple or 6-tuple will usually ensure that all the packets > >>>>> reach the same load-balanced destination, which is probably a good > thing. > >>>>> > >>>>> Third, reverting to the diffserv discussion, the same 5-tuple > >>>>> should ensure that all the packets would be classified the same > >>>>> (if they cross a diffserv domain boundary and get reclassified). > >>>> > >>>> What do you mean by 'all the packets would be classified the same'? > >>>> If you mean all the packets in a 5-tuple would get the same > >>>> differentiated > >> treatment, > >>>> that is not desirable, because there are lots of folks wanting to > >>>> send > >> video > >>>> i-frames or packets with FEC or other stuff with lower drop > >>>> precedence than other packets. > >>>> > >>>> -d > >>>> > >>>> > >>>>> > >>>>> Brian > >>>>> > >>>>>> > >>>>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on > >>>>>> the same 5-tuple see the last paragraph of Section 3.5 of > >>>>>> draft-ietf-rtcweb- > >>>> transports-04: > >>>>>> > >>>>>> RTCWEB implementations MUST support multiplexing of DTLS and RTP > >>>>>> over the same port pair, as described in the DTLS_SRTP > >>>>>> specification [RFC5764], section 5.1.2. All application layer > >>>>>> protocol payloads over this DTLS connection are SCTP packets. > >>>>>> > >>>>>> OTOH, concerns have been expressed about whether the > >>>>>> not-exactly-elegant demux processing specified in the reference > >>>>>> (RFC 5764, Section 5.1.2) > >> ought > >>>>>> to be recommended as a good way of doing this multiplexing. > >>>>>> > >>>>>> Please comment, including whether mixing SCTP and RTP on the same > >>>>>> UDP 5-tuple is a good idea (some rationale for doing this sort of > >> multiplexing > >>>>>> onto a single 5-tuple can be found in Section 3 of > >>>>>> draft-york-dart-dscp- > >>>> rtp-00). > >>>>>> > >>>>>> Thanks, > >>>>>> --David > >>>>>> ---------------------------------------------------- > >>>>>> David L. Black, Distinguished Engineer EMC Corporation, 176 South > >>>>>> St., Hopkinton, MA 01748 > >>>>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >>>>>> david.black@emc.com Mobile: +1 (978) 394-7754 > >>>>>> ---------------------------------------------------- > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Dart mailing list > >>>>>> Dart@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/dart > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Dart mailing list > >>>>> Dart@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dart > >>> > > >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Thu Jun 12 08:57:54 2014 Return-Path: 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 57CA71B2AA4 for ; Thu, 12 Jun 2014 08:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 o5hOyJ7ZlbJB for ; Thu, 12 Jun 2014 08:57:47 -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 1E4D01B2A70 for ; Thu, 12 Jun 2014 08:57:46 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5CFvdAi006504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 11:57:43 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s5CFvdAi006504 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402588663; bh=WuV0oqAR9zIdA5Sme8cVejvw49Q=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=U/ljZHQ0e5dyIaUe1vN4XWhwnOHB9sqlDmLTXE4zSAOaN/7+gLUldzMSo0pkF8Rul XJigpKHN45GkB3Ha8fefJUIO0HKpixholsssfmDX0dH9Ap6HCEeM+4pv8kHIQtyPsC 5+FmQarx/fHyc7blaejTEyvQ+XWAxeqXRijpYWUg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s5CFvdAi006504 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd04.lss.emc.com (RSA Interceptor); Thu, 12 Jun 2014 08:57:21 -0700 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5CFvHvw020136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 11:57:20 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Thu, 12 Jun 2014 11:57:17 -0400 From: "Black, David" To: Harald Alvestrand , Ben Campbell Date: Thu, 12 Jun 2014 11:57:16 -0400 Thread-Topic: [Dart] Commentary on draft-york-00 Thread-Index: Ac+GTBMa1MWNRZoIRFOAI6b/MSQV1AACdh4Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FF26661@MX15A.corp.emc.com> References: <5399A1C8.7080407@alvestrand.no> <2996CB73-E2E5-4AE9-B602-A5466FD8C445@nostrum.com> <5399BB79.9010900@alvestrand.no> In-Reply-To: <5399BB79.9010900@alvestrand.no> 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: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/8qhEvQMD_bvoKJGdWUs4JMNzOTk Cc: "dart@ietf.org" Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:57:49 -0000 Harald, This explanation helps (thank you): > 3.4. Multiple RTP Sessions over one Media Transport >=20 > [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism > that allow several RTP Sessions to be carried over a single > underlying Media Transport. [... snip ...] > The -westerlund- draft expired this April. I have not heard of anyone > pursuing it. I believe that the westerlund-avtcore draft was the indirect source of draft-york's assertion that multiple RTP sessions could be mixed on a single 5-tuple. In correcting that statement to say that RTP sessions cannot be mixed on a UDP 5-tuple, would it be reasonable to make note of that expired draft's proposal, possibly via a reference to the avtext-taxonomy draft? Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Thursday, June 12, 2014 10:39 AM > To: Ben Campbell > Cc: dart@ietf.org > Subject: Re: [Dart] Commentary on draft-york-00 >=20 > On 06/12/2014 04:25 PM, Ben Campbell wrote: > > Thanks Harald! I want to hit one particular comment: > > > > On Jun 12, 2014, at 7:49 AM, Harald Alvestrand w= rote: > > > > [...] > > > >> "SCTP ... can be multiplexed with one or more RTP sessions". Actually = we > can only multiplex SCTP with a single RTP session. There have been propos= als > that would allow multiplexing of multiple RTP sessions (each containing > multiple media flows) over a single 5-tuple, but these were not accepted. > >> > >> > > [...] > > > >> In bullet 2, only one RTP session can be multiplexed with another tran= sport > protocol (again). > > [...] > > > > Is this a matter of proper definitions of "RTP Session" vs "Media Flow"= ? > (i.e. properly naming the thing that can be multiplexed?) Or is there a > technical misunderstanding? > > > > Ben. > The word "session" is one of the most horrible words in the vocabulary...= .. >=20 > RTP packet streams that are in the same RTP session can be multiplexed > over the same 5-tuple. > RTP packet streams that are from different RTP sessions cannot. >=20 > A media flow as you've defined it here (=3D"packet stream" from > -taxonomy-) is identified by its SSRC. >=20 > About "RTP Session", -taxonomy- has this definition: >=20 > 2.2.2. RTP Session >=20 > An RTP session is an association among a group of participants > communicating with RTP. It is a group communications channel which > can potentially carry a number of Packet Streams. Within an RTP > session, every participant can find meta-data and control information > (over RTCP) about all the Packet Streams in the RTP session. The > bandwidth of the RTCP control channel is shared between all > participants within an RTP Session. >=20 > Alternate usages: >=20 > o Within the context of SDP, a singe m=3Dline can map to a single RT= P > Session or multiple m=3Dlines can map to a single RTP Session. The > latter is enabled via multiplexing schemes such as BUNDLE > [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which > allows mapping of multiple m=3Dlines to a single RTP Session. >=20 > Characteristics: >=20 > o Typically, an RTP Session can carry one ore more Packet Streams. >=20 > o An RTP Session shares a single SSRC space as defined in RFC3550 > [RFC3550]. That is, the End Points participating in an RTP > Session can see an SSRC identifier transmitted by any of the other > End Points. An End Point can receive an SSRC either as SSRC or as > a Contributing source (CSRC) in RTP and RTCP packets, as defined > by the endpoints' network interconnection topology. >=20 > o An RTP Session uses at least two Media Transports > (Section 2.1.13), one for sending and one for receiving. > Commonly, the receiving one is the reverse direction of the same > one as used for sending. An RTP Session may use many Media > Transports and these define the session's network interconnection > topology. A single Media Transport can normally not transport > more than one RTP Session, unless a solution for multiplexing > multiple RTP sessions over a single Media Transport is used. One > example of such a scheme is Multiple RTP Sessions on a Single > Lower-Layer Transport > [I-D.westerlund-avtcore-transport-multiplexing]. >=20 > o Multiple RTP Sessions can be related. >=20 > About the possibility of putting multiple sessions on a single media > transport, -taxonomy- says: >=20 > 3.4. Multiple RTP Sessions over one Media Transport >=20 > [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism > that allow several RTP Sessions to be carried over a single > underlying Media Transport. The main reasons for doing this are > related to the impact of using one or more Media Transports. Thus > using a common network path or potentially have different ones. > There is reduced need for NAT/FW traversal resources and no need for > flow based QoS. >=20 > However, Multiple RTP Sessions over one Media Transport makes it > clear that a single Media Transport 5-tuple is not sufficient to > express which RTP Session context a particular Packet Stream exists > in. Complexities in the relationship between Media Transports and > RTP Session already exist as one RTP Session contains multiple Media > Transports, e.g. even a Peer-to-Peer RTP Session with RTP/RTCP > Multiplexing requires two Media Transports, one in each direction. > The relationship between Media Transports and RTP Sessions as well as > additional levels of identifiers need to be considered in both > signaling design and when defining terminology. >=20 > This is, in my opinion, a very longwinded way of saying "this doesn't > exist". >=20 > The -westerlund- draft expired this April. I have not heard of anyone > pursuing it. >=20 >=20 >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Thu Jun 12 11:19:59 2014 Return-Path: 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 04F0F1B27C7 for ; Thu, 12 Jun 2014 11:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no 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 AcHANBfzagVZ for ; Thu, 12 Jun 2014 11:19:55 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 81A421B27BB for ; Thu, 12 Jun 2014 11:19:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D32477C3818; Thu, 12 Jun 2014 20:19:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwgiqTqjmDi2; Thu, 12 Jun 2014 20:19:53 +0200 (CEST) Received: from [172.30.42.85] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 876197C3814; Thu, 12 Jun 2014 20:19:53 +0200 (CEST) Message-ID: <5399EF49.8020107@alvestrand.no> Date: Thu, 12 Jun 2014 20:19:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" , Ben Campbell References: <5399A1C8.7080407@alvestrand.no> <2996CB73-E2E5-4AE9-B602-A5466FD8C445@nostrum.com> <5399BB79.9010900@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712076FF26661@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FF26661@MX15A.corp.emc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/RpylR4YiDQTn4q8CY-m2dhIGkpQ Cc: "dart@ietf.org" Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:19:58 -0000 On 06/12/2014 05:57 PM, Black, David wrote: > Harald, > > This explanation helps (thank you): > >> 3.4. Multiple RTP Sessions over one Media Transport >> >> [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism >> that allow several RTP Sessions to be carried over a single >> underlying Media Transport. > [... snip ...] > >> The -westerlund- draft expired this April. I have not heard of anyone >> pursuing it. > I believe that the westerlund-avtcore draft was the indirect source of > draft-york's assertion that multiple RTP sessions could be mixed on a > single 5-tuple. In correcting that statement to say that RTP sessions > cannot be mixed on a UDP 5-tuple, would it be reasonable to make note > of that expired draft's proposal, possibly via a reference to the > avtext-taxonomy draft? I'd ask the chairs of avtext / avtcore for guidance on that. If they don't see any more action on this front in the near future, I would prefer to say as little as possible about the possibility - it might happen in the future, it might not happen at all, or it might happen in a fashion which makes whatever we say about it now be wrong. If they don't see any action happening in the near future, the reference should be removed from -taxonomy- too, of course. > > Thanks, > --David > > >> -----Original Message----- >> From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: Thursday, June 12, 2014 10:39 AM >> To: Ben Campbell >> Cc: dart@ietf.org >> Subject: Re: [Dart] Commentary on draft-york-00 >> >> On 06/12/2014 04:25 PM, Ben Campbell wrote: >>> Thanks Harald! I want to hit one particular comment: >>> >>> On Jun 12, 2014, at 7:49 AM, Harald Alvestrand wrote: >>> >>> [...] >>> >>>> "SCTP ... can be multiplexed with one or more RTP sessions". Actually we >> can only multiplex SCTP with a single RTP session. There have been proposals >> that would allow multiplexing of multiple RTP sessions (each containing >> multiple media flows) over a single 5-tuple, but these were not accepted. >>>> >>> [...] >>> >>>> In bullet 2, only one RTP session can be multiplexed with another transport >> protocol (again). >>> [...] >>> >>> Is this a matter of proper definitions of "RTP Session" vs "Media Flow"? >> (i.e. properly naming the thing that can be multiplexed?) Or is there a >> technical misunderstanding? >>> Ben. >> The word "session" is one of the most horrible words in the vocabulary..... >> >> RTP packet streams that are in the same RTP session can be multiplexed >> over the same 5-tuple. >> RTP packet streams that are from different RTP sessions cannot. >> >> A media flow as you've defined it here (="packet stream" from >> -taxonomy-) is identified by its SSRC. >> >> About "RTP Session", -taxonomy- has this definition: >> >> 2.2.2. RTP Session >> >> An RTP session is an association among a group of participants >> communicating with RTP. It is a group communications channel which >> can potentially carry a number of Packet Streams. Within an RTP >> session, every participant can find meta-data and control information >> (over RTCP) about all the Packet Streams in the RTP session. The >> bandwidth of the RTCP control channel is shared between all >> participants within an RTP Session. >> >> Alternate usages: >> >> o Within the context of SDP, a singe m=line can map to a single RTP >> Session or multiple m=lines can map to a single RTP Session. The >> latter is enabled via multiplexing schemes such as BUNDLE >> [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which >> allows mapping of multiple m=lines to a single RTP Session. >> >> Characteristics: >> >> o Typically, an RTP Session can carry one ore more Packet Streams. >> >> o An RTP Session shares a single SSRC space as defined in RFC3550 >> [RFC3550]. That is, the End Points participating in an RTP >> Session can see an SSRC identifier transmitted by any of the other >> End Points. An End Point can receive an SSRC either as SSRC or as >> a Contributing source (CSRC) in RTP and RTCP packets, as defined >> by the endpoints' network interconnection topology. >> >> o An RTP Session uses at least two Media Transports >> (Section 2.1.13), one for sending and one for receiving. >> Commonly, the receiving one is the reverse direction of the same >> one as used for sending. An RTP Session may use many Media >> Transports and these define the session's network interconnection >> topology. A single Media Transport can normally not transport >> more than one RTP Session, unless a solution for multiplexing >> multiple RTP sessions over a single Media Transport is used. One >> example of such a scheme is Multiple RTP Sessions on a Single >> Lower-Layer Transport >> [I-D.westerlund-avtcore-transport-multiplexing]. >> >> o Multiple RTP Sessions can be related. >> >> About the possibility of putting multiple sessions on a single media >> transport, -taxonomy- says: >> >> 3.4. Multiple RTP Sessions over one Media Transport >> >> [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism >> that allow several RTP Sessions to be carried over a single >> underlying Media Transport. The main reasons for doing this are >> related to the impact of using one or more Media Transports. Thus >> using a common network path or potentially have different ones. >> There is reduced need for NAT/FW traversal resources and no need for >> flow based QoS. >> >> However, Multiple RTP Sessions over one Media Transport makes it >> clear that a single Media Transport 5-tuple is not sufficient to >> express which RTP Session context a particular Packet Stream exists >> in. Complexities in the relationship between Media Transports and >> RTP Session already exist as one RTP Session contains multiple Media >> Transports, e.g. even a Peer-to-Peer RTP Session with RTP/RTCP >> Multiplexing requires two Media Transports, one in each direction. >> The relationship between Media Transports and RTP Sessions as well as >> additional levels of identifiers need to be considered in both >> signaling design and when defining terminology. >> >> This is, in my opinion, a very longwinded way of saying "this doesn't >> exist". >> >> The -westerlund- draft expired this April. I have not heard of anyone >> pursuing it. >> >> >> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart -- Surveillance is pervasive. Go Dark. From nobody Thu Jun 12 13:12:54 2014 Return-Path: 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 64F501A024F for ; Thu, 12 Jun 2014 13:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 bIMj1BM2CJdO for ; Thu, 12 Jun 2014 13:12:49 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536811A01D6 for ; Thu, 12 Jun 2014 13:12:47 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id ma3so1116489pbc.29 for ; Thu, 12 Jun 2014 13:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tMwz+Vd6SOKVkbNbJvz0Jjixu91UXcyNSq6tlq97ed0=; b=kK0VP6+tGgECBPEmlQ7Im4HlJgWNzXY1I86zFNvamtnQ/9ChRyeZpTlXMCw6Zj3Nx5 wqYbfcXa1NzLcJ2Gi2cpnIpvadtXCGirCxaQnmxCFXoI18SPS4iG9/NcXn+ovlRWawPd ykG8dhN5fiiljpJ/iEoEMV4ddH5f4lDE03vLiggAYZTIt/tCg30hCU653mTrX96rONAd mIC8vNMxNxxwUps5Z/dAM6TkThf/wNJPpAqISyXibT1evHNXp2Wr7WDqClIxNJc6I3Ca n1C7q4IkFIx3tmL0GbpTV3UwpOe9svcZFaaQKjyym/1kR0aNTd0nNedCT3pmWdTgXc6a AhOQ== X-Received: by 10.66.197.131 with SMTP id iu3mr24043041pac.102.1402603966987; Thu, 12 Jun 2014 13:12:46 -0700 (PDT) Received: from [192.168.178.23] (148.200.69.111.dynamic.snap.net.nz. [111.69.200.148]) by mx.google.com with ESMTPSA id it4sm81930576pbc.39.2014.06.12.13.12.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 13:12:46 -0700 (PDT) Message-ID: <539A09C6.8030200@gmail.com> Date: Fri, 13 Jun 2014 08:12:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Harald Alvestrand References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <539991B1.1020000@alvestrand.no> In-Reply-To: <539991B1.1020000@alvestrand.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/EoHmTiAehT7cI6uZAJN1Oc2sp7A Cc: dart@ietf.org Subject: Re: [Dart] IPv6 Flow labels? (Re: RTP and non-RTP traffic on same UDP 5-tuple) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 20:12:51 -0000 Hi Harald, On 12/06/2014 23:40, Harald Alvestrand wrote: > Brian, > > you mentioned 6-tuples - with the link you gave, I assume you're talking > about IPv6 flow labels. > > Apart from the issues with remapping, the use of flow labels should have > many of the same aspects as the use of DSCP codepoints. > > Can you give us some idea of how the use (or not) of multiple flow > labels within a 5-tuple has been thought about in the IPv6 context? It hasn't, because the model is that the label will be the same for all packets in a given flow, and a flow is usually assumed to be identified by its 5-tuple. But there are words at the very beginning of RFC 6437 that intentionally leave room for breaking that assumption: > 1. Introduction > > From the viewpoint of the network layer, a flow is a sequence of > packets sent from a particular source to a particular unicast, > anycast, or multicast destination that a node desires to label as a > flow. From an upper-layer viewpoint, a flow could consist of all > packets in one direction of a specific transport connection or media > stream. However, a flow is not necessarily 1:1 mapped to a transport > connection. So the door is open for multiple labels for the same 5-tuple, but always remembering that the label might be used as part of a load-balancing mechanism (as discussed in RFC 6438 and RFC 7098). Also, here's the bad news, remapping cannot be completely excluded for the flow label. See http://tools.ietf.org/html/rfc6437#section-6 and in particular http://tools.ietf.org/html/rfc6437#section-6.1 Brian > > Harald > > > On 06/11/2014 10:42 PM, Brian E Carpenter wrote: >> On 11/06/2014 07:59, Black, David wrote: >>> In another message, Ruediger Geib asked (>), and I responded: >>> >>> -------------------- >>> >>>> Is the following correct: >>>> >>>> UDP_5-tuple-+--transport protocol 1----- >>>> | >>>> +--RTP session 1----- >>>> | >>>> +--RTP session 2-----+---RTP_stream_2.1 >>>> | >>>> +---RTP_stream_2.2 >>>> |... >>> Yes, that matches my understanding, although the author team would >>> like to >>> see discussion of whether it's a good idea to mix RTP and non-RTP >>> protocols >>> on the same 5-tuple - I'll copy your useful diagram into a separate >>> message >>> to start that discussion. >>> >>> -------------------- >>> >>> This is that message, and I want to thank Ruediger for drawing that >>> useful >>> diagram. >>> >>> The author team for draft-york would like input on whether the draft >>> should >>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, >>> vs. using >>> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP >>> traffic. >> One observation is that we should be thinking about a 6-tuple these >> days (see RFC 6437). I don't think it makes much difference to the >> argument. >> >> Another observation is when load balancing is in play, things get a bit >> more complicated, but to a first approximation using the same 5-tuple >> or 6-tuple will usually ensure that all the packets reach the same >> load-balanced destination, which is probably a good thing. >> >> Third, reverting to the diffserv discussion, the same 5-tuple >> should ensure that all the packets would be classified the same >> (if they cross a diffserv domain boundary and get reclassified). >> >> Brian >> >>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the >>> same >>> 5-tuple see the last paragraph of Section 3.5 of >>> draft-ietf-rtcweb-transports-04: >>> >>> RTCWEB implementations MUST support multiplexing of DTLS and RTP >>> over >>> the same port pair, as described in the DTLS_SRTP specification >>> [RFC5764], section 5.1.2. All application layer protocol payloads >>> over this DTLS connection are SCTP packets. >>> >>> OTOH, concerns have been expressed about whether the not-exactly-elegant >>> demux processing specified in the reference (RFC 5764, Section 5.1.2) >>> ought >>> to be recommended as a good way of doing this multiplexing. >>> >>> Please comment, including whether mixing SCTP and RTP on the same UDP >>> 5-tuple is a good idea (some rationale for doing this sort of >>> multiplexing >>> onto a single 5-tuple can be found in Section 3 of >>> draft-york-dart-dscp-rtp-00). >>> >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> david.black@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>> >>> >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart >>> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart > > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart > From nobody Thu Jun 12 16:12:03 2014 Return-Path: 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 EB5921A02E5 for ; Thu, 12 Jun 2014 16:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 pkFELfg0oo2T for ; Thu, 12 Jun 2014 16:11:59 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8158F1A02C4 for ; Thu, 12 Jun 2014 16:11:59 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kx10so1430521pab.26 for ; Thu, 12 Jun 2014 16:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3YW+inSbwhEwfPoI7YZOErUamonTyw0dvSBahr/q9q8=; b=oNfImLa+0EjPJ0c1YISGGLR1PBhMjJLfMms55kfNAavoUyqj9sXM2WNq0MbRiy7e4R FuYR/reZlryxCVOiRM525cMCJsbpkAmwCCmgY0GheCYZe8XmSrcA5nNntqat/DeM1Pzo 3JRa4A3jVGs/cePqj7XEeB7NAdOEE/SxvusmAizpoL2dMx3/LDHhV0MLiWTlCqIMA6Et csKEZobvFG7h8BFR/6g+Ri5ejeh9D5HS+kty++swDahp6FVMds72kOl0NYzrudCP42jD 4kNxrgcO56ERcnCxrdX7pws9oE0srcbWxkdeNYOOWjnc32Kba1/ccE9nGzuMYvOJWfZ+ z/2w== X-Received: by 10.68.213.97 with SMTP id nr1mr15935432pbc.52.1402614719094; Thu, 12 Jun 2014 16:11:59 -0700 (PDT) Received: from [192.168.178.23] (148.200.69.111.dynamic.snap.net.nz. [111.69.200.148]) by mx.google.com with ESMTPSA id kn1sm66820pbd.13.2014.06.12.16.11.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 16:11:58 -0700 (PDT) Message-ID: <539A33C6.9080409@gmail.com> Date: Fri, 13 Jun 2014 11:12:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ben Campbell References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <539904B6.4050803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/SUtEVxMcmZj5NErgCKj1-jYi_R0 Cc: "Black, David" , "dart@ietf.org" , Dan Wing Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 23:12:02 -0000 On 13/06/2014 02:41, Ben Campbell wrote: > On Jun 11, 2014, at 8:39 PM, Brian E Carpenter wrote: > >>> What do you mean by 'all the packets would be classified the same'? If you mean all the packets in a 5-tuple would get the same differentiated treatment, that is not desirable, because there are lots of folks wanting to send video i-frames or packets with FEC or other stuff with lower drop precedence than other packets. >> Dan, if a packet crosses a diffserv domain boundary, >> the assumption is that (absent a specific SLA) its >> DSCP *will* be rewritten in whatever way the classifier >> of the receiving domain desires. DSCPs don't have end to >> end semantics, unless there is a string of SLAs along >> the path that all provide the same DSCP semantics. >> >> Not everybody likes this, but it was what the operators >> in the diffserv WG wanted at the time. >> >> If all operators agree to implement a common subset of >> the DSCPs suggested in various TSVWG documents, there would >> be a de facto end to end SLA for those DSCPs. But today, >> that's a bit of a dream world. So, for two arbitrary >> RTCweb users, there's certainly no assurance that the >> DSCP set at the source will be preserved until the >> destination. On the contrary, it's quite likely to >> be set to zero (at the boundary of an operator that >> distrusts the DSCP field) or to a value deemed suitable >> by an ingress classifier for whatever 5-tuple it carries. >> It seems unlikely that a classifier will look further >> into the payload than the port numbers. > > I think I understand your meaning, but just to be sure: > > Even if the packets with the same 5-tuple have different DSCPs, the are likely to get reset to the same DSCP (probably zero) I'm not sure about "probably" (unless someone has done large-scale experiments, we don't really know) but it is the fail-safe default, so we can definitely say "quite likely." > at a boundary, because the classifier either ignores or distrusts the original markings entirely? (As opposed to remapping any given DSCP to a different DSCP, but maintaining some distinction within the flow.) Subject to David's comment about AF "colour" possibly being preserved, yes. There is another little point though. We've been discussing port numbers as though they are transport-independent. Actually, a classifier needs to look at the protocol number (TCP, UDP, SCTP, DCCP etc) before it knows for sure where the port numbers are. So debating this point before draft-ietf-rtcweb-transports-05 is rock solid may be a little academic. I don't think generic classifiers are set up for "SCTP over DTLS over ICE" for example. Brian From nobody Thu Jun 12 22:43:43 2014 Return-Path: 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 0607E1B28D7 for ; Thu, 12 Jun 2014 22:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 r55F9ypgmAcC for ; Thu, 12 Jun 2014 22:43:37 -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 2D1D11A036C for ; Thu, 12 Jun 2014 22:43:36 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5D5hVwT018990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 01:43:32 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5D5hVwT018990 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402638212; bh=3IUXR4vJaCooYYIbkzAyKXbD/kk=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EHIiH5SuNeuPLjnsImr83JuJD7vzN8TOtNbCltfdWftuA9IQJMKpVMqAZOSXHCnFv NSX8zrGheScy64sPyY+rpWRROwoIlfVS8sxoPTSZDKv+GVY3V62YqMcuJ2yNcFJH8B +Agu05m5ezOPS1us68rnwmufDq+HkbVofOllxNLY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5D5hVwT018990 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd03.lss.emc.com (RSA Interceptor); Fri, 13 Jun 2014 01:43:18 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5D5hEGN019303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 01:43:17 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Fri, 13 Jun 2014 01:43:14 -0400 From: "Black, David" To: Harald Alvestrand , "dart@ietf.org" Date: Fri, 13 Jun 2014 01:43:12 -0400 Thread-Topic: [Dart] Commentary on draft-york-00 Thread-Index: Ac+GPMQkqW7R46+9S0SkejvvC1nsFgAi8thQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FF26767@MX15A.corp.emc.com> References: <5399A1C8.7080407@alvestrand.no> In-Reply-To: <5399A1C8.7080407@alvestrand.no> 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: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/a9hwpjBAQ0X3sk-LteGfo6Vq9ak Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 05:43:41 -0000 Harald, Many thanks for the review and commentary, especially for the discussion of real time traffic sensitivity to reordering. This note is an attempt to pick up non-editorial items that haven't been dealt with in other messages on the list. I see four of them: [1] > 2.2 Diffserv PHBs >=20 > do you want to mention what the difference between the 4 AF classes is? > Is it just isolation, or is there a ranking between them (in theory or > in practice)? Sure, there is a ranking between them. In general, higher numbered AF classes are expected to receive better forwarding behavior roughly akin to higher numbered class selector codepoints being expected to receive better forwarding behavior. [2] > 2.3 Diffserv and transport protocols >=20 > The last paragraph is true but irrelevant - we're not using UDP here, > we're using other protocols carried inside UDP. And the stuff that's > carried inside UDP may be sensitive to reordering or may be insensitive > to reordering - we just can't tell purely from the fact that it's UDP. >=20 > Suggest deleting the paragraph. I agree with the point, but rather than deleting the paragraph, I'd suggest expanding it to include discussion of the use of UDP to encapsulate protocols that are sensitive to reordering. One of the reasons for the existence of this paragraph is that it sets up the allowance for use of multiple PHBs that may cause reordering within a single UDP 5-tuple. [3] > IMPORTANT: There is a huge missing section here - which is about > sensitivity of real time communications to packet reordering. I agree, and thank you for the more detailed explanation that can be used as a starting point to write this section. [4] > 2.4 DSCP remarking >=20 > The discussion of token-bucket-based remarkers leaves me a bit confused. > To me, it's obvious (?) that token-bucket-based remarkers would operate > in color-blind mode on a network boundary, and in color-sensitive mode > only when they had assurance that incoming markings were already > indicating color. Thus, flows from an end-user system should only hit > color-blind remarkers; the real question is: will a color-blind remarker > use the incoming DSCP codepoint to decide which of a group of remarking > treatments it chooses for the packets? I'm not sure about the "obvious" point - anyone care to comment on what's actually deployed/configured in practice? The answer to the final question about choice of remarking treatment is "yes" although the PHBs in an AF class should receive the same treatment. The fact that the question was asked suggests that the discussion of traffic classifiers needs some additional clarity and explanation. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Thursday, June 12, 2014 8:49 AM > To: dart@ietf.org > Subject: [Dart] Commentary on draft-york-00 >=20 > This message contains running notes made during my initial review of > draft-york-dart-dscp-rtp-00. > Apologies for lack of organization; it seems better to get them out soon > than to polish them. >=20 > 2 Background >=20 > "any one or more modalities" -> "one or more modalities" would read bette= r. >=20 > "RTP defines the mechanism by which real-time data is transmitted" seems > like an overreach. "RTP defines a common encapsulation format and > handling rules for real-time data transmitted over the Internet" would > be more appropriate. >=20 > "With most applications, a single..." - this is true for legacy. It > seems likely not to remain true. >=20 > The definition of "media flow" needs to be in a "definitions" section. > It's too important to be hiding in the "background" section - see much > other mail. >=20 > "SCTP ... can be multiplexed with one or more RTP sessions". Actually we > can only multiplex SCTP with a single RTP session. There have been > proposals that would allow multiplexing of multiple RTP sessions (each > containing multiple media flows) over a single 5-tuple, but these were > not accepted. >=20 > The mention of MediaStream should be removed from bullet 1. It just > confuses. >=20 > In bullet 2, only one RTP session can be multiplexed with another > transport protocol (again). >=20 > The last paragraph is where distinguishing between related name> and is very desirable. As it stands now, > it seems simple, but when you start asking what all these flows "are", > more precisely, it gets very confusing. >=20 > 2.1 DiffServ >=20 > bullet 1, first list: grammar nit - "classify traffic and setting bits" > -> "classify traffic and set bits" >=20 > "In this context, "forwarding behavior" is a general - for example" .... > is a general what, exactly? >=20 > "to allocates resources" -> "to allocate resources" >=20 > Nit: the all-zero DSCP seems to have only five zeroes. >=20 > 2.2 Diffserv PHBs >=20 > do you want to mention what the difference between the 4 AF classes is? > Is it just isolation, or is there a ranking between them (in theory or > in practice)? >=20 > 2.3 Diffserv and transport protocols >=20 > The last paragraph is true but irrelevant - we're not using UDP here, > we're using other protocols carried inside UDP. And the stuff that's > carried inside UDP may be sensitive to reordering or may be insensitive > to reordering - we just can't tell purely from the fact that it's UDP. >=20 > Suggest deleting the paragraph. >=20 > IMPORTANT: There is a huge missing section here - which is about > sensitivity of real time communications to packet reordering. >=20 > I'm not sure how much can be said here, but I think this is quite complex= : >=20 > - Packet reordering may lead to spurious NACK generation and unneeded > retransmission, just as for the data flow case. How sensitive it is to > that depends on timers. >=20 > - Packet reordering that can be accomodated within an existing jitter > buffer will not lead to any quality issues. >=20 > - Packet reordering that causes jitter buffers to extend is bad news for > delay sensitive communication, such as interactive conversations. > Interactive implementations may choose to discard late data - but this > is a matter of meeting the deadline, not a matter of whether it's reorder= ed. > For replay of recorded media, it doesn't matter much. >=20 > - Packet loss is dealt with differently on interactive media than on > reliable data delivery: Instead of retransmissing all lost data, one > finds a reference point that new data can be based on, and continues to > transmit media relative to that. One does not attempt to recover lost > frames that are history. > How that affects this discussion ... I'm not too sure. >=20 >=20 > 2.4 DSCP remarking >=20 > The discussion of token-bucket-based remarkers leaves me a bit confused. > To me, it's obvious (?) that token-bucket-based remarkers would operate > in color-blind mode on a network boundary, and in color-sensitive mode > only when they had assurance that incoming markings were already > indicating color. Thus, flows from an end-user system should only hit > color-blind remarkers; the real question is: will a color-blind remarker > use the incoming DSCP codepoint to decide which of a group of remarking > treatments it chooses for the packets? >=20 > It seems to me that the section should tell me, and it doesn't. >=20 > 3 RTP Multiplexing Background >=20 > Repeating the story about "only one RTP session per 5-tuple, please".... >=20 > 4 Recommendations >=20 > As discussed above, the first SHOULD NOT (reordering within a media > flow) is not sufficiently founded in discussion of media properties. > Reordering may be a problem, or it may not be a problem. >=20 > I don't see any issues with the other recommendations (the second seems > like an obvious thing to say, for well documented reasons; the three > others seem like no-ops from a practical standpoint). >=20 > Thanks for getting this out the door! >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Jun 13 01:04:51 2014 Return-Path: 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 7DADC1A01CE for ; Fri, 13 Jun 2014 01:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 NMUrIQKgBJNv for ; Fri, 13 Jun 2014 01:04:47 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DD51A0163 for ; Fri, 13 Jun 2014 01:04:46 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 13 Jun 2014 10:04:38 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 13 Jun 2014 10:04:37 +0200 From: To: Date: Fri, 13 Jun 2014 10:04:35 +0200 Thread-Topic: [Dart] Commentary on draft-york-00 Thread-Index: Ac+GPMQkqW7R46+9S0SkejvvC1nsFgAi8thQAAIqc3A= Message-ID: References: <5399A1C8.7080407@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712076FF26767@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FF26767@MX15A.corp.emc.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/KR1p9szdMXCMOMe6mq6sq9A5SCA Cc: dart@ietf.org Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 08:04:50 -0000 Hi David, to answer the question related to implementations and configurations at lea= st from the viewpoint of one network provider - you can support a multi-vendor strategy. This makes sense=20 from an economical point of view, but limits=20 deployments to the minimum common denominator. - to configure a PHB, there are classifiers, policers,=20 schedulers, AQM and re-markers. =20 Implementations differ to some aspects (e.g. on=20 supported number of classes and ingress/egress remarking). Limits like less than 20 PHBs may apply today. I'd be interested, whether there are offers of any=20 complete AF class as part of a single product.=20 =20 - there used to be a possibility to ignore the lower DSCP=20 bits 3-6, but there's no standard to that. Some vendors=20 removed this option and with IPv6, each PHB must be=20 classified and completely configured individually by DSCP. Please be aware, if it comes to a re-write, a single DSCP=20 is set for all incoming DSCPs matching this PHB. Keep in=20 mind the possible restrictions on the number of PHBs.=20 - many IP/MPLS backbone networks and also many Ethernet=20 based access networks support 3-4 PHBs for retail services. I'm not aware of any two providers using exactly the=20 same DSCPs. I'm also not aware of any two standards using fully=20 matching DSCPs for their PHBs (IETF, GSMA, MEF). - There's something I'd call enterprise philosophy, that is=20 making use of a large set of internal PHBs. I never saw=20 any of these philosophies remotely resembling the other.=20 PHBs or classes are used to identify products,=20 access types, stream types and so on. These usually just=20 consume PHBs with sometimes at best loose relation to=20 standards. If end-to-end DiffServ PHBs are what you look for, standardise what is real= ly required and be clear on how to use it. If a network provider is expecte= d to support these PHBs, there must be a convincing reason to do so. Take E= F as an example for a well specified DiffServ standard.=20 Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Black, David Gesendet: Freitag, 13. Juni 2014 07:43 An: Harald Alvestrand; dart@ietf.org Betreff: Re: [Dart] Commentary on draft-york-00 Harald, Many thanks for the review and commentary, especially for the discussion= =20 of real time traffic sensitivity to reordering. This note is an attempt= =20 to pick up non-editorial items that haven't been dealt with in other=20 messages on the list. I see four of them: RG: [snip] [4] > 2.4 DSCP remarking >=20 > The discussion of token-bucket-based remarkers leaves me a bit confuse= d. > To me, it's obvious (?) that token-bucket-based remarkers would=20 > operate in color-blind mode on a network boundary, and in=20 > color-sensitive mode only when they had assurance that incoming=20 > markings were already indicating color. Thus, flows from an end-user=20 > system should only hit color-blind remarkers; the real question is:=20 > will a color-blind remarker use the incoming DSCP codepoint to decide= =20 > which of a group of remarking treatments it chooses for the packets? I'm not sure about the "obvious" point - anyone care to comment on what'= s=20 actually deployed/configured in practice? The answer to the final question about choice of remarking treatment is= =20 "yes" although the PHBs in an AF class should receive the same treatment= . The fact that the question was asked suggests that the discussion of =20 traffic classifiers needs some additional clarity and explanation. Thanks, --David From nobody Fri Jun 13 06:24:41 2014 Return-Path: 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 CBB311B2884 for ; Fri, 13 Jun 2014 06:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 SdYpIfRve7in for ; Fri, 13 Jun 2014 06:24:35 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1EC1B2853 for ; Fri, 13 Jun 2014 06:24:35 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5DDOW5A010388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 09:24:33 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s5DDOW5A010388 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402665873; bh=pRZFmogZwNDQFEdUfKuxWZEQqeA=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LVx6WdED21O75TYl/ixLWUShBMYbor69AdEfKvObrpSnHO1y0M2UTnXU3OEEdqlUI ARtkNsN9kfI/J2tsJFMN2fWeLuiypopWZ8FoO/W8H2VOUswPMRV+7M1r0G/6Sb7vpN IVwqlN3XHxTx0+fP16wszxk6f8vc1B1oAD6fYAuU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s5DDOW5A010388 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 13 Jun 2014 09:24:18 -0400 Received: from mxhub39.corp.emc.com (mxhub39.corp.emc.com [128.222.70.106]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5DDOI55010197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 09:24:18 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Fri, 13 Jun 2014 09:24:17 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Fri, 13 Jun 2014 09:24:16 -0400 Thread-Topic: [Dart] Commentary on draft-york-00 Thread-Index: Ac+GPMQkqW7R46+9S0SkejvvC1nsFgAi8thQAAIqc3AADiec8A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FF267B4@MX15A.corp.emc.com> References: <5399A1C8.7080407@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712076FF26767@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/WTjbpSQo7jlRFlKIDMsRzSrYoKY Cc: "dart@ietf.org" Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:24:37 -0000 Hi Ruediger Many thanks for the additional information. I have a few comments: > - there used to be a possibility to ignore the lower DSCP > bits 3-6, but there's no standard to that. Some vendors > removed this option and with IPv6, each PHB must be > classified and completely configured individually by DSCP. That's a good thing, since that behavior (per DSCP traffic handling) is a core element of the DiffServ architecture, and is required by RFC 2474 (Section 3). > Please be aware, if it comes to a re-write, a single DSCP > is set for all incoming DSCPs matching this PHB. Keep in > mind the possible restrictions on the number of PHBs. Full AF support should classify all 3 PHBs that make up an AF class into a single aggregate on the node, with remarking applied to that aggregate, not DSCP by DSCP. > If end-to-end DiffServ PHBs are what you look for, standardize > what is really required and be clear on how to use it. As noted earlier, that's not the goal of the dart WG, as I understand it. I believe the goal of this short term WG is to describe what exists and provide guidance on how to use it, particularly for RTCWEB. Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Friday, June 13, 2014 4:05 AM > To: Black, David > Cc: dart@ietf.org > Subject: AW: [Dart] Commentary on draft-york-00 >=20 > Hi David, >=20 > to answer the question related to implementations and configurations at l= east > from the viewpoint of one network provider >=20 > - you can support a multi-vendor strategy. This makes sense > from an economical point of view, but limits > deployments to the minimum common denominator. >=20 > - to configure a PHB, there are classifiers, policers, > schedulers, AQM and re-markers. > Implementations differ to some aspects (e.g. on > supported number of classes and ingress/egress remarking). > Limits like less than 20 PHBs may apply today. > I'd be interested, whether there are offers of any > complete AF class as part of a single product. >=20 > - there used to be a possibility to ignore the lower DSCP > bits 3-6, but there's no standard to that. Some vendors > removed this option and with IPv6, each PHB must be > classified and completely configured individually by DSCP. > Please be aware, if it comes to a re-write, a single DSCP > is set for all incoming DSCPs matching this PHB. Keep in > mind the possible restrictions on the number of PHBs. >=20 > - many IP/MPLS backbone networks and also many Ethernet > based access networks support 3-4 PHBs for retail services. > I'm not aware of any two providers using exactly the > same DSCPs. I'm also not aware of any two standards using fully > matching DSCPs for their PHBs (IETF, GSMA, MEF). >=20 > - There's something I'd call enterprise philosophy, that is > making use of a large set of internal PHBs. I never saw > any of these philosophies remotely resembling the other. > PHBs or classes are used to identify products, > access types, stream types and so on. These usually just > consume PHBs with sometimes at best loose relation to > standards. >=20 > If end-to-end DiffServ PHBs are what you look for, standardise what is re= ally > required and be clear on how to use it. If a network provider is expected= to > support these PHBs, there must be a convincing reason to do so. Take EF a= s an > example for a well specified DiffServ standard. >=20 > Regards, >=20 > Ruediger >=20 > -----Urspr=FCngliche Nachricht----- > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Black, David > Gesendet: Freitag, 13. Juni 2014 07:43 > An: Harald Alvestrand; dart@ietf.org > Betreff: Re: [Dart] Commentary on draft-york-00 >=20 > Harald, >=20 > Many thanks for the review and commentary, especially for the discussi= on > of real time traffic sensitivity to reordering. This note is an attem= pt > to pick up non-editorial items that haven't been dealt with in other > messages on the list. I see four of them: >=20 > RG: [snip] >=20 > [4] > > 2.4 DSCP remarking > > > > The discussion of token-bucket-based remarkers leaves me a bit confu= sed. > > To me, it's obvious (?) that token-bucket-based remarkers would > > operate in color-blind mode on a network boundary, and in > > color-sensitive mode only when they had assurance that incoming > > markings were already indicating color. Thus, flows from an end-user > > system should only hit color-blind remarkers; the real question is: > > will a color-blind remarker use the incoming DSCP codepoint to decid= e > > which of a group of remarking treatments it chooses for the packets? >=20 > I'm not sure about the "obvious" point - anyone care to comment on wha= t's > actually deployed/configured in practice? >=20 > The answer to the final question about choice of remarking treatment i= s > "yes" although the PHBs in an AF class should receive the same treatme= nt. > The fact that the question was asked suggests that the discussion of > traffic classifiers needs some additional clarity and explanation. >=20 > Thanks, > --David >=20 From nobody Sat Jun 14 21:05:01 2014 Return-Path: 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 6B6C51B29D1 for ; Sat, 14 Jun 2014 21:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 3SYhFo92m5oM for ; Sat, 14 Jun 2014 21:04:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCD91B2889 for ; Sat, 14 Jun 2014 21:04:55 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s5F44etI012586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Jun 2014 00:04:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1402805092; bh=QpCwlETiDnUrT8hXmyif3Wa+5DgQaNe6BhVQXhnEGZ4=; h=From:To:Subject:Date:Content-Transfer-Encoding:Content-Type: In-Reply-To:Message-Id:Mime-Version:Reply-To; b=a/pPLNS6jpLsUJveP+qw7LqFHgbLq/YzB9/mWOVToPVTdpel4xOpsjskeB/8d6Lh2 KUDmSFJfzoeXqFiaGglHtnugYZ+ZLQAblRtbEcY6NZoWqP15VXsMOphiySU0I4j0WS 9Z+8hlGO8u5m3jEhUwKwteROYiup6Q870/QgkacQ= From: "Paul E. Jones" To: "Harald Alvestrand" , dart@ietf.org Date: Sun, 15 Jun 2014 04:04:52 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <539838DF.8010506@alvestrand.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.20154.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/bHi5-5ra_UkpO7y0Aa0DP1wgX3o Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 04:04:58 -0000 ------ Original Message ------ From: "Harald Alvestrand" To: dart@ietf.org Sent: 6/11/2014 7:09:19 AM Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt >On 06/10/2014 09:44 PM, Black, David wrote: >> >>Could you suggest a reference that could be cited for usage of an RTP >>packet stream for each MediaStream independent of how many >>MediaStreamTracks each MediaStream contains? > >Careful - "RTP packet stream" is one of those concepts that can be=20 >meaningless without citing a specific definition. > >draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference=20 >at the moment. It says this about "Packet stream": > Indeed. I threw my two cents in on the word "Packet Stream". I spoke=20 with (at least some of) the authors asking them to call this "RTP Packet= =20 Stream" or to pick something entirely different. Between "packet=20 stream" and "MediaStream" and "Media Stream" (yeah, those are different,= =20 too), the language makes it hard to follow. > >The term "media flow" doesn't sound to me like a good term to use for=20 >this concept. >Would the authors be willing to consider switching to "packet stream"? > I don't have a strong preference, except that I'd prefer to qualify that= =20 as "RTP Packet Stream". Paul From nobody Sat Jun 14 21:52:32 2014 Return-Path: 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 CA2551B2A95 for ; Sat, 14 Jun 2014 21:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 8sJ2wrbDxWMB for ; Sat, 14 Jun 2014 21:52:29 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9024A1B2A96 for ; Sat, 14 Jun 2014 21:52:29 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s5F4qQi6015496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Jun 2014 00:52:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1402807947; bh=CCA3dKGCUPXtVr9s8b5iB5+bZw0lYx3YB3ikHbyCO0o=; h=From:To:Subject:Date:Content-Transfer-Encoding:Content-Type: In-Reply-To:Message-Id:Mime-Version:Reply-To; b=rwZNS/Z1rG/M/a+xeGNw3gaYTadhgP3UYyQdRT46X4La3gxFxLpklkBCfQY2JjppI 6yIuPJMHdoguj2TuFitleFeiKP6oaIsSs9DQyHbdpENDf9URs/66HJmB/MUHXqZ7gz tOovWacoSTaHZnMk026O40LcUbzC0HEwnfuPbAQA= From: "Paul E. Jones" To: "Harald Alvestrand" , dart@ietf.org Date: Sun, 15 Jun 2014 04:52:38 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <5399A1C8.7080407@alvestrand.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.20154.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Vx8P0KvAnszf-t-lBENTc4HPPNA Subject: Re: [Dart] multiplexing different media types (was: Commentary on draft-york-00) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 04:52:31 -0000 Harald, >"SCTP ... can be multiplexed with one or more RTP sessions". Actually=20 >we can only multiplex SCTP with a single RTP session. There have been=20 >proposals that would allow multiplexing of multiple RTP sessions (each=20 >containing multiple media flows) over a single 5-tuple, but these were=20 >not accepted. Your draft (draft-ietf-rtcweb-transports) says: RTCWEB implementations MUST support multiplexing of DTLS and RTP=20 over the same port pair, as described in the DTLS_SRTP specification [RFC5764], section 5.1.2. All application layer protocol payloads over this DTLS connection are SCTP packets. I had a question about this as we discussed the DART draft. I assumed=20 the only DTLS connection would be one used for key negotiation for SRTP.= =20 Is that not the case? Would there be multiple DTLS connections=20 multiplexed? If so, how would one be differentiated from another? As for RTP Session multiplexing, it's interesting to hear that proposals= =20 are dead. Is there a proposal for multiplexing different media types=20 (e.g., audio and video) within the same RTP Session, then? RFC 3550=20 discourages that, but it was my understanding that browser makers wanted= =20 to multiplex the different media types somehow. What's the plan? Paul From nobody Sat Jun 14 22:21:02 2014 Return-Path: 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 875171B2C82 for ; Sat, 14 Jun 2014 22:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 RG69KlRZug5g for ; Sat, 14 Jun 2014 22:20:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5021B2C7E for ; Sat, 14 Jun 2014 22:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1402809658; x=1404019258; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=25Jqor53RHkuIOyYT0es/i/WakmopLBrXJeL8bWSmz0=; b=dxni+A7YQkmqXESEXcEmaGJpyRhJ5xbhE+siJwAUOIgCNiD/uYL4fJCu Voa+eL62a6oTL+dy4dHHP3kU+QTQkEBVGIg3iUH4LHwKE+eEiCbgui85f 9JrZ4sGqyLGNo1YTdWGKo/20B6gIghyxx8zA5+uPdV3W2sX4oOz1/ln98 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFAIgsnVOtJV2T/2dsb2JhbABagw1SWqloAQMBBpFnhz0BgQMWdYQDAQEBBAEBAWsLDAQCAQgRBAEBAS4nCx0IAgQOBYhCDc8NEwSFY4gxEQEdMwcGgyeBFgEDmkOTWINAgXc5 X-IronPort-AV: E=Sophos;i="5.01,480,1400025600"; d="scan'208";a="332984988" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP; 15 Jun 2014 05:20:57 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5F5KvdN024016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Jun 2014 05:20:57 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Sun, 15 Jun 2014 00:20:56 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Paul E. Jones" Thread-Topic: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: AQHPgepWyS4BAweuckqjQffoCSV1MptlKPeAgAUwE4CAAL+zAIABAm6AgAXSvACAABVDAA== Date: Sun, 15 Jun 2014 05:20:56 +0000 Message-ID: <8B6B4935-5715-4EED-8CB2-69F4F7B8EF71@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.53] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5C61F41A560A3E41B6F54152AB0E31E0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/c28xhcWTVHitGKRCWMn0wQeLezQ Cc: Harald Alvestrand , "dart@ietf.org" Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 05:20:59 -0000 On Jun 15, 2014, at 12:04 AM, Paul E. Jones wrote: >=20 >=20 > ------ Original Message ------ > From: "Harald Alvestrand" > To: dart@ietf.org > Sent: 6/11/2014 7:09:19 AM > Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >> On 06/10/2014 09:44 PM, Black, David wrote: >>>=20 >>> Could you suggest a reference that could be cited for usage of an RTP >>> packet stream for each MediaStream independent of how many >>> MediaStreamTracks each MediaStream contains? >>=20 >> Careful - "RTP packet stream" is one of those concepts that can be meani= ngless without citing a specific definition. >>=20 >> draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference a= t the moment. It says this about "Packet stream": >>=20 >=20 > Indeed. I threw my two cents in on the word "Packet Stream". I spoke wit= h (at least some of) the authors asking them to call this "RTP Packet Strea= m" or to pick something entirely different. Between "packet stream" and "M= ediaStream" and "Media Stream" (yeah, those are different, too), the langua= ge makes it hard to follow. Your issue has been understood and will be addressed. In fact, Bo has alre= ady sent an email confirming that this change will be made for the next ver= sion: "Change the term =93Packet Stream=94 to =93RTP Stream=94 throughout the doc= ument, since =93Packet Stream=94 is too unspecific" Cheers, Gonzalo >=20 >=20 >>=20 >> The term "media flow" doesn't sound to me like a good term to use for th= is concept. >> Would the authors be willing to consider switching to "packet stream"? >>=20 >=20 > I don't have a strong preference, except that I'd prefer to qualify that = as "RTP Packet Stream". >=20 > Paul >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Sun Jun 15 00:18:26 2014 Return-Path: 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 B57621B2B7F for ; Sun, 15 Jun 2014 00:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 FxbzGQeOC0BX for ; Sun, 15 Jun 2014 00:18:13 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFBF1A0066 for ; Sun, 15 Jun 2014 00:18:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9FE6E7C37F4; Sun, 15 Jun 2014 09:18:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRY4X4klijh4; Sun, 15 Jun 2014 09:18:09 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id DECF57C37ED; Sun, 15 Jun 2014 09:18:09 +0200 (CEST) Message-ID: <539D48B1.80003@alvestrand.no> Date: Sun, 15 Jun 2014 09:18:09 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Paul E. Jones" , dart@ietf.org, Eric Rescorla References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/vAOUBhEtOEDVKpmbdGZx7JmUigs Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 07:18:17 -0000 (Adding EKR to thread to get a definitive DTLS answer) On 06/15/2014 06:52 AM, Paul E. Jones wrote: > Harald, > > >> "SCTP ... can be multiplexed with one or more RTP sessions". Actually >> we can only multiplex SCTP with a single RTP session. There have been >> proposals that would allow multiplexing of multiple RTP sessions >> (each containing multiple media flows) over a single 5-tuple, but >> these were not accepted. > > Your draft (draft-ietf-rtcweb-transports) says: > > RTCWEB implementations MUST support multiplexing of DTLS and RTP over > the same port pair, as described in the DTLS_SRTP specification > [RFC5764], section 5.1.2. All application layer protocol payloads > over this DTLS connection are SCTP packets. > > I had a question about this as we discussed the DART draft. I assumed > the only DTLS connection would be one used for key negotiation for > SRTP. Is that not the case? Would there be multiple DTLS connections > multiplexed? If so, how would one be differentiated from another? EKR is the expert here. As I understand it, the key material for DTLS-SRTP is derived from the session keys from the DTLS session. This does not in any way affect the usage of the same DTLS session for passing DTLS data. > > As for RTP Session multiplexing, it's interesting to hear that > proposals are dead. Is there a proposal for multiplexing different > media types (e.g., audio and video) within the same RTP Session, > then? RFC 3550 discourages that, but it was my understanding that > browser makers wanted to multiplex the different media types somehow. > What's the plan? draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. The only thing in RTP itself that prevents such multiplexing is the words in RFC 3550; technically there is no barrier at the RTP level. At the SDP level things are a bit more complex, which is why -bundle- isn't an RFC yet. > > Paul > -- Surveillance is pervasive. Go Dark. From nobody Sun Jun 15 00:19:16 2014 Return-Path: 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 6B1291A0066 for ; Sun, 15 Jun 2014 00:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 3u3KyxkmvKx6 for ; Sun, 15 Jun 2014 00:19:06 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1699D1B2B80 for ; Sun, 15 Jun 2014 00:19:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5D2427C3854; Sun, 15 Jun 2014 09:19:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L44HlgPrlpYP; Sun, 15 Jun 2014 09:19:04 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 33EF67C37F4; Sun, 15 Jun 2014 09:19:04 +0200 (CEST) Message-ID: <539D48E8.8000507@alvestrand.no> Date: Sun, 15 Jun 2014 09:19:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , "Paul E. Jones" References: <8B6B4935-5715-4EED-8CB2-69F4F7B8EF71@cisco.com> In-Reply-To: <8B6B4935-5715-4EED-8CB2-69F4F7B8EF71@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/jsVdevs9FR9vFM34cNzmRQQPZvQ Cc: "dart@ietf.org" Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 07:19:09 -0000 On 06/15/2014 07:20 AM, Gonzalo Salgueiro (gsalguei) wrote: > On Jun 15, 2014, at 12:04 AM, Paul E. Jones wrote: > >> >> ------ Original Message ------ >> From: "Harald Alvestrand" >> To: dart@ietf.org >> Sent: 6/11/2014 7:09:19 AM >> Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt >> >>> On 06/10/2014 09:44 PM, Black, David wrote: >>>> Could you suggest a reference that could be cited for usage of an RTP >>>> packet stream for each MediaStream independent of how many >>>> MediaStreamTracks each MediaStream contains? >>> Careful - "RTP packet stream" is one of those concepts that can be meaningless without citing a specific definition. >>> >>> draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference at the moment. It says this about "Packet stream": >>> >> Indeed. I threw my two cents in on the word "Packet Stream". I spoke with (at least some of) the authors asking them to call this "RTP Packet Stream" or to pick something entirely different. Between "packet stream" and "MediaStream" and "Media Stream" (yeah, those are different, too), the language makes it hard to follow. > Your issue has been understood and will be addressed. In fact, Bo has already sent an email confirming that this change will be made for the next version: > > "Change the term “Packet Stream” to “RTP Stream” throughout the document, since “Packet Stream” is too unspecific" That should be "RTP packet stream", with a specific reference to -taxonomy-. "RTP Stream" is *less* specific than "packet stream". > > Cheers, > > Gonzalo > >> >>> The term "media flow" doesn't sound to me like a good term to use for this concept. >>> Would the authors be willing to consider switching to "packet stream"? >>> >> I don't have a strong preference, except that I'd prefer to qualify that as "RTP Packet Stream". >> >> Paul >> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart -- Surveillance is pervasive. Go Dark. From nobody Sun Jun 15 01:33:28 2014 Return-Path: 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 A4D3E1B2BB5 for ; Sun, 15 Jun 2014 01:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Zur2-ixGhXON for ; Sun, 15 Jun 2014 01:33:25 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id B79E81A0324 for ; Sun, 15 Jun 2014 01:33:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4E2857C3793 for ; Sun, 15 Jun 2014 10:33:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8Fij-wHxlM2 for ; Sun, 15 Jun 2014 10:33:23 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id ABA0E7C378F for ; Sun, 15 Jun 2014 10:33:23 +0200 (CEST) Message-ID: <539D5A53.3050801@alvestrand.no> Date: Sun, 15 Jun 2014 10:33:23 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dart@ietf.org References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <539904B6.4050803@gmail.com> <539A33C6.9080409@gmail.com> In-Reply-To: <539A33C6.9080409@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/tgUjpmOm8YfSpgt5ZVjQUVwZtXo Subject: [Dart] Protocols and port numbers (Re: RTP and non-RTP traffic on same UDP 5-tuple) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 08:33:27 -0000 On 06/13/2014 01:12 AM, Brian E Carpenter wrote: > > Subject to David's comment about AF "colour" possibly being preserved, yes. > > There is another little point though. We've been discussing port numbers > as though they are transport-independent. Actually, a classifier needs to > look at the protocol number (TCP, UDP, SCTP, DCCP etc) before it knows > for sure where the port numbers are. So debating this point before > draft-ietf-rtcweb-transports-05 is rock solid may be a little academic. > I don't think generic classifiers are set up for "SCTP over DTLS over ICE" > for example. As far as anything at all in RTCWEB is rock solid, the decision to use UDP is rock solid. So we can take that as a given for RTCWEB. (apart from the case where one uses TCP because the firewalls don't allow UDP...) Generic classifiers will detect the traffic as UDP, and may be able to tell RTP from DTLS-encapsulated data in the same way as the DTLS/RTP demultiplexing does it. -- Surveillance is pervasive. Go Dark. From nobody Sun Jun 15 07:24:31 2014 Return-Path: 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 37E1B1B2844 for ; Sun, 15 Jun 2014 07:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 YZ9FlKtzcIZN for ; Sun, 15 Jun 2014 07:24:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D481B283E for ; Sun, 15 Jun 2014 07:24:27 -0700 (PDT) Received: from dyn-225.arid.us (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s5FEOO9d021925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2014 10:24:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1402842265; bh=wbq2mTImMYMPOL36KmYPeWrcV5/FRTBIvN+R/WGFes0=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=PmyFfBxyHcecl/JQd/1g/bHbuZYqCZ0Jxg25VZx6FsP/mcmxQKrUBnao4erJlgFw6 eWA1KFAGuY0ZrJOolI/xi2qcgxlHYJa+S2Fy4jOSG42QeNVxWebLjQpwYfrbdJBWyI FgnhfOQbjZYkJ+oIdo8bqs3gdS7GC4apEmAlncJA= User-Agent: Kaiten Mail In-Reply-To: <539D48B1.80003@alvestrand.no> References: <539D48B1.80003@alvestrand.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ONXJMSX59YOBS00FR0Z8TET469KGD6" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Sun, 15 Jun 2014 10:24:23 -0400 To: Harald Alvestrand , dart@ietf.org, Eric Rescorla Message-ID: <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dart/bC8o4WnsOeoWbr-F-K2GXFTESls Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 14:24:29 -0000 ------ONXJMSX59YOBS00FR0Z8TET469KGD6 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Harald, Thanks for the clarification. If you'll indulge, allow me to ask one more basic question... In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value. Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint? Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint? Why not allow the PT number space to be distinct per SSRC? Paul -------- Original Message -------- From: Harald Alvestrand Sent: June 15, 2014 3:18:09 AM EDT To: "Paul E. Jones" , dart@ietf.org, Eric Rescorla Subject: Re: multiplexing different media types (Adding EKR to thread to get a definitive DTLS answer) On 06/15/2014 06:52 AM, Paul E. Jones wrote: > Harald, > > >> "SCTP ... can be multiplexed with one or more RTP sessions". Actually >> we can only multiplex SCTP with a single RTP session. There have been >> proposals that would allow multiplexing of multiple RTP sessions >> (each containing multiple media flows) over a single 5-tuple, but >> these were not accepted. > > Your draft (draft-ietf-rtcweb-transports) says: > > RTCWEB implementations MUST support multiplexing of DTLS and RTP over > the same port pair, as described in the DTLS_SRTP specification > [RFC5764], section 5.1.2. All application layer protocol payloads > over this DTLS connection are SCTP packets. > > I had a question about this as we discussed the DART draft. I assumed > the only DTLS connection would be one used for key negotiation for > SRTP. Is that not the case? Would there be multiple DTLS connections > multiplexed? If so, how would one be differentiated from another? EKR is the expert here. As I understand it, the key material for DTLS-SRTP is derived from the session keys from the DTLS session. This does not in any way affect the usage of the same DTLS session for passing DTLS data. > > As for RTP Session multiplexing, it's interesting to hear that > proposals are dead. Is there a proposal for multiplexing different > media types (e.g., audio and video) within the same RTP Session, > then? RFC 3550 discourages that, but it was my understanding that > browser makers wanted to multiplex the different media types somehow. > What's the plan? draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. The only thing in RTP itself that prevents such multiplexing is the words in RFC 3550; technically there is no barrier at the RTP level. At the SDP level things are a bit more complex, which is why -bundle- isn't an RFC yet. > > Paul > -- Surveillance is pervasive. Go Dark. ------ONXJMSX59YOBS00FR0Z8TET469KGD6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Harald,

Thanks for the clarification. If you'll indulge, allow me to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value. Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint?  Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint?

Why not allow the PT number space to be distinct per SSRC?

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

(Adding EKR to thread to get a definitive DTLS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:
 Harald,


 "SCTP ... can be multiplexed with one or more RTP sessions". Actually
 we can only multiplex SCTP with a single RTP session. There have been
 proposals that would allow multiplexing of multiple RTP sessions
 (each containing multiple media flows) over a single 5-tuple, but
 these were not accepted.

 Your draft (draft-ietf-rtcweb-transports) says:

     RTCWEB implementations MUST support multiplexing of DTLS and RTP over
     the same port pair, as described in the DTLS_SRTP specification
     [RFC5764], section 5.1.2. A!
 ll
application layer protocol payloads
     over this DTLS connection are SCTP packets.

 I had a question about this as we discussed the DART draft.  I assumed
 the only DTLS connection would be one used for key negotiation for
 SRTP.  Is that not the case? Would there be multiple DTLS connections
 multiplexed?  If so, how would one be differentiated from another?

EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.


 As for RTP Session multiplexing, it's interesting to hear that
 proposals are dead.  Is there a proposal for multiplexing different
 media types (e.g., audio and video) within the sa!
 me RTP
Session,
 then?  RFC 3550 discourages that, but it was my understanding that
 browser makers wanted to multiplex the different media types somehow. 
 What's the plan?

draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.


 Paul


------ONXJMSX59YOBS00FR0Z8TET469KGD6-- From nobody Sun Jun 15 07:35:55 2014 Return-Path: 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 A6A171B285A for ; Sun, 15 Jun 2014 07:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 Zy6ZepAloD5i for ; Sun, 15 Jun 2014 07:35:50 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC821B2854 for ; Sun, 15 Jun 2014 07:35:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BB1E47C37ED; Sun, 15 Jun 2014 16:35:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1uxO8Je8QCk; Sun, 15 Jun 2014 16:35:48 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:cfe:6103:ed28:a97f] (unknown [IPv6:2001:470:de0a:27:cfe:6103:ed28:a97f]) by mork.alvestrand.no (Postfix) with ESMTPSA id 29E147C37E5; Sun, 15 Jun 2014 16:35:48 +0200 (CEST) Message-ID: <539DAF41.50500@alvestrand.no> Date: Sun, 15 Jun 2014 16:35:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Paul E. Jones" , dart@ietf.org, Eric Rescorla References: <539D48B1.80003@alvestrand.no> <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> In-Reply-To: <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> Content-Type: multipart/alternative; boundary="------------090308080008010207050904" Archived-At: http://mailarchive.ietf.org/arch/msg/dart/NQEzjCKNuwsenlFgezRtzKh9Abs Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 14:35:53 -0000 This is a multi-part message in MIME format. --------------090308080008010207050904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 06/15/2014 04:24 PM, Paul E. Jones wrote: > > Harald, > > Thanks for the clarification. If you'll indulge, allow me to ask one > more basic question... > > In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to > explain that multiplexing is on the SSRC. It also says no two media > sources shall use the same PT value. > No, it does not say that - in fact, it says exactly the opposite. It says that it cannot use the same SSRC for two different media streams and depend on PT to distinguish between them. PT is not a multiplexing point. The PT value is a single byte, and is sometimes used for other purposes (with RTP/RTCP multiplexing, for example, some numbers are unusable because RTCP uses the same field for operation codes). Trying to use it to distinguish between streams would reduce the max number of possible streams to a seriously ridiculously low number. Can you point me at the language you interpreted that way? If it can be read that way, it *must* be changed. > Thus, a payload type could be used when demultiplexing, though the > text says otherwise. Perhaps this language exists to support > multipoint? Thus, a receiver first looks at the SSRC to identify the > source, then the PT to determine what the packet contains? Is SSRC > demuxing there only for multipoint? > No. The PT tells the receiver what format the packet contains. The SSRC tells you which RTP packet flow it belongs to. In some cases one RTP packet flow will switch between different payload types (audio, DTMF and comfort noise being the most common examples), while still representing only one media flow. > Why not allow the PT number space to be distinct per SSRC? > I have problems parsing this question into the context above. What are you asking? > Paul > > > > ------------------------------------------------------------------------ > *From:* Harald Alvestrand > *Sent:* June 15, 2014 3:18:09 AM EDT > *To:* "Paul E. Jones" , dart@ietf.org, Eric > Rescorla > *Subject:* Re: multiplexing different media types > > (Adding EKR to thread to get a definitive DTLS answer) > > On 06/15/2014 06:52 AM, Paul E. Jones wrote: > > Harald, > > "SCTP ... can be multiplexed with one or more RTP sessions". > Actually we can only multiplex SCTP with a single RTP session. > There have been proposals that would allow multiplexing of > multiple RTP sessions (each containing multiple media flows) > over a single 5-tuple, but these were not accepted. > > Your draft (draft-ietf-rtcweb-transports) says: RTCWEB > implementations MUST support multiplexing of DTLS and RTP over the > same port pair, as described in the DTLS_SRTP specification > [RFC5764], section 5.1.2. A! ll application layer protocol > payloads over this DTLS connection are SCTP packets. I had a > question about this as we discussed the DART draft. I assumed the > only DTLS connection would be one used for key negotiation for > SRTP. Is that not the case? Would there be multiple DTLS > connections multiplexed? If so, how would one be differentiated > from another? > > > EKR is the expert here. > > As I understand it, the key material for DTLS-SRTP is derived from the > session keys from the DTLS session. This does not in any way affect the > usage of the same DTLS session for passing DTLS data. > > As for RTP Session multiplexing, it's interesting to hear that > proposals are dead. Is there a proposal for multiplexing different > media types (e.g., audio and video) within the sa! me RTP Session, > then? RFC 3550 discourages that, but it was my understanding that > browser makers wanted to multiplex the different media types > somehow. What's the plan? > > > draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. > draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. > > The only thing in RTP itself that prevents such multiplexing is the > words in RFC 3550; technically there is no barrier at the RTP level. > > At the SDP level things are a bit more complex, which is why -bundle- > isn't an RFC yet. > > Paul > > > --------------090308080008010207050904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 06/15/2014 04:24 PM, Paul E. Jones wrote:

Harald,

Thanks for the clarification. If you'll indulge, allow me to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value.


No, it does not say that - in fact, it says exactly the opposite.

It says that it cannot use the same SSRC for two different media streams and depend on PT to distinguish between them. PT is not a multiplexing point.

The PT value is a single byte, and is sometimes used for other purposes (with RTP/RTCP multiplexing, for example, some numbers are unusable because RTCP uses the same field for operation codes). Trying to use it to distinguish between streams would reduce the max number of possible streams to a seriously ridiculously low number.

Can you point me at the language you interpreted that way? If it can be read that way, it *must* be changed.

Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint?  Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint?


No. The PT tells the receiver what format the packet contains. The SSRC tells you which RTP packet flow it belongs to. In some cases one RTP packet flow will switch between different payload types (audio, DTMF and comfort noise being the most common examples), while still representing only one media flow.


Why not allow the PT number space to be distinct per SSRC?


I have problems parsing this question into the context above. What are you asking?

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

(Adding EKR to thread to get a definitive DTLS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:

 Harald,



 "SCTP ... can be multiplexed with one or more RTP sessions". Actually
 we can only multiplex SCTP with a single RTP session. There have been
 proposals that would allow multiplexing of multiple RTP sessions
 (each containing multiple media flows) over a single 5-tuple, but
 these were not accepted.


 Your draft (draft-ietf-rtcweb-transports) says:

     RTCWEB implementations MUST support multiplexing of DTLS and RTP over
     the same port pair, as described in the DTLS_SRTP specification
     [RFC5764], section 5.1.2. A!
 ll
application layer protocol payloads
     over this DTLS connection are SCTP packets.

 I had a question about this as we discussed the DART draft.  I assumed
 the only DTLS connection would be one used for key negotiation for
 SRTP.  Is that not the case? Would there be multiple DTLS connections
 multiplexed?  If so, how would one be differentiated from another?


EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.



 As for RTP Session multiplexing, it's interesting to hear that
 proposals are dead.  Is there a proposal for multiplexing different
 media types (e.g., audio and video) within the sa!
 me RTP
Session,
 then?  RFC 3550 discourages that, but it was my understanding that
 browser makers wanted to multiplex the different media types somehow. 
 What's the plan?


draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.



 Paul

--------------090308080008010207050904-- From nobody Sun Jun 15 08:31:09 2014 Return-Path: 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 585C21B287E for ; Sun, 15 Jun 2014 08:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 MPKk5bjHRbgD for ; Sun, 15 Jun 2014 08:31:05 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3977F1B287A for ; Sun, 15 Jun 2014 08:31:05 -0700 (PDT) Received: from [IPV6:2607:fb90:c1c:4a81:43a2:3b98:8973:587c] ([172.56.4.241]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s5FFUxUF026163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2014 11:31:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1402846262; bh=Qf5P6lvfq1jDXZHgd8eCdYGiLMO5z3gXyxergsTK3cg=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=o5Lv74bhi/Xd+IgRH1TJBjBvXE4pgy2oTbYKsGmn3ZCfetyCTT+sl1MBZKveA18E1 WIRhu787R8HQIEJEOMkj+2vDh6Q3CuKVz9yNj7Hx+qa///PC9hZieWgf7xDNlUwwB/ 7ZEgeBslEU7c79hQijEfJ3PL35reK8fSD41tbGQA= User-Agent: Kaiten Mail In-Reply-To: <539DAF41.50500@alvestrand.no> References: <539D48B1.80003@alvestrand.no> <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> <539DAF41.50500@alvestrand.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----4BBP359FROFBRKXUP9I1DPX4L02NZS" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Sun, 15 Jun 2014 11:30:57 -0400 To: Harald Alvestrand , dart@ietf.org, Eric Rescorla Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/dart/F1SNNlXJ1g-AZcU0GZpyFHbHaho Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 15:31:07 -0000 ------4BBP359FROFBRKXUP9I1DPX4L02NZS Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Harald, I think we're saying the same thing. The multiplexing point is the SSRC, correct? I said two media sources cannot use the same PT. Effectively, all PT values used by an endpoint sending media are distinct. Is that correct? My last question below is trying to understand why its not allowed for SSRC1 and SSRC2, perhaps one being an audio source and one being a video source, to use PT 97, for example. I think that's presently not allowed, but not sure why since demux occurs on the SSRC. Paul -------- Original Message -------- From: Harald Alvestrand Sent: June 15, 2014 10:35:45 AM EDT To: "Paul E. Jones" , dart@ietf.org, Eric Rescorla Subject: Re: multiplexing different media types On 06/15/2014 04:24 PM, Paul E. Jones wrote: > > Harald, > > Thanks for the clarification. If you'll indulge, allow me to ask one > more basic question... > > In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to > explain that multiplexing is on the SSRC. It also says no two media > sources shall use the same PT value. > No, it does not say that - in fact, it says exactly the opposite. It says that it cannot use the same SSRC for two different media streams and depend on PT to distinguish between them. PT is not a multiplexing point. The PT value is a single byte, and is sometimes used for other purposes (with RTP/RTCP multiplexing, for example, some numbers are unusable because RTCP uses the same field for operation codes). Trying to use it to distinguish between streams would reduce the max number of possible streams to a seriously ridiculously low number. Can you point me at the language you interpreted that way? If it can be read that way, it *must* be changed. > Thus, a payload type could be used when demultiplexing, though the > text says otherwise. Perhaps this language exists to support > multipoint? Thus, a receiver first looks at the SSRC to identify the > source, then the PT to determine what the packet contains? Is SSRC > demuxing there only for multipoint? > No. The PT tells the receiver what format the packet contains. The SSRC tells you which RTP packet flow it belongs to. In some cases one RTP packet flow will switch between different payload types (audio, DTMF and comfort noise being the most common examples), while still representing only one media flow. > Why not allow the PT number space to be distinct per SSRC? > I have problems parsing this question into the context above. What are you asking? > Paul > > > > ------------------------------------------------------------------------ > *From:* Harald Alvestrand > *Sent:* June 15, 2014 3:18:09 AM EDT > *To:* "Paul E. Jones" , dart@ietf.org, Eric > Rescorla > *Subject:* Re: multiplexing different media types > > (Adding EKR to thread to get a definitive DTLS answer) > > On 06/15/2014 06:52 AM, Paul E. Jones wrote: > > Harald, > > "SCTP ... can be multiplexed with one or more RTP sessions". > Actually we can only multiplex SCTP with a single RTP session. > There have been proposals that would allow multiplexing of > multiple RTP sessions (each containing multiple media flows) > over a single 5-tuple, but these were not accepted. > > Your draft (draft-ietf-rtcweb-transports) says: RTCWEB > implementations MUST support multiplexing of DTLS and RTP over the > same port pair, as described in the DTLS_SRTP specification > [RFC5764], section 5.1.2. A! ll application layer protocol > payloads over this DTLS connection are SCTP packets. I had a > question about this as we discussed the DART draft. I assumed the > only DTLS connection would be one used for key negotiation for > SRTP. Is that not the case? Would there be multiple DTLS > connections multiplexed? If so, how would one be differentiated > from another? > > > EKR is the expert here. > > As I understand it, the key material for DTLS-SRTP is derived from the > session keys from the DTLS session. This does not in any way affect the > usage of the same DTLS session for passing DTLS data. > > As for RTP Session multiplexing, it's interesting to hear that > proposals are dead. Is there a proposal for multiplexing different > media types (e.g., audio and video) within the sa! me RTP Session, > then? RFC 3550 discourages that, but it was my understanding that > browser makers wanted to multiplex the different media types > somehow. What's the plan? > > > draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. > draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. > > The only thing in RTP itself that prevents such multiplexing is the > words in RFC 3550; technically there is no barrier at the RTP level. > > At the SDP level things are a bit more complex, which is why -bundle- > isn't an RFC yet. > > Paul > > > ------4BBP359FROFBRKXUP9I1DPX4L02NZS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Harald,

I think we're saying the same thing. The multiplexing point is the SSRC, correct?

I said two media sources cannot use the same PT. Effectively, all PT values used by an endpoint sending media are distinct. Is that correct?

My last question below is trying to understand why its not allowed for SSRC1 and SSRC2, perhaps one being an audio source and one being a video source, to use PT 97, for example. I think that's presently not allowed, but not sure why since demux occurs on the SSRC.

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 10:35:45 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

On 06/15/2014 04:24 PM, Paul E. Jones wrote:

Harald,

Thanks for the clarification. If you'll indulge, allow me to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value.


No, it does not say that - in fact, it says exactly the opposite.

It says that it cannot use the same SSRC for two different media streams and depend on PT to distinguish between them. PT is not a multiplexing point.

The PT value is a single byte, and is sometimes used for other purposes (with RTP/RTCP multiplexing, for example, some numbers are unusable because RTCP uses the same field for operation codes). Trying to use it to distinguish between streams would reduce the max number of possible streams to a seriously ridiculously low number.

Can you point me at the language you interpreted that way? If it can be read that way, it *must* be changed.

Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint?  Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint?


No. The PT tells the receiver what format the packet contains. The SSRC tells you which RTP packet flow it belongs to. In some cases one RTP packet flow will switch between different payload types (audio, DTMF and comfort noise being the most common examples), while still representing only one media flow.


Why not allow the PT number space to be distinct per SSRC?


I have problems parsing this question into the context above. What are you asking?

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

(Adding EKR to thread to get a definitive DTLS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:

 Harald,



 "SCTP ... can be multiplexed with one or more RTP sessions". Actually
 we can only multiplex SCTP with a single RTP session. There have been
 proposals that would allow multiplexing of multiple RTP sessions
 (each containing multiple media flows) over a single 5-tuple, but
 these were not accepted.


 Your draft (draft-ietf-rtcweb-transports) says:

     RTCWEB implementations MUST support multiplexing of DTLS and RTP over
     the same port pair, as described in the DTLS_SRTP specification
     [RFC5764], section 5.1.2. A!
 ll
application layer protocol payloads
     over this DTLS connection are SCTP packets.

 I had a question about this as we discussed the DART draft.  I assumed
 the only DTLS connection would be one used for key negotiation for
 SRTP.  Is that not the case? Would there be multiple DTLS connections
 multiplexed?  If so, how would one be differentiated from another?


EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.



 As for RTP Session multiplexing, it's interesting to hear that
 proposals are dead.  Is there a proposal for multiplexing different
 media types (e.g., audio and video) within the sa!
 me RTP
Session,
 then?  RFC 3550 discourages that, but it was my understanding that
 browser makers wanted to multiplex the different media types somehow. 
 What's the plan?


draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.



 Paul

------4BBP359FROFBRKXUP9I1DPX4L02NZS-- From nobody Sun Jun 15 09:18:25 2014 Return-Path: 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 8CAD91B2923 for ; Sun, 15 Jun 2014 09:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 EUf1NpRR3QC5 for ; Sun, 15 Jun 2014 09:18:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053371B2915 for ; Sun, 15 Jun 2014 09:18:18 -0700 (PDT) Received: from [IPV6:2607:fb90:c1c:4a81:43a2:3b98:8973:587c] ([172.56.4.241]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s5FGIFBQ029210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2014 12:18:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1402849096; bh=S0t+r39MiLqhB2uMI0rCmXce5x4IancRlXB5sjDQAM4=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=kICGuz02FdYA4FVtdRP2olgtOGxrJbvh7J1vZtOkYq/7Y0DrjvM9TbXaPnt3D//i3 Ti5tvT4H/AJbde2Z0UIFaIvS6U+T+sXqM8+MH4LLZciXSG/T7mx8xZIZaHmojI4Ijh zF7g2TtXbeL/pWZvJ0MkwBRVwvgAkvxS15Dc0mTE= User-Agent: Kaiten Mail In-Reply-To: References: <539D48B1.80003@alvestrand.no> <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> <539DAF41.50500@alvestrand.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----2MZ85BMCOW9CZMO32IXHEDPKH6CRPD" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Sun, 15 Jun 2014 12:18:13 -0400 To: Eric Rescorla Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/dart/jObsyUn2goT1nWgGYobWdMqRAhA Cc: Harald Alvestrand , dart@ietf.org Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 16:18:21 -0000 ------2MZ85BMCOW9CZMO32IXHEDPKH6CRPD Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Eric, Sorry, I should have been clearer in preparing the question. When I was referring to media sources, I had completely different types in mind (e.g., audio and video). What I am trying to understand is why there is this statement in the guidelines draft: "The payload type is scoped by sending endpoint within an RTP Session. All synchronisation sources sent from an single endpoint share the same payload types definitions." Clearly, that is legal. But, I'm curious why we maintain this restriction. Since a receiver will demux incoming packets via the SSRC, it seems the PT values associated with a given SSRC could be distinct from another SSRC. Presently for a given sender, there is a "global" definition of PT values (96 for some specific audio format, 97 for some specific video format, ...) and those can be used by multiple SSRCs. So I'm asking why we don't allow {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each 96 could be different formats. Paul -------- Original Message -------- From: Eric Rescorla Sent: June 15, 2014 11:41:09 AM EDT To: "Paul E. Jones" Cc: Harald Alvestrand , dart@ietf.org Subject: Re: multiplexing different media types On Sun, Jun 15, 2014 at 8:30 AM, Paul E. Jones wrote: > Harald, > > I think we're saying the same thing. The multiplexing point is the SSRC, > correct? > > I said two media sources cannot use the same PT. Effectively, all PT > values used by an endpoint sending media are distinct. Is that correct? > No. Two media sources that are sending the same type of media (e.g., two streams of VP8) from the same endpoint can use the same PT as long as the SSRCs are different. See: http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.2.1.2 -Ekr My last question below is trying to understand why its not allowed for > SSRC1 and SSRC2, perhaps one being an audio source and one being a video > source, to use PT 97, for example. I think that's presently not allowed, > but not sure why since demux occurs on the SSRC. > > Paul > > > ------------------------------ > *From:* Harald Alvestrand > *Sent:* June 15, 2014 10:35:45 AM EDT > > *To:* "Paul E. Jones" , dart@ietf.org, Eric > Rescorla > *Subject:* Re: multiplexing different media types > > On 06/15/2014 04:24 PM, Paul E. Jones wrote: > > Harald, > > Thanks for the clarification. If you'll indulge, allow me to ask one more > basic question... > > In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to > explain that multiplexing is on the SSRC. It also says no two media sources > shall use the same PT value. > > > No, it does not say that - in fact, it says exactly the opposite. > > It says that it cannot use the same SSRC for two different media streams > and depend on PT to distinguish between them. PT is not a multiplexing > point. > > The PT value is a single byte, and is sometimes used for other purposes > (with RTP/RTCP multiplexing, for example, some numbers are unusable because > RTCP uses the same field for operation codes). Trying to use it to > distinguish between streams would reduce the max number of possible streams > to a seriously ridiculously low number. > > Can you point me at the language you interpreted that way? If it can be > read that way, it *must* be changed. > > Thus, a payload type could be used when demultiplexing, though the text > says otherwise. Perhaps this language exists to support multipoint? Thus, > a receiver first looks at the SSRC to identify the source, then the PT to > determine what the packet contains? Is SSRC demuxing there only for > multipoint? > > > No. The PT tells the receiver what format the packet contains. The SSRC > tells you which RTP packet flow it belongs to. In some cases one RTP packet > flow will switch between different payload types (audio, DTMF and comfort > noise being the most common examples), while still representing only one > media flow. > > > Why not allow the PT number space to be distinct per SSRC? > > > I have problems parsing this question into the context above. What are you > asking? > > Paul > > > ------------------------------ > *From:* Harald Alvestrand > *Sent:* June 15, 2014 3:18:09 AM EDT > *To:* "Paul E. Jones" , > dart@ietf.org, Eric Rescorla > *Subject:* Re: multiplexing different media types > > (Adding EKR to thread to get a definitive DTLS answer) > > On 06/15/2014 06:52 AM, Paul E. Jones wrote: >> >> Harald, >> >> >>> >>> "SCTP ... can be multiplexed with one or more RTP sessions". Actually >>> we can only multiplex SCTP with a single RTP session. There have been >>> proposals that would allow multiplexing of multiple RTP sessions >>> (each containing multiple media flows) over a single 5-tuple, but >>> these were not accepted. >> >> >> Your draft (draft-ietf-rtcweb-transports) says: >> >> RTCWEB implementations MUST support multiplexing of DTLS and RTP over >> the same port pair, as described in the DTLS_SRTP specification >> [RFC5764], section 5.1.2. A! >> ll >> application layer protocol payloads >> over this DTLS connection are SCTP packets. >> >> I had a question about this as we discussed the DART draft. I assumed >> the only DTLS connection would be one used for key negotiation for >> SRTP. Is that not the case? Would there be multiple DTLS connections >> multiplexed? If so, how would one be differentiated from another? > > > EKR is the expert here. > > As I understand it, the key material for DTLS-SRTP is derived from the > session keys from the DTLS session. This does not in any way affect the > usage of the same DTLS session for passing DTLS data. > >> >> >> As for RTP Session multiplexing, it's interesting to hear that >> proposals are dead. Is there a proposal for multiplexing different >> media types (e.g., audio and video) within the sa! >> me RTP >> Session, >> then? RFC 3550 discourages that, but it was my understanding that >> browser makers wanted to multiplex the different media types somehow. >> What's the plan? > > > draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. > draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. > > The only thing in RTP itself that prevents such multiplexing is the > words in RFC 3550; technically there is no barrier at the RTP level. > > At the SDP level things are a bit more complex, which is why -bundle- > isn't an RFC yet. > >> >> >> Paul > > > > ------2MZ85BMCOW9CZMO32IXHEDPKH6CRPD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Eric,

Sorry, I should have been clearer in preparing the question. When I was referring to media sources, I had completely different types in mind (e.g., audio and video).

What I am trying to understand is why there is this statement in the guidelines draft:

"The payload type is scoped by sending endpoint within an RTP Session. All synchronisation sources sent from an single endpoint share the same payload types definitions."

Clearly, that is legal. But, I'm curious why we maintain this restriction.  Since a receiver will demux incoming packets via the SSRC, it seems the PT values associated with a given SSRC could be distinct from another SSRC.

Presently for a given sender, there is a "global" definition of PT values (96 for some specific audio format, 97 for some specific video format, ...) and those can be used by multiple SSRCs.  So I'm asking why we don't allow {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each 96 could be different formats.

Paul



From: Eric Rescorla <ekr@rtfm.com>
Sent: June 15, 2014 11:41:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, dart@ietf.org
Subject: Re: multiplexing different media types




On Sun, Jun 15, 2014 at 8:30 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Harald,

I think we're saying the same thing. The multiplexing point is the SSRC, correct?

I said two media sources cannot use the same PT. Effectively, all PT values used by an endpoint sending media are distinct. Is that correct?


No. Two media sources that are sending the same type of media
(e.g., two streams of VP8) from the same endpoint can use the same
PT as long as the SSRCs are different. See:


-Ekr

My last question below is trying to understand why its not allowed for SSRC1 and SSRC2, perhaps one being an audio source and one being a video source, to use PT 97, for example. I think that's presently not allowed, but not sure why since demux occurs on the SSRC.

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 10:35:45 AM EDT

To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

On 06/15/2014 04:24 PM, Paul E. Jones wrote:

Harald,

Thanks for the clarification. If you'll indulge, allow me to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value.


No, it does not say that - in fact, it says exactly the opposite.

It says that it cannot use the same SSRC for two different media streams and depend on PT to distinguish between them. PT is not a multiplexing point.

The PT value is a single byte, and is sometimes used for other purposes (with RTP/RTCP multiplexing, for example, some numbers are unusable because RTCP uses the same field for operation codes). Trying to use it to distinguish between streams would reduce the max number of possible streams to a seriously ridiculously low number.

Can you point me at the language you interpreted that way? If it can be read that way, it *must* be changed.

Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint?  Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint?


No. The PT tells the receiver what format the packet contains. The SSRC tells you which RTP packet flow it belongs to. In some cases one RTP packet flow will switch between different payload types (audio, DTMF and comfort noise being the most common examples), while still representing only one media flow.


Why not allow the PT number space to be distinct per SSRC?


I have problems parsing this question into the context above. What are you asking?

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

(Adding EKR to thread to get a definitive DTLS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:

 Harald,



 "SCTP ... can be multiplexed with one or more RTP sessions". Actually
 we can only multiplex SCTP with a single RTP session. There have been
 proposals that would allow multiplexing of multiple RTP sessions
 (each containing multiple media flows) over a single 5-tuple, but
 these were not accepted.


 Your draft (draft-ietf-rtcweb-transports) says:

     RTCWEB implementations MUST support multiplexing of DTLS and RTP over
     the same port pair, as described in the DTLS_SRTP specification
     [RFC5764], section 5.1.2. A!
 ll
application layer protocol payloads
     over this DTLS connection are SCTP packets.

 I had a question about this as we discussed the DART draft.  I assumed
 the only DTLS connection would be one used for key negotiation for
 SRTP.  Is that not the case? Would there be multiple DTLS connections
 multiplexed?  If so, how would one be differentiated from another?


EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.



 As for RTP Session multiplexing, it's interesting to hear that
 proposals are dead.  Is there a proposal for multiplexing different
 media types (e.g., audio and video) within the sa!
 me RTP
Session,
 then?  RFC 3550 discourages that, but it was my understanding that
 browser makers wanted to multiplex the different media types somehow. 
 What's the plan?


draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.



 Paul


------2MZ85BMCOW9CZMO32IXHEDPKH6CRPD-- From nobody Sun Jun 15 11:26:00 2014 Return-Path: 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 38BEE1B28F7 for ; Sun, 15 Jun 2014 11:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 3gwl_W9tr6i5 for ; Sun, 15 Jun 2014 11:25:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8585F1B28E8 for ; Sun, 15 Jun 2014 11:25:54 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s5FIPmJd005072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Jun 2014 14:25:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1402856751; bh=5Q7p1JbQ7mD0KQB8p+HY8YXfVwgZUU+N/lzZrpw24FQ=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=plXEusMc/AYvFjkO12+ed0ZpDTY0eeojF06LFwaqfNlq/DFFZJquvJrzPQUuIISlI mMziU4N74ZQPhV3ytnG+wzKpeBg7PJ9mJ3w1lP+2tF44eGPimTJuE4mcARRssyKaN9 5TpQSKhYnsYVsOV9Zrs5M4FplLY5JKPwdkWZDMwc= From: "Paul E. Jones" To: "Eric Rescorla" Date: Sun, 15 Jun 2014 18:26:01 +0000 Content-Type: multipart/alternative; boundary="------=_MB9424C4AA-25B4-4B46-B8A6-F4D4D3FAD217" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.20154.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/ytqKQCvOYQ9x32LazAlewxYP4Jg Cc: Harald Alvestrand , dart@ietf.org Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 18:25:57 -0000 --------=_MB9424C4AA-25B4-4B46-B8A6-F4D4D3FAD217 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Eric, The reason is to free the endpoint from what I think might be an=20 unnecessary constraints. >From the multiplexing guidelines draft, we have this: | | packets +-- v | +------------+ | | Socket | | +------------+ | || ||= =20 RTP | RTP/ || |+-----> SCTP ( ...and any other protocols) Session | RTCP= =20 || +------> STUN (multiplexed using same port) +-- || +-- || | (split by= =20 SSRC) | || || || | || || || Media | +--+ +--+ +--+ Streams | |PB| |PB|=20 |PB| Jitter buffer, process RTCP, FEC, etc. | +--+ +--+ +--+ +-- | | |=20 (pick rending context based on PT) +-- | / | | +---+ | | / | | Payload |= =20 +--+ +--+ +--+ Formats | |CR| |CR| |CR| Codecs and rendering | +--+ +--+= =20 +--+ +-- So the PT value only has practical significance within the context of a=20 given SSRC (which maps directly to a specific media source), as it's=20 that point in the code where some application component (e.g., the audio= =20 component) will look at the packets. Given the fact that the PT number=20 space is fairly limited, having PT associated only with a given SSRC=20 makes it possible for any media source to have a fairly extensive number= =20 of values. If there is a complex system sending a lots of different media formats,=20 sending FEC information (which I assume would still use the same SSRC),=20 perhaps RFC 2198 redundancy PT, etc., it's possible that the number of=20 different payload types might go beyond the number currently allocated=20 as dynamic PT values. This has not been an issue until now, since=20 systems would usually use separate RTP sessions for different media=20 sources, which means the endpoint is less constrained by the numbering=20 space for PT values. Now that the plan is to multiplex media over the same port and using the= =20 SSRC to differentiate one media source from the other, each media source= =20 potentially using a multiplicity of payload type values, I think there=20 might be benefit in not imposing the restriction of "all synchronisation= =20 sources sent from an single endpoint share the same payload types=20 definitions." So lifting this restriction, * a video source could define PT 96, 97, 98, and 99 for it's purpose * an audio source could define PT 96, 97, 98, 99, 100, 101 for its=20 purpose * a file transfer component could use PT 96 (this might go over the data= =20 channel, but indulge me) * etc. In terms of writing code, this could allow for further separation of=20 application components. There is no need for the audio component to=20 coordinate with the whiteboarding component or video component or=20 whatever when deciding what payload type values to use. I can imagine=20 how these different components might be developed by different teams,=20 with all of the independent components easily plugging in together to=20 share an RTP session. Forcing the use of a "global" set of PT=20 definition forces additional coordination between these application=20 component teams and more complexity in the internal application=20 interfaces. If each component can be developed and maintained in=20 isolation as much as possible, the easier it will be to mix/match=20 components in the browser and to share the single RTP session. It also=20 make orchestration between those components a bit easier. At least=20 that's my opinion. :-) I'm not suggesting the current text is wrong, but I am curious why we=20 might not want to lift that global payload type definition restriction. Paul ------ Original Message ------ From: "Eric Rescorla" To: "Paul E. Jones" Cc: "Harald Alvestrand" ; dart@ietf.org Sent: 6/15/2014 1:01:29 PM Subject: Re: multiplexing different media types > > > >On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones =20 >wrote: >>Eric, >> >>Sorry, I should have been clearer in preparing the question. When I=20 >>was referring to media sources, I had completely different types in=20 >>mind (e.g., audio and video). >> >>What I am trying to understand is why there is this statement in the=20 >>guidelines draft: >> >>"The payload type is scoped by sending endpoint within an RTP Session.= =20 >>All synchronisation sources sent from an single endpoint share the=20 >>same payload types definitions." >> >>Clearly, that is legal. But, I'm curious why we maintain this=20 >>restriction. Since a receiver will demux incoming packets via the=20 >>SSRC, it seems the PT values associated with a given SSRC could be=20 >>distinct from another SSRC. >> >>Presently for a given sender, there is a "global" definition of PT=20 >>values (96 for some specific audio format, 97 for some specific video=20 >>format, ...) and those can be used by multiple SSRCs. So I'm asking=20 >>why we don't allow {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each= =20 >>96 could be different formats. >> >What would be the virtue of doing that? > >-Ekr > [snip] --------=_MB9424C4AA-25B4-4B46-B8A6-F4D4D3FAD217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Eric,
 
The reason is to free the endpoint from what I think might be an = unnecessary constraints.
 
From the multiplexing guidelines draft, we have this:
 
                           |
                           | packets
           +--             v
           |        +------------+
           |        |   Socket   |
           |        +------------+
           |            ||  ||
      RTP  |       RTP/ ||  |+-----> SCTP ( ...and any other protocols)
   Session |       RTCP ||  +------> STUN (multiplexed using same port)
           +--          ||
           +--          ||
           |      (split by SSRC)
           |       ||   ||   ||
           |       ||   ||   ||
     Media |      +--+ +--+ +--+
   Streams |      |PB| |PB| |PB| Jitter buffer, process RTCP, FEC, etc.
           |      +--+ +--+ +--+
           +--      |   |     |
           (pick rending context based on PT)
           +--      |  /      |
           |        +---+     |
           |         /  |     |
   Payload |      +--+ +--+ +--+
   Formats |      |CR| |CR| |CR| Codecs and rendering
           |      +--+ +--+ +--+
           +--
 
So the PT value only has practical significance within the= context of a given SSRC (which maps directly to a specific media= source), as it's that point in the code where some application component= (e.g., the audio component) will look at the packets.  Given the fact= that the PT number space is fairly limited, having PT associated only with= a given SSRC makes it possible for any media source to have a fairly exten= sive number of values.
 
If there is a complex system sending a lots of different media formats= , sending FEC information (which I assume would still use the same SSRC),= perhaps RFC 2198 redundancy PT, etc., it's possible that the number of = different payload types might go beyond the number currently allocated as= dynamic PT values.  This has not been an issue until now, since syste= ms would usually use separate RTP sessions for different media sources, = which means the endpoint is less constrained by the numbering = space for PT values.
 
Now that the plan is to multiplex media over the same port and using= the SSRC to differentiate one media source from the other, each media sour= ce potentially using a multiplicity of payload type values, I think there= might be benefit in not imposing the restriction of "all synchronisation sources sent from an single= endpoint share the same payload types definitions."
 
So lifting this restriction,
* a video source could define PT 96, 97, 98, and 99 for = it's purpose
* an audio source could define PT 96, 97, 98, 99, 100, 101 for= its purpose
* a file transfer component could use PT 96 (this might go over= the data channel, but indulge me)
* etc.
 
In terms of writing code, this could allow for further separatio= n of application components.  There is no need for the audio component= to coordinate with the whiteboarding component or video component or whate= ver when deciding what payload type values to use.  I can imagine how= these different components might be developed by different teams, with = all of the independent components easily plugging in together to share= an RTP session.  Forcing the use of a "global" set of PT definition= forces additional coordination between these application compone= nt teams and more complexity in the internal application interfaces.&n= bsp; If each component can be developed and maintained in isolation as much= as possible, the easier it will be to mix/match components in the browser= and to share the single RTP session.  It also make orchestration betw= een those components a bit easier.  At least that's my opinion. :-)
 
I'm not suggesting the current text is wrong, but= I am curious why we might not want to lift that global payload type defini= tion restriction.
 
Paul
 
------ Original Message ------
From: "Eric Rescorla" <ekr@rtfm.com= >
To: "Paul E. Jones" <paule= j@packetizer.com>
Cc: "Harald Alvestrand" <ha= rald@alvestrand.no>; dart@ietf.org<= /A>
Sent: 6/15/2014 1:01:29 PM
Subject: Re: multiplexing different media types
 



On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones = <paulej@packeti= zer.com> wrote:

Eric,

Sorry, I should have been clearer in preparing the question.= When I was referring to media sources, I had completely different types= in mind (e.g., audio and video).

What I am trying to understand is why there is this statement= in the guidelines draft:

"The payload type is scoped by sending endpoint within an RTP= Session. All synchronisation sources sent from an single endpoint share= the same payload types definitions."

Clearly, that is legal. But, I'm curious why we maintain this= restriction.  Since a receiver will demux incoming packets via the= SSRC, it seems the PT values associated with a given SSRC could be distinc= t from another SSRC.

Presently for a given sender, there is a "global" definition= of PT values (96 for some specific audio format, 97 for some specific vide= o format, ...) and those can be used by multiple SSRCs.  So I'm asking= why we don't allow {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each = 96 could be different formats.

What would be the virtue of doing that?

-Ekr
 
[snip]
 
--------=_MB9424C4AA-25B4-4B46-B8A6-F4D4D3FAD217-- From nobody Sun Jun 15 13:07:07 2014 Return-Path: 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 A2DEB1B2968 for ; Sun, 15 Jun 2014 13:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 BomJ53WPPEnI for ; Sun, 15 Jun 2014 13:06:45 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553161B296E for ; Sun, 15 Jun 2014 13:06:45 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id eu11so3757071pac.33 for ; Sun, 15 Jun 2014 13:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xKAnxWCAtbjigy2QuuAzHEHRKiVu/5bCNF6xFctkGTk=; b=t3Bc6+2CuNgpDJn/Pr5I3NLvdTaKkxIczG0VivpRPGa/22FBhvbjk6Vx3msvfMhMOE BESpLQGaJap6QFSIFA+q7k+5lBrEX67n9sTXMcJ+FP5dZfNaKcipaZTm9UnSg+aiwnJC LIzjS5ErI8KtkvzhEX0lAAhWDIaK4UcTc8eMat49ddW39zxLvQMJjqbUmOrjaLTLthBB TSIdfZJ4wgvJ0maswTMXkIpfU2tB0Ss/AnCEVwSRK5B5Mr4iuPBDuzXSyEeF4XvIr12v 4BQZMHSpNDBVdTN8hWZ7/M07GfYj+vvo0Q4jJ+OmqbGZSLQIrIMUEA8qxKHNPi9EOJRO pIhA== X-Received: by 10.66.232.166 with SMTP id tp6mr18754510pac.127.1402862804977; Sun, 15 Jun 2014 13:06:44 -0700 (PDT) Received: from [192.168.178.23] (246.197.69.111.dynamic.snap.net.nz. [111.69.197.246]) by mx.google.com with ESMTPSA id kq10sm14723126pbc.90.2014.06.15.13.06.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Jun 2014 13:06:44 -0700 (PDT) Message-ID: <539DFCCC.70106@gmail.com> Date: Mon, 16 Jun 2014 08:06:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Harald Alvestrand References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <539904B6.4050803@gmail.com> <539A33C6.9080409@gmail.com> <539D5A53.3050801@alvestrand.no> In-Reply-To: <539D5A53.3050801@alvestrand.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/d3Zilj3zvI-2uXqgJZEkHmo5TWs Cc: dart@ietf.org Subject: Re: [Dart] Protocols and port numbers (Re: RTP and non-RTP traffic on same UDP 5-tuple) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 20:06:54 -0000 Harald, On 15/06/2014 20:33, Harald Alvestrand wrote: > On 06/13/2014 01:12 AM, Brian E Carpenter wrote: >> Subject to David's comment about AF "colour" possibly being preserved, yes. >> >> There is another little point though. We've been discussing port numbers >> as though they are transport-independent. Actually, a classifier needs to >> look at the protocol number (TCP, UDP, SCTP, DCCP etc) before it knows >> for sure where the port numbers are. So debating this point before >> draft-ietf-rtcweb-transports-05 is rock solid may be a little academic. >> I don't think generic classifiers are set up for "SCTP over DTLS over ICE" >> for example. > > As far as anything at all in RTCWEB is rock solid, the decision to use > UDP is rock solid. > So we can take that as a given for RTCWEB. > > (apart from the case where one uses TCP because the firewalls don't > allow UDP...) Ah. Now I understand better. The following comment is out of scope for DART, but I think that draft-ietf-rtcweb-transports desparately needs an overview section with a diagram that shows the complete set of transport nestings. I was very confused by http://tools.ietf.org/html/draft-ietf-rtcweb-transports-05#section-3.5 and such a diagram would make it much clearer what a diffserv classifier would see in the outermost header. > Generic classifiers will detect the traffic as UDP, and may be able to > tell RTP from DTLS-encapsulated data in the same way as the DTLS/RTP > demultiplexing does it. I expect David will agree that RFC 2983 might be worth a read, because some of the same issues arise. I guess that if RTCweb takes over the universe, classifiers might be updated to understand RTCweb transport nestings, but initially you certainly can't assume that. Brian From nobody Sun Jun 15 23:54:22 2014 Return-Path: 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 593441B2C0A for ; Sun, 15 Jun 2014 23:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=no 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 qKuhTziNTfsg for ; Sun, 15 Jun 2014 23:54:19 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665731B2C08 for ; Sun, 15 Jun 2014 23:54:17 -0700 (PDT) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 16 Jun 2014 08:54:05 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 16 Jun 2014 08:54:04 +0200 From: To: Date: Mon, 16 Jun 2014 08:54:04 +0200 Thread-Topic: [Dart] Commentary on draft-york-00 Thread-Index: Ac+GPMQkqW7R46+9S0SkejvvC1nsFgAi8thQAAIqc3AADiec8ACIiabA Message-ID: References: <5399A1C8.7080407@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712076FF26767@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076FF267B4@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FF267B4@MX15A.corp.emc.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/hqzgSHxlUNclWa4POfDt_Y74aAk Cc: dart@ietf.org Subject: Re: [Dart] Commentary on draft-york-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 06:54:21 -0000 Hi David, to make sure we mean the same thing on AF, re-marking and PHB consumption: If a network provider just supports aggregated classes and that provider mu= st use DSCP based classification then Incoming AF4n -> outgoing AF4 with a cost of 1 local PHB is (for example): Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 Incoming DSCP 100 100 -> outgoing DSCP 100 010 PHB AF41 Incoming DSCP 100 110 -> outgoing DSCP 100 010 PHB AF41 The other option, with a cost of 3 local PHBs is Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 Incoming DSCP 100 100 -> outgoing DSCP 100 100 PHB AF42 Incoming DSCP 100 110 -> outgoing DSCP 100 110 PHB AF43 If there was an additional possibility to classify based on=20 DSCP bits 0-2, the second option can be configured with a cost=20 of 1 local PHB (results in an aggregate / single local PHB for=20 the provider and 3 DSCPs for an application or a device closer=20 to the network edge).=20 Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Black, David [mailto:david.black@emc.com]=20 Gesendet: Freitag, 13. Juni 2014 15:24 An: Geib, R=FCdiger Cc: dart@ietf.org Betreff: RE: [Dart] Commentary on draft-york-00 Hi Ruediger Many thanks for the additional information. I have a few comments: > - there used to be a possibility to ignore the lower DSCP > bits 3-6, but there's no standard to that. Some vendors > removed this option and with IPv6, each PHB must be > classified and completely configured individually by DSCP. That's a good thing, since that behavior (per DSCP traffic handling) is a core element of the DiffServ architecture, and is required b= y RFC 2474 (Section 3). > Please be aware, if it comes to a re-write, a single DSCP > is set for all incoming DSCPs matching this PHB. Keep in > mind the possible restrictions on the number of PHBs. Full AF support should classify all 3 PHBs that make up an AF class into a = single aggregate on the node, with remarking applied to that aggregate, not= DSCP by DSCP. > If end-to-end DiffServ PHBs are what you look for, standardize what is=20 > really required and be clear on how to use it. As noted earlier, that's not the goal of the dart WG, as I understand it. = I believe the goal of this short term WG is to describe what exists and pro= vide guidance on how to use it, particularly for RTCWEB. Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Friday, June 13, 2014 4:05 AM > To: Black, David > Cc: dart@ietf.org > Subject: AW: [Dart] Commentary on draft-york-00 >=20 > Hi David, >=20 > to answer the question related to implementations and configurations=20 > at least from the viewpoint of one network provider >=20 > - you can support a multi-vendor strategy. This makes sense > from an economical point of view, but limits > deployments to the minimum common denominator. >=20 > - to configure a PHB, there are classifiers, policers, > schedulers, AQM and re-markers. > Implementations differ to some aspects (e.g. on > supported number of classes and ingress/egress remarking). > Limits like less than 20 PHBs may apply today. > I'd be interested, whether there are offers of any > complete AF class as part of a single product. >=20 > - there used to be a possibility to ignore the lower DSCP > bits 3-6, but there's no standard to that. Some vendors > removed this option and with IPv6, each PHB must be > classified and completely configured individually by DSCP. > Please be aware, if it comes to a re-write, a single DSCP > is set for all incoming DSCPs matching this PHB. Keep in > mind the possible restrictions on the number of PHBs. >=20 > - many IP/MPLS backbone networks and also many Ethernet > based access networks support 3-4 PHBs for retail services. > I'm not aware of any two providers using exactly the > same DSCPs. I'm also not aware of any two standards using fully > matching DSCPs for their PHBs (IETF, GSMA, MEF). >=20 > - There's something I'd call enterprise philosophy, that is > making use of a large set of internal PHBs. I never saw > any of these philosophies remotely resembling the other. > PHBs or classes are used to identify products, > access types, stream types and so on. These usually just > consume PHBs with sometimes at best loose relation to > standards. >=20 > If end-to-end DiffServ PHBs are what you look for, standardise what is=20 > really required and be clear on how to use it. If a network provider=20 > is expected to support these PHBs, there must be a convincing reason=20 > to do so. Take EF as an example for a well specified DiffServ standard. >=20 > Regards, >=20 > Ruediger >=20 > -----Urspr=FCngliche Nachricht----- > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Black, David > Gesendet: Freitag, 13. Juni 2014 07:43 > An: Harald Alvestrand; dart@ietf.org > Betreff: Re: [Dart] Commentary on draft-york-00 >=20 > Harald, >=20 > Many thanks for the review and commentary, especially for the discussi= on > of real time traffic sensitivity to reordering. This note is an attem= pt > to pick up non-editorial items that haven't been dealt with in other > messages on the list. I see four of them: >=20 > RG: [snip] >=20 > [4] > > 2.4 DSCP remarking > > > > The discussion of token-bucket-based remarkers leaves me a bit confu= sed. > > To me, it's obvious (?) that token-bucket-based remarkers would > > operate in color-blind mode on a network boundary, and in > > color-sensitive mode only when they had assurance that incoming > > markings were already indicating color. Thus, flows from an end-user > > system should only hit color-blind remarkers; the real question is: > > will a color-blind remarker use the incoming DSCP codepoint to decid= e > > which of a group of remarking treatments it chooses for the packets? >=20 > I'm not sure about the "obvious" point - anyone care to comment on wha= t's > actually deployed/configured in practice? >=20 > The answer to the final question about choice of remarking treatment i= s > "yes" although the PHBs in an AF class should receive the same treatme= nt. > The fact that the question was asked suggests that the discussion of > traffic classifiers needs some additional clarity and explanation. >=20 > Thanks, > --David >=20 From nobody Mon Jun 16 05:40:02 2014 Return-Path: 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 51E181A000B for ; Mon, 16 Jun 2014 05:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 Dh5Fk_MuYZq3 for ; Mon, 16 Jun 2014 05:39:47 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 849831A001A for ; Mon, 16 Jun 2014 05:39:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 82FCD7C377B; Mon, 16 Jun 2014 14:39:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5XSkVb-cqvh; Mon, 16 Jun 2014 14:39:42 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7B4447C3775; Mon, 16 Jun 2014 14:39:42 +0200 (CEST) Message-ID: <539EE58E.9010106@alvestrand.no> Date: Mon, 16 Jun 2014 14:39:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Paul E. Jones" , Eric Rescorla References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------050301050903060108020305" Archived-At: http://mailarchive.ietf.org/arch/msg/dart/0pe8OGnHDiH4JBC4vSJos69_qbc Cc: dart@ietf.org Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 12:39:56 -0000 This is a multi-part message in MIME format. --------------050301050903060108020305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Paul, this is one of the (many) things that seem extremely simple when we look at the RTP level, but devolves into dastardly complexity when we consider SDP as a description protocol, and the claim is made that the restriction is also embedded into many RTP/SDP/SIP implementations. SDP uses a per m-line field to describe a payload type, without indicating which SSRC these payload types are intended to belong to. Traditionally, one m-line described one RTP session. So colliding PTs inside one RTP session simply couldn't work. As I've heard the arguments in the context of the BUNDLE draft, there are implementations that expected this state of things to last forever, and do not do any SSRC signalling - so when they see a new SSRC, they look at its payload type to decide what kind of flow it is. In a context where something different than SDP is used, and SSRCs are always described explicitly, what you suggest is easy. When using SDP, with either non-explicit SSRC signaling or multiple media flows per m-line, it is hard. I'll return later to why I think the problem is not so great as you describe below, but that's enough of a topic to deserve another message. On 06/15/2014 08:26 PM, Paul E. Jones wrote: > Eric, > > The reason is to free the endpoint from what I think might be > an unnecessary constraints. > > From the multiplexing guidelines draft, we have this: > > | > | packets > +-- v > | +------------+ > | | Socket | > | +------------+ > | || || > RTP | RTP/ || |+-----> SCTP ( ...and any other protocols) > Session | RTCP || +------> STUN (multiplexed using same port) > +-- || > +-- || > | (split by SSRC) > | || || || > | || || || > Media | +--+ +--+ +--+ > Streams | |PB| |PB| |PB| Jitter buffer, process RTCP, FEC, etc. > | +--+ +--+ +--+ > +-- | | | > (pick rending context based on PT) > +-- | / | > | +---+ | > | / | | > Payload | +--+ +--+ +--+ > Formats | |CR| |CR| |CR| Codecs and rendering > | +--+ +--+ +--+ > +-- > > So the PT value only has practical significance within the context of > a given SSRC (which maps directly to a specific media source), as it's > that point in the code where some application component (e.g., the > audio component) will look at the packets. Given the fact that the PT > number space is fairly limited, having PT associated only with a given > SSRC makes it possible for any media source to have a fairly extensive > number of values. > > If there is a complex system sending a lots of different media > formats, sending FEC information (which I assume would still use the > same SSRC), perhaps RFC 2198 redundancy PT, etc., it's possible that > the number of different payload types might go beyond the number > currently allocated as dynamic PT values. This has not been an issue > until now, since systems would usually use separate RTP sessions for > different media sources, which means the endpoint is less constrained > by the numbering space for PT values. > > Now that the plan is to multiplex media over the same port and using > the SSRC to differentiate one media source from the other, each media > source potentially using a multiplicity of payload type values, I > think there might be benefit in not imposing the restriction of "all > synchronisation sources sent from an single endpoint share the same > payload types definitions." > > So lifting this restriction, > * a video source could define PT 96, 97, 98, and 99 for it's purpose > * an audio source could define PT 96, 97, 98, 99, 100, 101 for its purpose > * a file transfer component could use PT 96 (this might go over the > data channel, but indulge me) > * etc. > > In terms of writing code, this could allow for further separation of > application components. There is no need for the audio component to > coordinate with the whiteboarding component or video component or > whatever when deciding what payload type values to use. I can imagine > how these different components might be developed by different teams, > with all of the independent components easily plugging in together to > share an RTP session. Forcing the use of a "global" set of PT > definition forces additional coordination between these application > component teams and more complexity in the internal application > interfaces. If each component can be developed and maintained in > isolation as much as possible, the easier it will be to mix/match > components in the browser and to share the single RTP session. It > also make orchestration between those components a bit easier. At > least that's my opinion. :-) > > I'm not suggesting the current text is wrong, but I am curious why we > might not want to lift that global payload type definition restriction. > > Paul > > ------ Original Message ------ > From: "Eric Rescorla" > > To: "Paul E. Jones" > > Cc: "Harald Alvestrand" >; dart@ietf.org > Sent: 6/15/2014 1:01:29 PM > Subject: Re: multiplexing different media types > >> >> >> >> On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones > > wrote: >> >> Eric, >> >> Sorry, I should have been clearer in preparing the question. When >> I was referring to media sources, I had completely different >> types in mind (e.g., audio and video). >> >> What I am trying to understand is why there is this statement in >> the guidelines draft: >> >> "The payload type is scoped by sending endpoint within an RTP >> Session. All synchronisation sources sent from an single endpoint >> share the same payload types definitions." >> >> Clearly, that is legal. But, I'm curious why we maintain this >> restriction. Since a receiver will demux incoming packets via >> the SSRC, it seems the PT values associated with a given SSRC >> could be distinct from another SSRC. >> >> Presently for a given sender, there is a "global" definition of >> PT values (96 for some specific audio format, 97 for some >> specific video format, ...) and those can be used by multiple >> SSRCs. So I'm asking why we don't allow {SSRC1: (96, 97), SSRC2: >> (96, 97), ...}, where each 96 could be different formats. >> >> What would be the virtue of doing that? >> >> -Ekr >> > [snip] > -- Surveillance is pervasive. Go Dark. --------------050301050903060108020305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Paul,

this is one of the (many) things that seem extremely simple when we look at the RTP level, but devolves into dastardly complexity when we consider SDP as a description protocol, and the claim is made that the restriction is also embedded into many RTP/SDP/SIP implementations.

SDP uses a per m-line field to describe a payload type, without indicating which SSRC these payload types are intended to belong to. Traditionally, one m-line described one RTP session. So colliding PTs inside one RTP session simply couldn't work.

As I've heard the arguments in the context of the BUNDLE draft, there are implementations that expected this state of things to last forever, and do not do any SSRC signalling - so when they see a new SSRC, they look at its payload type to decide what kind of flow it is.

In a context where something different than SDP is used, and SSRCs are always described explicitly, what you suggest is easy.

When using SDP, with either non-explicit SSRC signaling or multiple media flows per m-line, it is hard.

I'll return later to why I think the problem is not so great as you describe below, but that's enough of a topic to deserve another message.

On 06/15/2014 08:26 PM, Paul E. Jones wrote:
Eric,
 
The reason is to free the endpoint from what I think might be an unnecessary constraints.
 
From the multiplexing guidelines draft, we have this:
 
                           |
                           | packets
           +--             v
           |        +------------+
           |        |   Socket   |
           |        +------------+
           |            ||  ||
      RTP  |       RTP/ ||  |+-----> SCTP ( ...and any other protocols)
   Session |       RTCP ||  +------> STUN (multiplexed using same port)
           +--          ||
           +--          ||
           |      (split by SSRC)
           |       ||   ||   ||
           |       ||   ||   ||
     Media |      +--+ +--+ +--+
   Streams |      |PB| |PB| |PB| Jitter buffer, process RTCP, FEC, etc.
           |      +--+ +--+ +--+
           +--      |   |     |
           (pick rending context based on PT)
           +--      |  /      |
           |        +---+     |
           |         /  |     |
   Payload |      +--+ +--+ +--+
   Formats |      |CR| |CR| |CR| Codecs and rendering
           |      +--+ +--+ +--+
           +--
 
So the PT value only has practical significance within the context of a given SSRC (which maps directly to a specific media source), as it's that point in the code where some application component (e.g., the audio component) will look at the packets.  Given the fact that the PT number space is fairly limited, having PT associated only with a given SSRC makes it possible for any media source to have a fairly extensive number of values.
 
If there is a complex system sending a lots of different media formats, sending FEC information (which I assume would still use the same SSRC), perhaps RFC 2198 redundancy PT, etc., it's possible that the number of different payload types might go beyond the number currently allocated as dynamic PT values.  This has not been an issue until now, since systems would usually use separate RTP sessions for different media sources, which means the endpoint is less constrained by the numbering space for PT values.
 
Now that the plan is to multiplex media over the same port and using the SSRC to differentiate one media source from the other, each media source potentially using a multiplicity of payload type values, I think there might be benefit in not imposing the restriction of "all synchronisation sources sent from an single endpoint share the same payload types definitions."
 
So lifting this restriction,
* a video source could define PT 96, 97, 98, and 99 for it's purpose
* an audio source could define PT 96, 97, 98, 99, 100, 101 for its purpose
* a file transfer component could use PT 96 (this might go over the data channel, but indulge me)
* etc.
 
In terms of writing code, this could allow for further separation of application components.  There is no need for the audio component to coordinate with the whiteboarding component or video component or whatever when deciding what payload type values to use.  I can imagine how these different components might be developed by different teams, with all of the independent components easily plugging in together to share an RTP session.  Forcing the use of a "global" set of PT definition forces additional coordination between these application component teams and more complexity in the internal application interfaces.  If each component can be developed and maintained in isolation as much as possible, the easier it will be to mix/match components in the browser and to share the single RTP session.  It also make orchestration between those components a bit easier.  At least that's my opinion. :-)
 
I'm not suggesting the current text is wrong, but I am curious why we might not want to lift that global payload type definition restriction.
 
Paul
 
------ Original Message ------
From: "Eric Rescorla" <ekr@rtfm.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "Harald Alvestrand" <harald@alvestrand.no>; dart@ietf.org
Sent: 6/15/2014 1:01:29 PM
Subject: Re: multiplexing different media types
 



On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Eric,

Sorry, I should have been clearer in preparing the question. When I was referring to media sources, I had completely different types in mind (e.g., audio and video).

What I am trying to understand is why there is this statement in the guidelines draft:

"The payload type is scoped by sending endpoint within an RTP Session. All synchronisation sources sent from an single endpoint share the same payload types definitions."

Clearly, that is legal. But, I'm curious why we maintain this restriction.  Since a receiver will demux incoming packets via the SSRC, it seems the PT values associated with a given SSRC could be distinct from another SSRC.

Presently for a given sender, there is a "global" definition of PT values (96 for some specific audio format, 97 for some specific video format, ...) and those can be used by multiple SSRCs.  So I'm asking why we don't allow {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each 96 could be different formats.

What would be the virtue of doing that?

-Ekr
 
[snip]
 


-- 
Surveillance is pervasive. Go Dark.
--------------050301050903060108020305-- From nobody Mon Jun 16 10:39:01 2014 Return-Path: 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 5A7561B2844 for ; Sun, 15 Jun 2014 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 MsMKzqUeR1wW for ; Sun, 15 Jun 2014 07:21:06 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E761B2842 for ; Sun, 15 Jun 2014 07:21:05 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so4608529wgh.16 for ; Sun, 15 Jun 2014 07:21:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xQR/9AyTe8iTUP3fA6HcHk2QL0LaL6blnWKx+IZdZqQ=; b=bZlV4ZiAzmfxZTQzItPt0tRwGvfDFFtThilKwXVW/heiOUadt5S5yjkCNC7dpxz8or 9Uhd+9Sdao6ZZ/mtP/vQm9Wrq95VO2pktCWPDcBpP1WzK92hvJo46qddBN22uo7TpY/0 a64NHMzT/DrH0TN/tKoYyFyWsm2gCx4cLnRRTsUxicaMknWZpqVtuwom+4e26995KGmC 1dLEYRH+TuFZXYGQkgJmsOx4CCmsq3r3gvTYHc6c4dNiBfCKNHM+RUOerkhSPkDqRhGb gwnl+AnlGuA6EIYBc6t9kYWDwtH0/8ZsXxfIbu1M197jn4zdUeocL6MwzRVhhve9YAh8 AuYg== X-Gm-Message-State: ALoCoQkJHc90tV4AHR4csAt4q4Upx0MPsNhoY8gWU/PBfTDWkNJKbqU+ssSFaGb0FN+T78r2vHPo X-Received: by 10.180.13.230 with SMTP id k6mr5847369wic.1.1402842064157; Sun, 15 Jun 2014 07:21:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 15 Jun 2014 07:20:24 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <539D48B1.80003@alvestrand.no> References: <539D48B1.80003@alvestrand.no> From: Eric Rescorla Date: Sun, 15 Jun 2014 07:20:24 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c2291ae9353c04fbe09efe Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Wl1vXQtvSNplrJtNWhYT4BNT95A X-Mailman-Approved-At: Mon, 16 Jun 2014 10:37:42 -0700 Cc: "Paul E. Jones" , dart@ietf.org Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 14:21:08 -0000 X-List-Received-Date: Sun, 15 Jun 2014 14:21:08 -0000 X-List-Received-Date: Sun, 15 Jun 2014 14:21:08 -0000 --001a11c2291ae9353c04fbe09efe Content-Type: text/plain; charset=UTF-8 On Sun, Jun 15, 2014 at 12:18 AM, Harald Alvestrand wrote: > (Adding EKR to thread to get a definitive DTLS answer) > > On 06/15/2014 06:52 AM, Paul E. Jones wrote: > > Harald, > > > > > >> "SCTP ... can be multiplexed with one or more RTP sessions". Actually > >> we can only multiplex SCTP with a single RTP session. There have been > >> proposals that would allow multiplexing of multiple RTP sessions > >> (each containing multiple media flows) over a single 5-tuple, but > >> these were not accepted. > > > > Your draft (draft-ietf-rtcweb-transports) says: > > > > RTCWEB implementations MUST support multiplexing of DTLS and RTP over > > the same port pair, as described in the DTLS_SRTP specification > > [RFC5764], section 5.1.2. All application layer protocol payloads > > over this DTLS connection are SCTP packets. > > > > I had a question about this as we discussed the DART draft. I assumed > > the only DTLS connection would be one used for key negotiation for > > SRTP. Is that not the case? Would there be multiple DTLS connections > > multiplexed? If so, how would one be differentiated from another? > > EKR is the expert here. > > As I understand it, the key material for DTLS-SRTP is derived from the > session keys from the DTLS session. This does not in any way affect the > usage of the same DTLS session for passing DTLS data. > Each transport pair is attached to one DTLS association. If you mux media and data channels on the same transport pairs, you have one DTLS association. You derive SRTP keys from the DTLS keys and send SRTP over the same transport. -Ekr > > > > As for RTP Session multiplexing, it's interesting to hear that > > proposals are dead. Is there a proposal for multiplexing different > > media types (e.g., audio and video) within the same RTP Session, > > then? RFC 3550 discourages that, but it was my understanding that > > browser makers wanted to multiplex the different media types somehow. > > What's the plan? > > draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. > draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. > > The only thing in RTP itself that prevents such multiplexing is the > words in RFC 3550; technically there is no barrier at the RTP level. > > At the SDP level things are a bit more complex, which is why -bundle- > isn't an RFC yet. > > > > > Paul > > > > > -- > Surveillance is pervasive. Go Dark. > > --001a11c2291ae9353c04fbe09efe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 15, 2014 at 12:18 AM, Harald Alvestrand <harald@alv= estrand.no> wrote:
(Adding EKR to thread to get a definitive DT= LS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:
> Harald,
>
>
>> "SCTP ... can be multiplexed with one or more RTP sessions&qu= ot;. Actually
>> we can only multiplex SCTP with a single RTP session. There have b= een
>> proposals that would allow multiplexing of multiple RTP sessions >> (each containing multiple media flows) over a single 5-tuple, but<= br> >> these were not accepted.
>
> Your draft (draft-ietf-rtcweb-transports) says:
>
> =C2=A0 =C2=A0 RTCWEB implementations MUST support multiplexing of DTLS= and RTP over
> =C2=A0 =C2=A0 the same port pair, as described in the DTLS_SRTP specif= ication
> =C2=A0 =C2=A0 [RFC5764], section 5.1.2. All application layer protocol= payloads
> =C2=A0 =C2=A0 over this DTLS connection are SCTP packets.
>
> I had a question about this as we discussed the DART draft. =C2=A0I as= sumed
> the only DTLS connection would be one used for key negotiation for
> SRTP. =C2=A0Is that not the case? Would there be multiple DTLS connect= ions
> multiplexed? =C2=A0If so, how would one be differentiated from another= ?

EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.
=
Each transport pair is attached to one DTLS association.

If you mux media and data channels on the same transp= ort pairs,
you have one DTLS association. You derive SRTP keys from the
DTLS keys and send SRTP over the same transport.

= -Ekr

=C2=A0
>
> As for RTP Session multiplexing, it's interesting to hear that
> proposals are dead. =C2=A0Is there a proposal for multiplexing differe= nt
> media types (e.g., audio and video) within the same RTP Session,
> then? =C2=A0RFC 3550 discourages that, but it was my understanding tha= t
> browser makers wanted to multiplex the different media types somehow.<= br> > What's the plan?

draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.

>
> Paul
>


--
Surveillance is pervasive. Go Dark.


--001a11c2291ae9353c04fbe09efe-- From nobody Mon Jun 16 10:39:03 2014 Return-Path: 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 4B2C91B2854 for ; Sun, 15 Jun 2014 07:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 7B8n7SYT4shj for ; Sun, 15 Jun 2014 07:31:36 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619BD1B283E for ; Sun, 15 Jun 2014 07:31:36 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so4554183wgh.35 for ; Sun, 15 Jun 2014 07:31:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KhwhYbeKqURpilTrl4ow+YO1oudnpkx2iyflsPmTpI4=; b=fU9sNuvOwAhgazhFEoJtTOjh3USZRUdyhABxeg/JHcvliaL7TAtU4eHvqMT6dJEet6 haI8YsW5r8wAJkw+uVYAsNoJHY+bHuXh5kHJ01n6HNHp3mLrE282DEyvKn3/souHNvUJ eysfsssZc2RPTEqOxdFi382d8ksmrjdO1NSVVfGy3iNgq4N0Q17qwJP1Lua1vOoJtioA YgFf1p6z+dB7g9oW4Qx2wj/paVZ8whDCmbvjt83NxX2Nu2npKzDxThPz6cbn2Ns09Y1r tBUHjXR24o2Jj9ADXTdY8E3zaXgucc5Yt/+W9PrlNJGDQqaUrXZcPHsjz1s29O0HxIn8 4v1Q== X-Gm-Message-State: ALoCoQl9z/4/CEAXNLSEI++0G73S9xGBJm0ujqzvYaKz4lKnsZ5CZhSK+NTjNJG64IaUhbcWZXU/ X-Received: by 10.194.62.176 with SMTP id z16mr3736528wjr.76.1402842694775; Sun, 15 Jun 2014 07:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 15 Jun 2014 07:30:54 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> References: <539D48B1.80003@alvestrand.no> <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> From: Eric Rescorla Date: Sun, 15 Jun 2014 07:30:54 -0700 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7ba979c27f93d104fbe0c4c1 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/yr5OZsDtF0irK-G-dwFZR3xHEhQ X-Mailman-Approved-At: Mon, 16 Jun 2014 10:37:48 -0700 Cc: Harald Alvestrand , dart@ietf.org Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 14:31:39 -0000 X-List-Received-Date: Sun, 15 Jun 2014 14:31:39 -0000 --047d7ba979c27f93d104fbe0c4c1 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 15, 2014 at 7:24 AM, Paul E. Jones wrote: > Harald, > > Thanks for the clarification. If you'll indulge, allow me to ask one more > basic question... > > In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to > explain that multiplexing is on the SSRC. It also says no two media sources > shall use the same PT value. Thus, a payload type could be used when > demultiplexing, though the text says otherwise. Perhaps this language > exists to support multipoint? Thus, a receiver first looks at the SSRC to > identify the source, then the PT to determine what the packet contains? Is > SSRC demuxing there only for multipoint? > > Why not allow the PT number space to be distinct per SSRC? > This is an inconsistency in the drafts. See: http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00 for extensive documentation of the issues at hand and the current plan of record. -Ekr Paul > > > ------------------------------ > *From:* Harald Alvestrand > *Sent:* June 15, 2014 3:18:09 AM EDT > *To:* "Paul E. Jones" , dart@ietf.org, Eric > Rescorla > *Subject:* Re: multiplexing different media types > > (Adding EKR to thread to get a definitive DTLS answer) > > On 06/15/2014 06:52 AM, Paul E. Jones wrote: > >> Harald, >> >> >> "SCTP ... can be multiplexed with one or more RTP sessions". Actually >>> >>> we can only multiplex SCTP with a single RTP session. There have been >>> proposals that would allow multiplexing of multiple RTP sessions >>> (each containing multiple media flows) over a single 5-tuple, but >>> these were not accepted. >>> >> >> Your draft (draft-ietf-rtcweb-transports) says: >> >> RTCWEB implementations MUST support multiplexing of DTLS and RTP over >> the same port pair, as described in the DTLS_SRTP specification >> [RFC5764], section 5.1.2. A! >> ll >> application layer protocol payloads >> >> over this DTLS connection are SCTP packets. >> >> I had a question about this as we discussed the DART draft. I assumed >> the only DTLS connection would be one used for key negotiation for >> >> SRTP. Is that not the case? Would there be multiple DTLS connections >> multiplexed? If so, how would one be differentiated from another? >> > > EKR is the expert here. > > As I understand it, the key material for DTLS-SRTP is derived from the > > session keys from the DTLS session. This does not in any way affect the > usage of the same DTLS session for passing DTLS data. > > >> As for RTP Session multiplexing, it's interesting to hear that >> proposals are dead. Is there a proposal for multiplexing different >> media types (e.g., audio and video) within the sa! >> me RTP >> Session, >> >> then? RFC 3550 discourages that, but it was my understanding that >> browser makers wanted to multiplex the different media types somehow. >> What's the plan? >> > > draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. > draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. > > The only thing in RTP itself that prevents such multiplexing is the > words in RFC 3550; technically there is no barrier at the RTP level. > > At the SDP level things are a bit more complex, which is why -bundle- > isn't an RFC yet. > > >> Paul > > > > --047d7ba979c27f93d104fbe0c4c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 15, 2014 at 7:24 AM, Paul E. Jones &l= t;paulej@packeti= zer.com> wrote:

Harald,

Thanks for the clarification. If you'll indulge, allow m= e to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great= length to explain that multiplexing is on the SSRC. It also says no two me= dia sources shall use the same PT value. Thus, a payload type could be used= when demultiplexing, though the text says otherwise. Perhaps this language= exists to support multipoint?=C2=A0 Thus, a receiver first looks at the SS= RC to identify the source, then the PT to determine what the packet contain= s? Is SSRC demuxing there only for multipoint?

Why not allow the PT number space to be distinct per SSRC?

This is an inconsistency in the drafts. See:

for extensive documentation of the issues at hand= and the
current plan of record.

-Ekr

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

(Adding EKR to thread to get a definitive DTLS answer)=


On 06/15/2014 06:52 AM, Paul E. Jones wrote:



 Harald,


 "SCTP ... can be=
 multiplexed with one or more RTP sessions". Actually


 we can only multiplex SCTP with a single RTP session. There have been
 =
proposals that would allow multiplexing of multiple RTP sessions
 (each =
containing multiple media flows) over a single 5-tuple, but
 these were =
not accepted.




 Your draft (draft-ietf-rtcweb-transports) says:

  =
   RTCWEB implementations MUST support multiplexing of DTLS and RTP over     the same port pair, as described in the DTLS_SRTP specification



     [RFC5764], section 5.1.2. A!
 ll
application layer protocol payloads

     over this DTLS =
connection are SCTP packets.

 I had a question about this as we disc=
ussed the DART draft.  I assumed
 the only DTLS connection would be one =
used for key negotiation for


 SRTP.  Is that not the case? Would there be multiple DTLS connections
 =
multiplexed?  If so, how would one be differentiated from another?

EKR is the expert here.

As I under=
stand it, the key material for DTLS-SRTP is derived from the


session keys from the DTLS session. This does not in any way affect the
=
usage of the same DTLS session for passing DTLS data.





 As for RTP Session multiplexing, it's interesting =
to hear that
 proposals are dead.  Is there a proposal for multiplexing =
different
 media types (e.g., audio and video) within the sa!
 me RTP
Session,

 then?  RFC 3550 discourages that, but it was m=
y understanding that
 browser makers wanted to multiplex the different m=
edia types somehow. 
 What's the plan?

draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draf= t-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The onl= y thing in RTP itself that prevents such multiplexing is the
words in RF= C 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-isn't an RFC yet.


Paul



--047d7ba979c27f93d104fbe0c4c1-- From nobody Mon Jun 16 10:39:05 2014 Return-Path: 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 4926C1B287D for ; Sun, 15 Jun 2014 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 xR23YABTQ6DL for ; Sun, 15 Jun 2014 08:41:51 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB771B287E for ; Sun, 15 Jun 2014 08:41:50 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so4556518wes.26 for ; Sun, 15 Jun 2014 08:41:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W2rchFOq1+KofU6iY2jeyO+9JpkUfS9CBDQw0qecioU=; b=U6hQgk9RjqL3WTkJsRWlawVICFUPhD/pMJmf3o7yqNrVyRArmreC4zWQxJ68ca3YEq usQm+YDeXTFpmuPjCS20AOe51VC1F9i58UebWilMMR2n+xWWr/6IN0TLhISRU+xKMEUC 6Ume3VIOhLvv5uWwx72KoW9AQ/f0FY4TL7g1d73/GR4jjEjvgikzm2WqFNGi3QAj/0dU Wt63UMri7uTHBemIKxeQUw6yPOCxdPMCxAo5Vivu0/fXqL3+sYsX2ESGhmvKEmG76+6Q 5uXXlNIPGPBdSvudrql0m56wCOLQDm1DsT67+CGRDhwiCzH/r5Iy52qceo6QAcbysM0a YwTw== X-Gm-Message-State: ALoCoQmUqJl6n44Q/9/wXcur94v5ZALGcIOC4cYiVWUl4xtbyC8IZhg5b7+WNkoefk1JtttC7mRV X-Received: by 10.194.10.130 with SMTP id i2mr20370383wjb.70.1402846909209; Sun, 15 Jun 2014 08:41:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 15 Jun 2014 08:41:09 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <539D48B1.80003@alvestrand.no> <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> <539DAF41.50500@alvestrand.no> From: Eric Rescorla Date: Sun, 15 Jun 2014 08:41:09 -0700 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b450586b2c82004fbe1bfae Archived-At: http://mailarchive.ietf.org/arch/msg/dart/nPMoQnPBCQ-3_DhbRLo0euenqB4 X-Mailman-Approved-At: Mon, 16 Jun 2014 10:37:48 -0700 Cc: Harald Alvestrand , dart@ietf.org Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 15:41:53 -0000 --047d7b450586b2c82004fbe1bfae Content-Type: text/plain; charset=UTF-8 On Sun, Jun 15, 2014 at 8:30 AM, Paul E. Jones wrote: > Harald, > > I think we're saying the same thing. The multiplexing point is the SSRC, > correct? > > I said two media sources cannot use the same PT. Effectively, all PT > values used by an endpoint sending media are distinct. Is that correct? > No. Two media sources that are sending the same type of media (e.g., two streams of VP8) from the same endpoint can use the same PT as long as the SSRCs are different. See: http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.2.1.2 -Ekr My last question below is trying to understand why its not allowed for > SSRC1 and SSRC2, perhaps one being an audio source and one being a video > source, to use PT 97, for example. I think that's presently not allowed, > but not sure why since demux occurs on the SSRC. > > Paul > > > ------------------------------ > *From:* Harald Alvestrand > *Sent:* June 15, 2014 10:35:45 AM EDT > > *To:* "Paul E. Jones" , dart@ietf.org, Eric > Rescorla > *Subject:* Re: multiplexing different media types > > On 06/15/2014 04:24 PM, Paul E. Jones wrote: > > Harald, > > Thanks for the clarification. If you'll indulge, allow me to ask one more > basic question... > > In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to > explain that multiplexing is on the SSRC. It also says no two media sources > shall use the same PT value. > > > No, it does not say that - in fact, it says exactly the opposite. > > It says that it cannot use the same SSRC for two different media streams > and depend on PT to distinguish between them. PT is not a multiplexing > point. > > The PT value is a single byte, and is sometimes used for other purposes > (with RTP/RTCP multiplexing, for example, some numbers are unusable because > RTCP uses the same field for operation codes). Trying to use it to > distinguish between streams would reduce the max number of possible streams > to a seriously ridiculously low number. > > Can you point me at the language you interpreted that way? If it can be > read that way, it *must* be changed. > > Thus, a payload type could be used when demultiplexing, though the text > says otherwise. Perhaps this language exists to support multipoint? Thus, > a receiver first looks at the SSRC to identify the source, then the PT to > determine what the packet contains? Is SSRC demuxing there only for > multipoint? > > > No. The PT tells the receiver what format the packet contains. The SSRC > tells you which RTP packet flow it belongs to. In some cases one RTP packet > flow will switch between different payload types (audio, DTMF and comfort > noise being the most common examples), while still representing only one > media flow. > > > Why not allow the PT number space to be distinct per SSRC? > > > I have problems parsing this question into the context above. What are you > asking? > > Paul > > > ------------------------------ > *From:* Harald Alvestrand > *Sent:* June 15, 2014 3:18:09 AM EDT > *To:* "Paul E. Jones" , > dart@ietf.org, Eric Rescorla > *Subject:* Re: multiplexing different media types > > (Adding EKR to thread to get a definitive DTLS answer) > > On 06/15/2014 06:52 AM, Paul E. Jones wrote: >> >> Harald, >> >> >>> >>> "SCTP ... can be multiplexed with one or more RTP sessions". Actually >>> we can only multiplex SCTP with a single RTP session. There have been >>> proposals that would allow multiplexing of multiple RTP sessions >>> (each containing multiple media flows) over a single 5-tuple, but >>> these were not accepted. >> >> >> Your draft (draft-ietf-rtcweb-transports) says: >> >> RTCWEB implementations MUST support multiplexing of DTLS and RTP over >> the same port pair, as described in the DTLS_SRTP specification >> [RFC5764], section 5.1.2. A! >> ll >> application layer protocol payloads >> over this DTLS connection are SCTP packets. >> >> I had a question about this as we discussed the DART draft. I assumed >> the only DTLS connection would be one used for key negotiation for >> SRTP. Is that not the case? Would there be multiple DTLS connections >> multiplexed? If so, how would one be differentiated from another? > > > EKR is the expert here. > > As I understand it, the key material for DTLS-SRTP is derived from the > session keys from the DTLS session. This does not in any way affect the > usage of the same DTLS session for passing DTLS data. > >> >> >> As for RTP Session multiplexing, it's interesting to hear that >> proposals are dead. Is there a proposal for multiplexing different >> media types (e.g., audio and video) within the sa! >> me RTP >> Session, >> then? RFC 3550 discourages that, but it was my understanding that >> browser makers wanted to multiplex the different media types somehow. >> What's the plan? > > > draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. > draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. > > The only thing in RTP itself that prevents such multiplexing is the > words in RFC 3550; technically there is no barrier at the RTP level. > > At the SDP level things are a bit more complex, which is why -bundle- > isn't an RFC yet. > >> >> >> Paul > > > > --047d7b450586b2c82004fbe1bfae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 15, 2014 at 8:30 AM, Paul E. Jones &l= t;paulej@packeti= zer.com> wrote:

H= arald,

I think we're saying the same thing. The multiplexing po= int is the SSRC, correct?

I said two media sources cannot use the same PT. Effectively= , all PT values used by an endpoint sending media are distinct. Is that cor= rect?


No. Two media sources that = are sending the same type of media
(e.g., two streams of VP8) from the same endpoint can use the same
PT as long as the SSRCs are different. See:

http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-= 00#section-3.2.1.2=C2=A0

-Ekr

My last question below is trying to understand why its not a= llowed for SSRC1 and SSRC2, perhaps one being an audio source and one being= a video source, to use PT 97, for example. I think that's presently no= t allowed, but not sure why since demux occurs on the SSRC.

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 10:35:45 AM EDT

To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

=20 =20 =20 =20
On 06/15/2014 04:24 PM, Paul E. Jones wrote:

Harald,

Thanks for the clarification. If you'll indulge, allow me to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value.


No, it does not say that - in fact, it says exactly the opposite.

It says that it cannot use the same SSRC for two different media streams and depend on PT to distinguish between them. PT is not a multiplexing point.

The PT value is a single byte, and is sometimes used for other purposes (with RTP/RTCP multiplexing, for example, some numbers are unusable because RTCP uses the same field for operation codes). Trying to use it to distinguish between streams would reduce the max number of possible streams to a seriously ridiculously low number.

Can you point me at the language you interpreted that way? If it can be read that way, it *must* be changed.

Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint?=C2=A0 Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint?


No. The PT tells the receiver what format the packet contains. The SSRC tells you which RTP packet flow it belongs to. In some cases one RTP packet flow will switch between different payload types (audio, DTMF and comfort noise being the most common examples), while still representing only one media flow.


Why not allow the PT number space to be distinct per SSRC?


I have problems parsing this question into the context above. What are you asking?

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@= rtfm.com>
Subject: Re: multiplexing different media types

(Adding EKR to thread to get a definitive DTLS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:

 Harald,



 "SCTP ... can be multiplexed with one or more RTP se=
ssions". Actually
 we can only multiplex SCTP with a single RTP session. There have been
 proposals that would allow multiplexing of multiple RTP sessions
 (each containing multiple media flows) over a single 5-tuple, but
 these were not accepted.


 Your draft (draft-ietf-rtcweb-transports) says:

     RTCWEB implementations MUST support multiplexing of DTLS and RTP over
     the same port pair, as described in the DTLS_SRTP specification
     [RFC5764], section 5.1.2. A!
 ll
application layer protocol payloads
     over this DTLS connection are SCTP packets.

 I had a question about this as we discussed the DART draft.  I assumed
 the only DTLS connection would be one used for key negotiation for
 SRTP.  Is that not the case? Would there be multiple DTLS connections
 multiplexed?  If so, how would one be differentiated from another?


EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.



 As for RTP Session multiplexing, it's interesting to hear that
 proposals are dead.  Is there a proposal for multiplexing different
 media types (e.g., audio and video) within the sa!
 me RTP
Session,
 then?  RFC 3550 discourages that, but it was my understanding that
 browser makers wanted to multiplex the different media types somehow.=20
 What's the plan?


draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.



 Paul

=20

--047d7b450586b2c82004fbe1bfae-- From nobody Mon Jun 16 10:39:06 2014 Return-Path: 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 F11C31B2BAB for ; Sun, 15 Jun 2014 10:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 cwGIQ7oWZ6KR for ; Sun, 15 Jun 2014 10:02:11 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9DF1B2B66 for ; Sun, 15 Jun 2014 10:02:10 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so4251384wib.0 for ; Sun, 15 Jun 2014 10:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=J5j7+aIWurfuEzjHCyy2yfhJA41eNorB0DckdPw+FVU=; b=aG54POuGydpIKFyb2Oa3hOFquW4YzH/rbV0dJSxJBflvrvBz6g0v7TsG3KyeTkyFcb rYzSdI4PixqRaBCX5XuG2xX4lu/i/O+xWLRCPUZqV5V2Uvq45K6qIYSHTGjzDNyusU+S 4MI5CyJ3PdMZDFYgtTTu8ovebvjDaWyBdk9HaXpEwSvselviCAS+Hsn8H5oJUasUDFjX Zy0V/p33NEh6E5ylpiQNiDUIAPArZRSymjJ4Nty20LJFMj/uG1K5V3yObuaxa4yJ1w+F gpmpdLTbyJmHjx5NiexsQwaHdlecH2tqUPvuQWkzjEY1ZPL6UZEljFRrR7jgpxn0IgGZ Aw2Q== X-Gm-Message-State: ALoCoQnGR3DQmRzS1ezf2zwK+5yTdsDCArwhx4JWAudAglrjdp8Ygg5dvT5qrhzCXSfdiNTaftmS X-Received: by 10.195.13.79 with SMTP id ew15mr20913281wjd.19.1402851729136; Sun, 15 Jun 2014 10:02:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 15 Jun 2014 10:01:29 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <539D48B1.80003@alvestrand.no> <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> <539DAF41.50500@alvestrand.no> From: Eric Rescorla Date: Sun, 15 Jun 2014 10:01:29 -0700 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7bfd093afcfb4104fbe2dec2 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/z22cSKFwLCgB1O5uz6Wjk0Fb8GQ X-Mailman-Approved-At: Mon, 16 Jun 2014 10:37:50 -0700 Cc: Harald Alvestrand , dart@ietf.org Subject: Re: [Dart] multiplexing different media types X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 17:02:14 -0000 --047d7bfd093afcfb4104fbe2dec2 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones wrote: > Eric, > > Sorry, I should have been clearer in preparing the question. When I was > referring to media sources, I had completely different types in mind (e.g., > audio and video). > > What I am trying to understand is why there is this statement in the > guidelines draft: > > "The payload type is scoped by sending endpoint within an RTP Session. All > synchronisation sources sent from an single endpoint share the same payload > types definitions." > > Clearly, that is legal. But, I'm curious why we maintain this > restriction. Since a receiver will demux incoming packets via the SSRC, it > seems the PT values associated with a given SSRC could be distinct from > another SSRC. > > Presently for a given sender, there is a "global" definition of PT values > (96 for some specific audio format, 97 for some specific video format, ...) > and those can be used by multiple SSRCs. So I'm asking why we don't allow > {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each 96 could be different > formats. > What would be the virtue of doing that? -Ekr > Paul > > > ------------------------------ > *From:* Eric Rescorla > *Sent:* June 15, 2014 11:41:09 AM EDT > > *To:* "Paul E. Jones" > *Cc:* Harald Alvestrand , dart@ietf.org > > *Subject:* Re: multiplexing different media types > > > > > On Sun, Jun 15, 2014 at 8:30 AM, Paul E. Jones > wrote: > >> Harald, >> >> I think we're saying the same thing. The multiplexing point is the SSRC, >> correct? >> >> I said two media sources cannot use the same PT. Effectively, all PT >> values used by an endpoint sending media are distinct. Is that correct? >> > > No. Two media sources that are sending the same type of media > (e.g., two streams of VP8) from the same endpoint can use the same > PT as long as the SSRCs are different. See: > > > http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.2.1.2 > > > -Ekr > > My last question below is trying to understand why its not allowed for >> SSRC1 and SSRC2, perhaps one being an audio source and one being a video >> source, to use PT 97, for example. I think that's presently not allowed, >> but not sure why since demux occurs on the SSRC. >> >> Paul >> >> >> ------------------------------ >> *From:* Harald Alvestrand >> *Sent:* June 15, 2014 10:35:45 AM EDT >> >> *To:* "Paul E. Jones" , dart@ietf.org, Eric >> Rescorla >> *Subject:* Re: multiplexing different media types >> >> On 06/15/2014 04:24 PM, Paul E. Jones wrote: >> >> Harald, >> >> Thanks for the clarification. If you'll indulge, allow me to ask one more >> basic question... >> >> In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to >> explain that multiplexing is on the SSRC. It also says no two media sources >> shall use the same PT value. >> >> >> No, it does not say that - in fact, it says exactly the opposite. >> >> It says that it cannot use the same SSRC for two different media streams >> and depend on PT to distinguish between them. PT is not a multiplexing >> point. >> >> The PT value is a single byte, and is sometimes used for other purposes >> (with RTP/RTCP multiplexing, for example, some numbers are unusable because >> RTCP uses the same field for operation codes). Trying to use it to >> distinguish between streams would reduce the max number of possible streams >> to a seriously ridiculously low number. >> >> Can you point me at the language you interpreted that way? If it can be >> read that way, it *must* be changed. >> >> Thus, a payload type could be used when demultiplexing, though the text >> says otherwise. Perhaps this language exists to support multipoint? Thus, >> a receiver first looks at the SSRC to identify the source, then the PT to >> determine what the packet contains? Is SSRC demuxing there only for >> multipoint? >> >> >> No. The PT tells the receiver what format the packet contains. The SSRC >> tells you which RTP packet flow it belongs to. In some cases one RTP packet >> flow will switch between different payload types (audio, DTMF and comfort >> noise being the most common examples), while still representing only one >> media flow. >> >> >> Why not allow the PT number space to be distinct per SSRC? >> >> >> I have problems parsing this question into the context above. What are >> you asking? >> >> Paul >> >> >> ------------------------------ >> *From:* Harald Alvestrand >> *Sent:* June 15, 2014 3:18:09 AM EDT >> *To:* "Paul E. Jones" , >> dart@ietf.org, Eric Rescorla >> *Subject:* Re: multiplexing different media types >> >> (Adding EKR to thread to get a definitive DTLS answer) >> >> On 06/15/2014 06:52 AM, Paul E. Jones wrote: >>> >>> Harald, >>> >>> >>>> >>>> "SCTP ... can be multiplexed with one or more RTP sessions". Actually >>>> we can only multiplex SCTP with a single RTP session. There have been >>>> proposals that would allow multiplexing of multiple RTP sessions >>>> (each containing multiple media flows) over a single 5-tuple, but >>>> these were not accepted. >>> >>> >>> Your draft (draft-ietf-rtcweb-transports) says: >>> >>> RTCWEB implementations MUST support multiplexing of DTLS and RTP over >>> the same port pair, as described in the DTLS_SRTP specification >>> [RFC5764], section 5.1.2. A! >>> ll >>> application layer protocol payloads >>> over this DTLS connection are SCTP packets. >>> >>> I had a question about this as we discussed the DART draft. I assumed >>> the only DTLS connection would be one used for key negotiation for >>> SRTP. Is that not the case? Would there be multiple DTLS connections >>> multiplexed? If so, how would one be differentiated from another? >> >> >> EKR is the expert here. >> >> As I understand it, the key material for DTLS-SRTP is derived from the >> session keys from the DTLS session. This does not in any way affect the >> usage of the same DTLS session for passing DTLS data. >> >>> >>> >>> As for RTP Session multiplexing, it's interesting to hear that >>> proposals are dead. Is there a proposal for multiplexing different >>> media types (e.g., audio and video) within the sa! >>> me RTP >>> Session, >>> then? RFC 3550 discourages that, but it was my understanding that >>> browser makers wanted to multiplex the different media types somehow. >>> What's the plan? >> >> >> draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects. >> draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP. >> >> The only thing in RTP itself that prevents such multiplexing is the >> words in RFC 3550; technically there is no barrier at the RTP level. >> >> At the SDP level things are a bit more complex, which is why -bundle- >> isn't an RFC yet. >> >>> >>> >>> Paul >> >> >> >> > --047d7bfd093afcfb4104fbe2dec2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones &l= t;paulej@packeti= zer.com> wrote:

Eric,

Sorry, I should have been clearer in preparing the question.= When I was referring to media sources, I had completely different types in= mind (e.g., audio and video).

What I am trying to understand is why there is this statemen= t in the guidelines draft:

"The payload type is scoped by sending endpoint within = an RTP Session. All synchronisation sources sent from an single endpoint sh= are the same payload types definitions."

Clearly, that is legal. But, I'm curious why we maintain= this restriction.=C2=A0 Since a receiver will demux incoming packets via t= he SSRC, it seems the PT values associated with a given SSRC could be disti= nct from another SSRC.

Presently for a given sender, there is a "global" = definition of PT values (96 for some specific audio format, 97 for some spe= cific video format, ...) and those can be used by multiple SSRCs.=C2=A0 So = I'm asking why we don't allow {SSRC1: (96, 97), SSRC2: (96, 97), ..= .}, where each 96 could be different formats.

What would be the virtue of doing that?
<= br>
-Ekr
=C2=A0

Paul



From: Eric Rescorla <ekr@rtfm.com>
Sent: June 15, 2014 11:41:09 AM EDT

To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, dart@ietf.org

Subject: Re: multiplexing different media types




On Sun, Jun 15, 2014 at 8:30 AM, Paul E. Jones &l= t;paulej@packeti= zer.com> wrote:

H= arald,

I think we're saying the same thing. The multiplexing po= int is the SSRC, correct?

I said two media sources cannot use the same PT. Effectively= , all PT values used by an endpoint sending media are distinct. Is that cor= rect?


No. Two media sources that = are sending the same type of media
(e.g., two streams of VP8) from the same endpoint can use the same
PT as long as the SSRCs are different. See:

http://tools.ietf.org/html/draft-roach-mm= usic-unified-plan-00#section-3.2.1.2=C2=A0

-Ekr

My last question below is trying to understand why its not a= llowed for SSRC1 and SSRC2, perhaps one being an audio source and one being= a video source, to use PT 97, for example. I think that's presently no= t allowed, but not sure why since demux occurs on the SSRC.

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 10:35:45 AM EDT

To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

=20 =20 =20 =20
On 06/15/2014 04:24 PM, Paul E. Jones wrote:

Harald,

Thanks for the clarification. If you'll indulge, allow me to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value.


No, it does not say that - in fact, it says exactly the opposite.

It says that it cannot use the same SSRC for two different media streams and depend on PT to distinguish between them. PT is not a multiplexing point.

The PT value is a single byte, and is sometimes used for other purposes (with RTP/RTCP multiplexing, for example, some numbers are unusable because RTCP uses the same field for operation codes). Trying to use it to distinguish between streams would reduce the max number of possible streams to a seriously ridiculously low number.

Can you point me at the language you interpreted that way? If it can be read that way, it *must* be changed.

Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint?=C2=A0 Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint?


No. The PT tells the receiver what format the packet contains. The SSRC tells you which RTP packet flow it belongs to. In some cases one RTP packet flow will switch between different payload types (audio, DTMF and comfort noise being the most common examples), while still representing only one media flow.


Why not allow the PT number space to be distinct per SSRC?


I have problems parsing this question into the context above. What are you asking?

Paul



From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@= rtfm.com>
Subject: Re: multiplexing different media types

(Adding EKR to thread to get a definitive DTLS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:

 Harald,



 "SCTP ... can be multiplexed with one or more RTP se=
ssions". Actually
 we can only multiplex SCTP with a single RTP session. There have been
 proposals that would allow multiplexing of multiple RTP sessions
 (each containing multiple media flows) over a single 5-tuple, but
 these were not accepted.


 Your draft (draft-ietf-rtcweb-transports) says:

     RTCWEB implementations MUST support multiplexing of DTLS and RTP over
     the same port pair, as described in the DTLS_SRTP specification
     [RFC5764], section 5.1.2. A!
 ll
application layer protocol payloads
     over this DTLS connection are SCTP packets.

 I had a question about this as we discussed the DART draft.  I assumed
 the only DTLS connection would be one used for key negotiation for
 SRTP.  Is that not the case? Would there be multiple DTLS connections
 multiplexed?  If so, how would one be differentiated from another?


EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.



 As for RTP Session multiplexing, it's interesting to hear that
 proposals are dead.  Is there a proposal for multiplexing different
 media types (e.g., audio and video) within the sa!
 me RTP
Session,
 then?  RFC 3550 discourages that, but it was my understanding that
 browser makers wanted to multiplex the different media types somehow.=20
 What's the plan?


draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.



 Paul

=20


--047d7bfd093afcfb4104fbe2dec2-- From nobody Mon Jun 16 10:44:48 2014 Return-Path: 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 8E74D1A0125 for ; Mon, 16 Jun 2014 10:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 UEPVyLmgTRKA for ; Mon, 16 Jun 2014 10:44:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7AA1A0132 for ; Mon, 16 Jun 2014 10:44:06 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5GHhfbc089252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 16 Jun 2014 12:44:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell Date: Mon, 16 Jun 2014 12:44:05 -0500 X-Mao-Original-Outgoing-Id: 424633445.495506-456049caff3c429c6fe18ff0b9d30aaa Content-Transfer-Encoding: quoted-printable Message-Id: <5C507555-5392-429E-8F16-35CC3DDF5724@nostrum.com> References: <18924.1402682912@sandelman.ca> To: dart@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/y3kKaiqi7N3sXcb8gsUe8FkFnsw Subject: [Dart] Fwd: third call: NomCom 2014-2015 Call for Volunteers X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 17:44:27 -0000 Hi All, Please help out the nomcom! Thanks! Ben. Begin forwarded message: > From: Michael Richardson > Subject: third call: NomCom 2014-2015 Call for Volunteers > Date: June 13, 2014 at 1:08:32 PM CDT > To: ietf@ietf.org >=20 >=20 > This is the third call for volunteers. > VOLUNTEER NOW: we need to make 200. > The DEADLINE is June 26 to volunteer. >=20 > The IETF nomcom appoints folks to fill the open slots on the IAOC, the = IAB, > and the IESG (including IETF Chair). >=20 > If your name is on the below, then you have volunteered and are = qualified. > In addition to those who volunteered by email, it also includes those = who > indicated their willingness to serve on the IETF90 registration form, = and > whose eligibility has been confirmed. 54 people were confirmed to be > eligible, and 70 people were not confirmed based upon the email they = have > used to register. Those 124 people have been contacted directly. >=20 > If you have heard from me, but are not on the list, then there is some > problem, and you should have gotten a query from me to determine your > eligibility. >=20 > If you have volunteered and not heard from him, then please resend; > it got lost. >=20 > Ten voting members for the nomcom are selected in a verifiably random > way from a pool of volunteers. The more volunteers, the better chance = we have > of choosing a random yet representative cross section of the IETF = population. >=20 > Let's break the 200 volunteer mark again this year! > We are at 123 volunteers so far, and WE NEED TO HAVE 200!!! >=20 > The details of the operation of the nomcom can be found in RFC 3777, > and BCP10/RFC3797 details the selection algorithm. >=20 > Volunteers must have attended 3 of the past 5 IETF meetings. As = specified in > RFC 3777, that means three out of the five past meetings up to the = time this > email announcement goes out to start the solicitation of volunteers. > The five meetings out of which you must have attended *three* > are IETF 85(Atlanta), \ > 86(Orlando), \ > 87(Berlin), *** ANY THREE! > 88(Vancouver), / > 89(London) / >=20 > If you qualify, please volunteer. However, much as we want this, = before you > decide to volunteer, please be sure you are willing to forgo = appointment > to any of the positions for which this nomcom is responsible. >=20 > The list of people and posts whose terms end with the March 2015 IETF > meeting, and thus the positions for which this nomcom is responsible, = are >=20 > IAOC: > To be confirmed >=20 > IAB: > Joel Halpern > Russ Housley > Eliot Lear > Xing Li > Andrew Sullivan > Dave Thaler >=20 > IESG: > Pete Resnick (Applications) > Ted Lemon (Internet) > Joel Jaeggli (Operations and Management) > Richard Barnes (RAI) > Adrian Farrel* (Routing) > Stephen Farrell (Security) > Spencer Dawkins (Transport) > Jari Arkko (Gen) >=20 > (names with * have publically indicated they will not serve another = term) >=20 > The primary activity for this nomcom will begin in July 2014 and = should be > completed in January 2015. The nomcom will have regularly scheduled > conference calls to ensure progress. (We might dogfood WebRTC) > There will be activities to collect requirements from the community, = review > candidate questionnaires, review feedback from community members about > candidates, and talk to candidates. >=20 > Thus, being a nomcom member does require some time commitment; but it = is also > a very rewarding experience. >=20 > It is very important that you be able to attend IETF91 to conduct = interviews. > Being at IETF90 is useful for training. Being at IETF92 is not = essential. >=20 > Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 = hours) > June 22, 2013, as follows: >=20 > To: nomcom-chair-2014@ietf.org > Subject: Nomcom 2014-15 Volunteer >=20 > Please include the following 4 lines the email body (it is simplest > if you just include the info); >=20 > Your Full Name > Emails used to register > Telephone > Current Primary Affiliation >=20 > You should expect an email response from me within 3 business days = stating > whether or not you are qualified. If you don't receive this response, > please re-send your email with the tag "RESEND"" added to the subject = line. >=20 > If you are not yet sure if you would like to volunteer, please = consider > that nomcom members play a very important role in shaping the = leadership > of the IETF. Questions by email or voice are welcome. > Volunteering for the nomcom is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the nomcom web site at: > https://datatracker.ietf.org/nomcom/2014/ >=20 > I will be publishing a more detailed target timetable, as well as = details > of the randomness seeds to be used for the RFC 3797 selection process, > within the next couple weeks. >=20 > Thank you! > Michael Richardson > mcr+nomcom@sandelman.ca > nomcom-chair-2014@ietf.org >=20 > =3D=3D=3D=3D=3D qualified volunteers so far, in alphabetical order by = first name > ANM Zaheduzzaman Sarker > Adam Montville > Ari Ker?nen > Benson Schliesser > Bhumip Khasnabish > Bill VerSteeg > Carl Williams > Carlos Martinez > Charles Eckel > Charles Perkins > Christer Holmberg > Craig White > DHRUV DHODY > Dacheng Zhang > Damien Saucez > Dapeng Liu > Dean Bogdanovic > Dimitri Papadimitriou > Donald Eastlake > Edward Crabbe > Emil Ivov > Eric Rescorla > Eric VYNCKE > Fangwei Hu > Fatai Zhang > Fernando Gont > Fred Baker > Giles Heron > Gonzalo Salgueiro > Gregory Mirsky > Hannes Gredler > Hongyu Li > Hosnieh Rafiee > Hugo Salgado > Hui Deng > Iuniana Oprescu > Jeff Tantsura > John Drake > John Jason Brzozowski > John Levine > John Scudder > Jon Hudson > Jon Mitchell > Karen O'Donoghue > Karen Seo > Kaveh Ranjbar > Klaas Wierenga > Larry Masinter > Lars Eggert > Lee Howard > Lei Zhu > Li Xue > Linda Dunbar > Lingli Deng > Louis (Lou) Berger > Luca Martini > Lucy Lynch > Lucy Yong > Luigi Iannone > Mach Chen > Marcelo Bagnulo > Mark Townsley > Matt Lepinski > Matthew Bocci > Mehmet Ersue > Melinda Shore > Michael Jones > Min Ye > Mingui Zhang > Ning Zong > Ole Troan > Pascal Thubert > Paul Hoffman > Peter Lothberg > Peter Yee > QIN WU > Ralph Droms > Ron Bonica > Ross Callon > Ross Finlayson > Russ White > Sam K. Aldrin > Samuel Weiler > Sandeep Kumar > Sanjay Mishra > Scott Mansfield > Sheng JIANG > Shucheng Liu > Simon Pietro Romano > Stan Ratliff > Stephan Friedl > Stephan Wenger > Stephen Kent > Stewart Bryant > Stig Venaas > Suhas Nandakumar > Suresh Krishnan > Susan Hares > Thomas Walsh > Tim Wicinski > Tissa Senevirathne > Toerless Eckert > Tony Hansen > Ulrich Herberg > Varun Singh > Wassim Haddad > Xiaohu XU > Yi Zhao > Yizhou Li > Yong Cui > Yuanlong Jiang > Yunfei Zhang > Zhaohui Zhang > Zhen Cao > iuniana oprescu >=20 >=20 > -- > Michael Richardson > mcr+nomcom@sandelman.ca > nomcom-chair-2014@ietf.org >=20 >=20 >=20 From nobody Mon Jun 16 14:58:38 2014 Return-Path: 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 9C0F51A0286 for ; Mon, 16 Jun 2014 14:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 nC2JhZ8O4XjE for ; Mon, 16 Jun 2014 14:58:32 -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 43ECF1A0278 for ; Mon, 16 Jun 2014 14:58:31 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5GLwUkF032286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 17:58:30 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5GLwUkF032286 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402955910; bh=JygJz1agOHYrCRRD9JAalQJ40eU=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=W0nQWJv0ZaZYrL4s3PfOErz/PEkPsg9v9fn3PEWlwjK/LqKdGUXdeMNZhS423/nTI WwR4XCmdSR0GNJorGwSTMB/0HR9k5NNHCxu6/FB6ca4a/sA/dCI3nyHqJiEhPLZtTp U04GGDzoS3rjR8Wjyk/0YeOryY64ZHs+4B8BvnYM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5GLwUkF032286 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 16 Jun 2014 17:58:11 -0400 Received: from mxhub38.corp.emc.com (mxhub38.corp.emc.com [128.222.70.105]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5GLwANv021633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jun 2014 17:58:10 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Mon, 16 Jun 2014 17:58:10 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Mon, 16 Jun 2014 17:58:09 -0400 Thread-Topic: AF - DSCPs, PHBs and remarking Thread-Index: Ac+Jrg91Wx6GNA7VR2CrgHbx5skqHw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FF26B09@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/i4Teb521A8AttwLfaBdwu2i0KCs Cc: "dart@ietf.org" Subject: [Dart] AF - DSCPs, PHBs and remarking X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 21:58:36 -0000 Hi Ruediger, > Incoming AF4n -> outgoing AF4 with a cost of 1 local PHB is (for example)= : >=20 > Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 100 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 110 -> outgoing DSCP 100 010 PHB AF41 > > The other option, with a cost of 3 local PHBs is >=20 > Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 100 -> outgoing DSCP 100 100 PHB AF42 > Incoming DSCP 100 110 -> outgoing DSCP 100 110 PHB AF43 Well, what ought to happen (based on the original design of AF) is neither 1-1 PHB mapping nor classification by only the first three bits of the DSCP, as the latter approach would also run CS4 (DSCP 100 000) through the same queue as AF4x. The desired treatment is to classify by DSCP, but put inbound traffic with three DSCPs for AF4x into one queue preserving packet order. The DiffServ term for this set of traffic that uses the three AF4x PHBs (with a DSCP for each) is "ordered aggregate" - see Section 5 of RFC 3260. After initial classification has separated out the ordered aggregate, it can be run through an AF remarker in order to condition the outbound proportions of AF41/42/43 to match some desired distribution. For examples of AF remarkers that can be used for this purpose, see RFC 2697 and RFC 2698. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of > Ruediger.Geib@telekom.de > Sent: Monday, June 16, 2014 2:54 AM > To: Black, David > Cc: dart@ietf.org > Subject: Re: [Dart] Commentary on draft-york-00 >=20 > Hi David, >=20 > to make sure we mean the same thing on AF, re-marking and PHB consumption= : >=20 > If a network provider just supports aggregated classes and that provider = must > use DSCP based classification then >=20 > Incoming AF4n -> outgoing AF4 with a cost of 1 local PHB is (for example)= : >=20 > Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 100 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 110 -> outgoing DSCP 100 010 PHB AF41 >=20 > The other option, with a cost of 3 local PHBs is >=20 > Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 100 -> outgoing DSCP 100 100 PHB AF42 > Incoming DSCP 100 110 -> outgoing DSCP 100 110 PHB AF43 >=20 > If there was an additional possibility to classify based on > DSCP bits 0-2, the second option can be configured with a cost > of 1 local PHB (results in an aggregate / single local PHB for > the provider and 3 DSCPs for an application or a device closer > to the network edge). >=20 > Regards, >=20 > Ruediger >=20 > -----Urspr=FCngliche Nachricht----- > Von: Black, David [mailto:david.black@emc.com] > Gesendet: Freitag, 13. Juni 2014 15:24 > An: Geib, R=FCdiger > Cc: dart@ietf.org > Betreff: RE: [Dart] Commentary on draft-york-00 >=20 > Hi Ruediger >=20 > Many thanks for the additional information. I have a few comments: >=20 > > - there used to be a possibility to ignore the lower DSCP > > bits 3-6, but there's no standard to that. Some vendors > > removed this option and with IPv6, each PHB must be > > classified and completely configured individually by DSCP. >=20 > That's a good thing, since that behavior (per DSCP traffic > handling) is a core element of the DiffServ architecture, and is required= by > RFC 2474 (Section 3). >=20 > > Please be aware, if it comes to a re-write, a single DSCP > > is set for all incoming DSCPs matching this PHB. Keep in > > mind the possible restrictions on the number of PHBs. >=20 > Full AF support should classify all 3 PHBs that make up an AF class into = a > single aggregate on the node, with remarking applied to that aggregate, n= ot > DSCP by DSCP. >=20 > > If end-to-end DiffServ PHBs are what you look for, standardize what is > > really required and be clear on how to use it. >=20 > As noted earlier, that's not the goal of the dart WG, as I understand it.= I > believe the goal of this short term WG is to describe what exists and pro= vide > guidance on how to use it, particularly for RTCWEB. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Friday, June 13, 2014 4:05 AM > > To: Black, David > > Cc: dart@ietf.org > > Subject: AW: [Dart] Commentary on draft-york-00 > > > > Hi David, > > > > to answer the question related to implementations and configurations > > at least from the viewpoint of one network provider > > > > - you can support a multi-vendor strategy. This makes sense > > from an economical point of view, but limits > > deployments to the minimum common denominator. > > > > - to configure a PHB, there are classifiers, policers, > > schedulers, AQM and re-markers. > > Implementations differ to some aspects (e.g. on > > supported number of classes and ingress/egress remarking). > > Limits like less than 20 PHBs may apply today. > > I'd be interested, whether there are offers of any > > complete AF class as part of a single product. > > > > - there used to be a possibility to ignore the lower DSCP > > bits 3-6, but there's no standard to that. Some vendors > > removed this option and with IPv6, each PHB must be > > classified and completely configured individually by DSCP. > > Please be aware, if it comes to a re-write, a single DSCP > > is set for all incoming DSCPs matching this PHB. Keep in > > mind the possible restrictions on the number of PHBs. > > > > - many IP/MPLS backbone networks and also many Ethernet > > based access networks support 3-4 PHBs for retail services. > > I'm not aware of any two providers using exactly the > > same DSCPs. I'm also not aware of any two standards using fully > > matching DSCPs for their PHBs (IETF, GSMA, MEF). > > > > - There's something I'd call enterprise philosophy, that is > > making use of a large set of internal PHBs. I never saw > > any of these philosophies remotely resembling the other. > > PHBs or classes are used to identify products, > > access types, stream types and so on. These usually just > > consume PHBs with sometimes at best loose relation to > > standards. > > > > If end-to-end DiffServ PHBs are what you look for, standardise what is > > really required and be clear on how to use it. If a network provider > > is expected to support these PHBs, there must be a convincing reason > > to do so. Take EF as an example for a well specified DiffServ standard. > > > > Regards, > > > > Ruediger > > > > -----Urspr=FCngliche Nachricht----- > > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Black, David > > Gesendet: Freitag, 13. Juni 2014 07:43 > > An: Harald Alvestrand; dart@ietf.org > > Betreff: Re: [Dart] Commentary on draft-york-00 > > > > Harald, > > > > Many thanks for the review and commentary, especially for the discus= sion > > of real time traffic sensitivity to reordering. This note is an att= empt > > to pick up non-editorial items that haven't been dealt with in other > > messages on the list. I see four of them: > > > > RG: [snip] > > > > [4] > > > 2.4 DSCP remarking > > > > > > The discussion of token-bucket-based remarkers leaves me a bit > confused. > > > To me, it's obvious (?) that token-bucket-based remarkers would > > > operate in color-blind mode on a network boundary, and in > > > color-sensitive mode only when they had assurance that incoming > > > markings were already indicating color. Thus, flows from an end-us= er > > > system should only hit color-blind remarkers; the real question is= : > > > will a color-blind remarker use the incoming DSCP codepoint to dec= ide > > > which of a group of remarking treatments it chooses for the packet= s? > > > > I'm not sure about the "obvious" point - anyone care to comment on w= hat's > > actually deployed/configured in practice? > > > > The answer to the final question about choice of remarking treatment= is > > "yes" although the PHBs in an AF class should receive the same treat= ment. > > The fact that the question was asked suggests that the discussion of > > traffic classifiers needs some additional clarity and explanation. > > > > Thanks, > > --David > > >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Tue Jun 17 00:52:30 2014 Return-Path: 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 627911A02D9 for ; Tue, 17 Jun 2014 00:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=no 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 68woycOa_nVj for ; Tue, 17 Jun 2014 00:52:23 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57031A02C8 for ; Tue, 17 Jun 2014 00:52:21 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 17 Jun 2014 09:52:19 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 17 Jun 2014 09:52:19 +0200 From: To: Date: Tue, 17 Jun 2014 09:52:18 +0200 Thread-Topic: AF - DSCPs, PHBs and remarking Thread-Index: Ac+Jrg91Wx6GNA7VR2CrgHbx5skqHwATLJxQ Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076FF26B09@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FF26B09@MX15A.corp.emc.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Z4VkPD1eZDvJyig6QbYxEjiBCLY Cc: dart@ietf.org Subject: Re: [Dart] AF - DSCPs, PHBs and remarking X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 07:52:26 -0000 Hi David, you are of course correct with your assessment on standards. You've asked=20 for information on what's implemented today and that's what I've provided. Each AF DSCP identifies an individual PHB. If classification is DSCP=20 based and limits apply on the number of PHBs, that's what providers have=20 to respect. This limit still applies, if e.g. all AF4 packets are operated= =20 by the same scheduler (which I'd expect from a provider deployment). It is also somewhat demanding to configure 14 PHBs to support just rtcweb=20 on a retail access and then provide additional PHBs for services of a=20 provider. The provider may offer some services with admission control and=20 if rtcweb isn't running through the same admission control, this requires=20 additional PHBs. Some carriers may have deployed DiffServ already, when=20 rtcweb starts to use it.=20 Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Black, David [mailto:david.black@emc.com]=20 Gesendet: Montag, 16. Juni 2014 23:58 An: Geib, R=FCdiger Cc: dart@ietf.org Betreff: AF - DSCPs, PHBs and remarking Hi Ruediger, > Incoming AF4n -> outgoing AF4 with a cost of 1 local PHB is (for example)= : >=20 > Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 100 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 110 -> outgoing DSCP 100 010 PHB AF41 > > The other option, with a cost of 3 local PHBs is >=20 > Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 100 -> outgoing DSCP 100 100 PHB AF42 > Incoming DSCP 100 110 -> outgoing DSCP 100 110 PHB AF43 Well, what ought to happen (based on the original design of AF) is neither = 1-1 PHB mapping nor classification by only the first three bits of the DSCP= , as the latter approach would also run CS4 (DSCP 100 000) through the same queue as AF4x. The desired treatment is to classify by DSCP, but put inbound traffic with = three DSCPs for AF4x into one queue preserving packet order. The DiffServ = term for this set of traffic that uses the three AF4x PHBs (with a DSCP for= each) is "ordered aggregate" - see Section 5 of RFC 3260. After initial classification has separated out the ordered aggregate, it ca= n be run through an AF remarker in order to condition the outbound proporti= ons of AF41/42/43 to match some desired distribution. For examples of AF r= emarkers that can be used for this purpose, see RFC 2697 and RFC 2698. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of=20 > Ruediger.Geib@telekom.de > Sent: Monday, June 16, 2014 2:54 AM > To: Black, David > Cc: dart@ietf.org > Subject: Re: [Dart] Commentary on draft-york-00 >=20 > Hi David, >=20 > to make sure we mean the same thing on AF, re-marking and PHB consumption= : >=20 > If a network provider just supports aggregated classes and that=20 > provider must use DSCP based classification then >=20 > Incoming AF4n -> outgoing AF4 with a cost of 1 local PHB is (for example)= : >=20 > Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 100 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 110 -> outgoing DSCP 100 010 PHB AF41 >=20 > The other option, with a cost of 3 local PHBs is >=20 > Incoming DSCP 100 010 -> outgoing DSCP 100 010 PHB AF41 > Incoming DSCP 100 100 -> outgoing DSCP 100 100 PHB AF42 > Incoming DSCP 100 110 -> outgoing DSCP 100 110 PHB AF43 >=20 > If there was an additional possibility to classify based on DSCP bits=20 > 0-2, the second option can be configured with a cost of 1 local PHB=20 > (results in an aggregate / single local PHB for the provider and 3=20 > DSCPs for an application or a device closer to the network edge). >=20 > Regards, >=20 > Ruediger >=20 > -----Urspr=FCngliche Nachricht----- > Von: Black, David [mailto:david.black@emc.com] > Gesendet: Freitag, 13. Juni 2014 15:24 > An: Geib, R=FCdiger > Cc: dart@ietf.org > Betreff: RE: [Dart] Commentary on draft-york-00 >=20 > Hi Ruediger >=20 > Many thanks for the additional information. I have a few comments: >=20 > > - there used to be a possibility to ignore the lower DSCP > > bits 3-6, but there's no standard to that. Some vendors > > removed this option and with IPv6, each PHB must be > > classified and completely configured individually by DSCP. >=20 > That's a good thing, since that behavior (per DSCP traffic > handling) is a core element of the DiffServ architecture, and is=20 > required by RFC 2474 (Section 3). >=20 > > Please be aware, if it comes to a re-write, a single DSCP > > is set for all incoming DSCPs matching this PHB. Keep in > > mind the possible restrictions on the number of PHBs. >=20 > Full AF support should classify all 3 PHBs that make up an AF class=20 > into a single aggregate on the node, with remarking applied to that=20 > aggregate, not DSCP by DSCP. >=20 > > If end-to-end DiffServ PHBs are what you look for, standardize what=20 > > is really required and be clear on how to use it. >=20 > As noted earlier, that's not the goal of the dart WG, as I understand=20 > it. I believe the goal of this short term WG is to describe what=20 > exists and provide guidance on how to use it, particularly for RTCWEB. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Friday, June 13, 2014 4:05 AM > > To: Black, David > > Cc: dart@ietf.org > > Subject: AW: [Dart] Commentary on draft-york-00 > > > > Hi David, > > > > to answer the question related to implementations and configurations=20 > > at least from the viewpoint of one network provider > > > > - you can support a multi-vendor strategy. This makes sense > > from an economical point of view, but limits > > deployments to the minimum common denominator. > > > > - to configure a PHB, there are classifiers, policers, > > schedulers, AQM and re-markers. > > Implementations differ to some aspects (e.g. on > > supported number of classes and ingress/egress remarking). > > Limits like less than 20 PHBs may apply today. > > I'd be interested, whether there are offers of any > > complete AF class as part of a single product. > > > > - there used to be a possibility to ignore the lower DSCP > > bits 3-6, but there's no standard to that. Some vendors > > removed this option and with IPv6, each PHB must be > > classified and completely configured individually by DSCP. > > Please be aware, if it comes to a re-write, a single DSCP > > is set for all incoming DSCPs matching this PHB. Keep in > > mind the possible restrictions on the number of PHBs. > > > > - many IP/MPLS backbone networks and also many Ethernet > > based access networks support 3-4 PHBs for retail services. > > I'm not aware of any two providers using exactly the > > same DSCPs. I'm also not aware of any two standards using fully > > matching DSCPs for their PHBs (IETF, GSMA, MEF). > > > > - There's something I'd call enterprise philosophy, that is > > making use of a large set of internal PHBs. I never saw > > any of these philosophies remotely resembling the other. > > PHBs or classes are used to identify products, > > access types, stream types and so on. These usually just > > consume PHBs with sometimes at best loose relation to > > standards. > > > > If end-to-end DiffServ PHBs are what you look for, standardise what=20 > > is really required and be clear on how to use it. If a network=20 > > provider is expected to support these PHBs, there must be a=20 > > convincing reason to do so. Take EF as an example for a well specified = DiffServ standard. > > > > Regards, > > > > Ruediger > > > > -----Urspr=FCngliche Nachricht----- > > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Black, David > > Gesendet: Freitag, 13. Juni 2014 07:43 > > An: Harald Alvestrand; dart@ietf.org > > Betreff: Re: [Dart] Commentary on draft-york-00 > > > > Harald, > > > > Many thanks for the review and commentary, especially for the discus= sion > > of real time traffic sensitivity to reordering. This note is an att= empt > > to pick up non-editorial items that haven't been dealt with in other > > messages on the list. I see four of them: > > > > RG: [snip] > > > > [4] > > > 2.4 DSCP remarking > > > > > > The discussion of token-bucket-based remarkers leaves me a bit > confused. > > > To me, it's obvious (?) that token-bucket-based remarkers would > > > operate in color-blind mode on a network boundary, and in > > > color-sensitive mode only when they had assurance that incoming > > > markings were already indicating color. Thus, flows from an end-us= er > > > system should only hit color-blind remarkers; the real question is= : > > > will a color-blind remarker use the incoming DSCP codepoint to dec= ide > > > which of a group of remarking treatments it chooses for the packet= s? > > > > I'm not sure about the "obvious" point - anyone care to comment on w= hat's > > actually deployed/configured in practice? > > > > The answer to the final question about choice of remarking treatment= is > > "yes" although the PHBs in an AF class should receive the same treat= ment. > > The fact that the question was asked suggests that the discussion of > > traffic classifiers needs some additional clarity and explanation. > > > > Thanks, > > --David > > >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Tue Jun 17 03:33:58 2014 Return-Path: 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 B17061A0340 for ; Tue, 17 Jun 2014 03:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 ob6AV28H_-O8 for ; Tue, 17 Jun 2014 03:33:52 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1986F1A0336 for ; Tue, 17 Jun 2014 03:33:51 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1Wwqhx-0007mO-07; Tue, 17 Jun 2014 12:33:41 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id E852EA8079D; Tue, 17 Jun 2014 12:33:48 +0200 (CEST) Message-ID: <53A0198C.4000204@kit.edu> Date: Tue, 17 Jun 2014 12:33:48 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de, david.black@emc.com References: <8D3D17ACE214DC429325B2B98F3AE712076FF26B09@MX15A.corp.emc.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1403001221. Archived-At: http://mailarchive.ietf.org/arch/msg/dart/FqhsFWVH2Je-6_7i1vo93JjEyzo Cc: dart@ietf.org Subject: Re: [Dart] AF - DSCPs, PHBs and remarking X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 10:33:56 -0000 Hi Ruediger, Am 17.06.2014 09:52, schrieb Ruediger.Geib@telekom.de: > you are of course correct with your assessment on standards. You've asked > for information on what's implemented today and that's what I've provided. > > Each AF DSCP identifies an individual PHB. If classification is DSCP > based and limits apply on the number of PHBs, that's what providers have > to respect. This limit still applies, if e.g. all AF4 packets are operated > by the same scheduler (which I'd expect from a provider deployment). Each AF class (2 or 3 PHBs) usually only needs a single queue. It is not allowed to map an AF class to only a single PHB: Within each AF class, a DS node MUST accept all three drop precedence codepoints and they MUST yield at least two different levels of loss probability. So at least one needs to distinguish between AFx1 and AFx2/AFx3. > It is also somewhat demanding to configure 14 PHBs to support just rtcweb > on a retail access and then provide additional PHBs for services of a > provider. The provider may offer some services with admission control and If you want to realize all proposed mappings of http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-00 you probably need 7 separate queues (LE, BE, AF1-AF4, EF) and at most 15 DSCP to PHB mappings. > if rtcweb isn't running through the same admission control, this requires > additional PHBs. Some carriers may have deployed DiffServ already, when > rtcweb starts to use it. I think that you'll need admission control for EF and AFx1 PHBs otherwise you'll end up with best-effort behavior in overload situations... Regards, Roland From nobody Tue Jun 17 05:14:45 2014 Return-Path: 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 06FF31A036A for ; Tue, 17 Jun 2014 05:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 Ofv5i4LgNRFV for ; Tue, 17 Jun 2014 05:14:37 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42531A0369 for ; Tue, 17 Jun 2014 05:14:36 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 17 Jun 2014 14:14:10 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 17 Jun 2014 14:14:10 +0200 From: To: Date: Tue, 17 Jun 2014 14:14:09 +0200 Thread-Topic: [Dart] AF - DSCPs, PHBs and remarking Thread-Index: Ac+KF8kGeFP4JQQHQe2xzJ43VqvlrAAB0YFA Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076FF26B09@MX15A.corp.emc.com> <53A0198C.4000204@kit.edu> In-Reply-To: <53A0198C.4000204@kit.edu> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Jm3Y8c8QZuTmB-6dQmIjF7eG4QA Cc: dart@ietf.org Subject: Re: [Dart] AF - DSCPs, PHBs and remarking X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 12:14:42 -0000 Hi Roland, yes, of course all AFx packets use the same queue (and AFy another).=20 That's independent of the number of drop levels. My point is, if a=20 separate DSCP is desired on egress, a separate classification for=20 a PHB is required on ingress. If your choice is 3 DSCPs for AFx class,=20 then the queue may be configured to produce one, two or three=20 differing drop levels. This may be relevant for standards compliance,=20 but not for the number of PHBs to be configured.=20 In this thread, we seem to either explain the same thing to each other=20 or talk past each other.=20 Thanks for correcting my count of PHBs, I forgot EF. And yes, 7 queues=20 for RTCweb. That's another restricted resource. Admission control must work the same way for all flows of a PHB where=20 it is deployed. Otherwise it is pointless. Will RTCWeb align well=20 with e.g. an IMS VoIP solution running through admission control=20 if both intend to use EF? Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Bless, Roland (TM) Gesendet: Dienstag, 17. Juni 2014 12:34 An: Geib, R=FCdiger; david.black@emc.com Cc: dart@ietf.org Betreff: Re: [Dart] AF - DSCPs, PHBs and remarking Hi Ruediger, Am 17.06.2014 09:52, schrieb Ruediger.Geib@telekom.de: > you are of course correct with your assessment on standards. You've=20 > asked for information on what's implemented today and that's what I've pr= ovided. >=20 > Each AF DSCP identifies an individual PHB. If classification is DSCP=20 > based and limits apply on the number of PHBs, that's what providers=20 > have to respect. This limit still applies, if e.g. all AF4 packets are=20 > operated by the same scheduler (which I'd expect from a provider deployme= nt). Each AF class (2 or 3 PHBs) usually only needs a single queue. It is not allowed to map an AF class to only a single PHB: Within each AF class, a DS node MUST accept all three drop precedence codepoints and they MUST yield at least two different levels of loss probability. So at least one needs to distinguish between AFx1 and AFx2/AFx3. > It is also somewhat demanding to configure 14 PHBs to support just=20 > rtcweb on a retail access and then provide additional PHBs for=20 > services of a provider. The provider may offer some services with=20 > admission control and If you want to realize all proposed mappings of http://tools.ietf.org/html/= draft-ietf-tsvwg-rtcweb-qos-00 you probably need 7 separate queues (LE, BE, AF1-AF4, EF) and at most 15 DS= CP to PHB mappings. > if rtcweb isn't running through the same admission control, this=20 > requires additional PHBs. Some carriers may have deployed DiffServ=20 > already, when rtcweb starts to use it. I think that you'll need admission control for EF and AFx1 PHBs otherwise y= ou'll end up with best-effort behavior in overload situations... Regards, Roland _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Thu Jun 19 10:52:30 2014 Return-Path: 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 AD8AC1A02E0; Wed, 18 Jun 2014 11:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 5F0wecDvr0lM; Wed, 18 Jun 2014 11:26:38 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D5B1A02D8; Wed, 18 Jun 2014 11:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4614; q=dns/txt; s=iport; t=1403115998; x=1404325598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9vzcqOv9TIRC0Yf0UHJZ2ZmQYqsCak0slbKL6hdx8XQ=; b=mr1wVtpLsstXfzQXboGrCZZ58L/OZfm/1tpvcIlFr9HwU/wn58VLf8Du 0//Ks13RsferXoI3tKJQO0nmjzUjp8GpZ5fvIujcr8FctD5jxhDiYP7p4 8tVpuQ6O7wpbI0YIFQq/yCsPtMJd91qAStl1dxYn1Bl84YYV0J3sttwum k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAIAKLYoVOtJA2J/2dsb2JhbABaDoJ/UlqqBwwBAQEBAQEFAZkoAYELFnWEAwEBAQQ6PwwEAgEIEQQBAQsDEQkHMhQJCAIEAQ0FCIg6Dc0sF4ViiGIxBwaDJ4EWBJwGkhWDAEKCMA X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="54158211" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 18 Jun 2014 18:26:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5IIQbL9030113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 18:26:37 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.38]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 13:26:36 -0500 From: "Subha Dhesikan (sdhesika)" To: "Bless, Roland (TM)" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 Thread-Index: AQHPhkO4fRrG2WYKYkKaZZx78AMF65t3Nd7A Date: Wed, 18 Jun 2014 18:26:36 +0000 Message-ID: References: <5399AD7F.20805@kit.edu> In-Reply-To: <5399AD7F.20805@kit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.209.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/-hHd0DWdHJ1IiXzCHYern9mq9R4 X-Mailman-Approved-At: Thu, 19 Jun 2014 10:52:28 -0700 Cc: "dart@ietf.org" Subject: Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 18:26:40 -0000 Roland,=20 Thanks for your comments. Inline: -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Bless, Roland (TM) Sent: Thursday, June 12, 2014 6:39 AM To: tsvwg@ietf.org Cc: dart@ietf.org Subject: [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 Hi, some remarks on draft-ietf-tsvwg-rtcweb-qos-00: Sec. 2: The mitigation for such action is through an authorization mechanism. An authorization mechanism alone is probably not sufficient, because DS bou= ndary nodes may need to police (e.g., remark/drop) incoming traffic accordi= ng to some agreed/negotiated traffic profile for some of the PHBs, e.g., th= e EF PHB does not work properly if its traffic class is overloaded (see bel= ow). SD: Agreed. The previous line states: " Therefore, the DSCP value may be re= marked at the network edge through policy to any other DSCP value, including best effort.". = There is already a mention that apckers may be remarked or dropped and any = additional mitigation is outside the scope of this draft. Sec. 4: The below uses the concept of a media flow, however these are commonly not equivalent to a transport flow, i.e. as defined by a 5-tuple (source address, destination address, source port, destination port, and protocol). I think one should try to use definitions that do not depend on the classif= ier type like 5-tuple, because as Brian already mentioned, for IPv6 a 3-tup= le (IPsrc, IPdst, Flow Label) may be sufficient and header fields of the 5-= tuple are not always accessible. I liked the definition of microflow in DiffServ as being an application-to-= application flow of packets, usually being identified by that well known 5-= tuple. For elements within the network microflows are usually the most fine= grained distinction level for flows (except when you apply multi-field cla= ssifier that do some DPI and add the SSRC etc.). (nit: is probably a word like "text" missing in the first cited sentence above?) Proper definitions for media flow, RTP session, transport flow etc. may help to avoid confusion, so maybe one could try to combine efforts with= draft-york-dart-dscp-rtp-00? SD:. There has been some discussion on the use of the word "media flow". B= etween the webrtc group and tsvwg, these words are defined or being defined= . I will further check on it. Sec. 5: SHOULD use these values to mark the appropriate media packets. More information on EF can be found in [RFC3246]. More information on AF can be found in [RFC2597]. The problem with using EF is that if too many EF marked packets are injecte= d into a DS domain, they probably void the EF properties for other users wi= thin this domain (background is that the service rate of EF packets on a gi= ven output interface must exceed their arrival rate at that interface over = long and short time intervals - this is usually checked by admission contro= l before use and policing at DS boundary nodes during use). Therefore, mayb= e some discussion w.r.t. RFC5865 http://tools.ietf.org/html/rfc5865 may be = useful. SD: Agreed that admission control is very useful and relevant. This draft i= s intended for the selection and use of the right DSCP for webrtc media flo= ws. There is a mention of over-subscription in the beginning.=20 The above table assumes that packets marked with CS1 is treated as "less than best effort". However, the treatment of CS1 is implementation dependent. If an implementation treats CS1 as other than "less than best effort", then the priority of the packets may be changed from what is intended. BTW, there is no "less than best effort" PHB defined, but a Lower Effort Pe= r-Domain Behavior (PDB) in RFC 3662 (http://tools.ietf.org /html/rfc3662). = This RFC is also the source for the recommendation of using the CS-1 codepo= int for that purpose, so you may considering referencing it. SD: Sounds good. Will do. If a packet enters a QoS domain that has no support for the above defined Data Types/Application (service) classes, then the network node at the edge will remark the DSCP value based on policies. Yes, but even if there is support for these classes traffic conditioning (e= .g., remarking/dropping etc.) may be necessary and applied. Remarking to di= fferent PHBs may also lead to packet reordering within a media flow?! SD: Remarking/dropping may occur, which is mentioned in the draft. =20 Thanks again for the review of the draft. Regards, Subha Regards, Roland From nobody Mon Jun 23 20:58:06 2014 Return-Path: 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 502FC1A0547 for ; Mon, 23 Jun 2014 20:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Fqrvi2vqd3wM for ; Mon, 23 Jun 2014 20:58:00 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF831B2823 for ; Mon, 23 Jun 2014 20:58:00 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id g10so6443428pdj.14 for ; Mon, 23 Jun 2014 20:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=59JXD15FR0Fr7pO+U6CbmoF9P5/1EIZiI17wFHUL5nE=; b=FELl7vwRCMSphTrGLT0XV6zFnbd4fXDGN1j7PpoowXhgsWe6pUo2bp95ODklHXO06B q3Ofl1mA987aPn1jKpMCt/BwEk3cylJDRX+2K8wHld9ykDe9jsWa6U8jLstfdyEQ+nKv aSmYLZtFyfmUz9bVzE8Owi/JYGV8I5hEx5AZvgTBLC7va01DsRDxKK5oHEmZMHU5HZOr 0Iyx5huwoAyzRHENVUks/jfRsmP3udJcs+2mvbcNVBO272wiNODH131JSE/hhuPN1kv7 nAEwKZ4einw2oa91Te6c1whX0wQ7yyTIRJGy4Lv+sCHwoORCQEdBYPY94507ZsG+Fj8O w2hg== X-Received: by 10.66.118.71 with SMTP id kk7mr33914009pab.147.1403582280358; Mon, 23 Jun 2014 20:58:00 -0700 (PDT) Received: from [192.168.178.23] (244.196.69.111.dynamic.snap.net.nz. [111.69.196.244]) by mx.google.com with ESMTPSA id qf10sm29388671pbc.23.2014.06.23.20.57.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 20:57:59 -0700 (PDT) Message-ID: <53A8F74A.9010108@gmail.com> Date: Tue, 24 Jun 2014 15:58:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dart@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/YT6q2xTaqCelcuc6W78v1gDwtnI Subject: [Dart] Diffserv survival... X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 03:58:02 -0000 This is really a comment on draft-ietf-tsvwg-rtcweb-qos, but I think the discussion should perhaps start here. draft-ietf-tsvwg-rtcweb-qos is aligned with a subset of RFC 4594, which is entirely reasonable since the update of that RFC seems to be on hold. However, in terms of what DSCPs have a good chance of actually crossing ISP boundaries in one piece, I think we should also look at draft-geib-tsvwg-diffserv-intercon. The main issue is that draft-geib suggests a quite small set of DSCPs that would hypothetically cross boundaries. Personally I think that is realistic and might even happen, whereas the set proposed in rtcweb-qos looks implausibly large to me, and very unlikely ever to be supported in peering relationships. Brian From nobody Tue Jun 24 01:30:36 2014 Return-Path: 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 228D71B299A; Tue, 24 Jun 2014 01:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 aWUgQ4kxtbUE; Tue, 24 Jun 2014 01:30:27 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B651B299F; Tue, 24 Jun 2014 01:30:26 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1WzM7R-0002lx-GS; Tue, 24 Jun 2014 10:30:21 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id B0523A804D5; Tue, 24 Jun 2014 10:30:24 +0200 (CEST) Message-ID: <53A93720.6040604@kit.edu> Date: Tue, 24 Jun 2014 10:30:24 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Subha Dhesikan (sdhesika)" , "tsvwg@ietf.org" References: <5399AD7F.20805@kit.edu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1403598621. Archived-At: http://mailarchive.ietf.org/arch/msg/dart/2GNzacrZFPb53putQ1KzGvtjkic Cc: "dart@ietf.org" Subject: Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 08:30:30 -0000 Hi Subha, thanks for you reply, see comments inline: > An authorization mechanism alone is probably not sufficient, because > DS boundary nodes may need to police (e.g., remark/drop) incoming > traffic according to some agreed/negotiated traffic profile for some > of the PHBs, e.g., the EF PHB does not work properly if its traffic > class is overloaded (see below). > > SD: Agreed. The previous line states: " Therefore, the DSCP value > may be remarked at the network edge through policy to any other DSCP > value, including best effort.". There is already a mention that > apckers may be remarked or dropped and any additional mitigation is > outside the scope of this draft. Unfortunately, this doesn't address my comment. DSCP remarking by provider policy is somewhat different from having policers installed (e.g., a token bucket w/ marker and dropper) that perform traffic conditioning according to some installed traffic profile. Static remarking of DSCPs may be caused by using a different DCSP/PHB mapping or lack of DiffServ support etc. which is slightly different. > The problem with using EF is that if too many EF marked packets are > injected into a DS domain, they probably void the EF properties for > other users within this domain (background is that the service rate of > EF packets on a given output interface must exceed their arrival rate at > that interface over long and short time intervals - this is usually > checked by admission control before use and policing at DS boundary > nodes during use). Therefore, maybe some discussion w.r.t. RFC5865 > http://tools.ietf.org/html/rfc5865 may be useful. > SD: Agreed that admission control is very useful and relevant. This > draft is intended for the selection and use of the right DSCP for > webrtc media flows. There is a mention of over-subscription in the > beginning. Sure, however, my point was that simply injecting traffic marked with a DSCP for a PHB that normally requires prior admission control is somewhat problematic: either guarantees for already admitted flows are violated or such traffic has to be dropped. > If a packet enters a QoS domain that has no support for the above > defined Data Types/Application (service) classes, then the network > node at the edge will remark the DSCP value based on policies. > > Yes, but even if there is support for these classes traffic > conditioning (e.g., remarking/dropping etc.) may be necessary and > applied. Remarking to different PHBs may also lead to packet > reordering within a media flow?! >SD: Remarking/dropping may occur, which is mentioned in the draft. Same issue as above: remarking caused by a static DS domain policy (PHBx -> PHBy) is different from remarking and other actions that boundary nodes may perform for individual flows according to traffic profiles. Regards, Roland From nobody Tue Jun 24 16:57:10 2014 Return-Path: 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 96D4D1B29ED for ; Tue, 24 Jun 2014 16:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 lFgfyUcnOwoy for ; Tue, 24 Jun 2014 16:57:05 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6CC1B29E7 for ; Tue, 24 Jun 2014 16:57:04 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5ONv1h9024571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2014 19:57:01 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s5ONv1h9024571 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1403654221; bh=abgfe9MYTDyQ0UJucbD6mqSBpzk=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=MTXXoGIkBennI1vX9X1wLoFkaUb38eUzSS+1nMoE3ffRUuCSZGMReVohrVBB64AuW gYNDZrfgrbtQ4ChUqKMfAaxCBpx02wg6S5F8XCSiwjw/Pi66VT+i0RHgOtmtcH1Lr2 gCUyclXhs3Anm5ABWZmrQk3Xk2MSGRi0bSiVuvvk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s5ONv1h9024571 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd52.lss.emc.com (RSA Interceptor); Tue, 24 Jun 2014 19:56:43 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5ONuhtG015254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jun 2014 19:56:43 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Tue, 24 Jun 2014 19:56:43 -0400 From: "Black, David" To: Brian E Carpenter , "dart@ietf.org" Date: Tue, 24 Jun 2014 19:56:41 -0400 Thread-Topic: [Dart] Diffserv survival... Thread-Index: Ac+PYIWnbrRaiNRvT3m15/mDmjoZ2wApywJg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077005028A@MX15A.corp.emc.com> References: <53A8F74A.9010108@gmail.com> In-Reply-To: <53A8F74A.9010108@gmail.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: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/YFoEekUl_LRp0FWTTyDahm-G_v8 Subject: Re: [Dart] Diffserv survival... X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 23:57:07 -0000 +1 as an individual (not tsvwg WG chair) - next version of draft-york is expected to have stronger text on this point (most DSCPs won't make it through many carrier networks). --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Monday, June 23, 2014 11:58 PM > To: dart@ietf.org > Subject: [Dart] Diffserv survival... >=20 > This is really a comment on draft-ietf-tsvwg-rtcweb-qos, > but I think the discussion should perhaps start here. >=20 > draft-ietf-tsvwg-rtcweb-qos is aligned with a subset of > RFC 4594, which is entirely reasonable since the update of that > RFC seems to be on hold. >=20 > However, in terms of what DSCPs have a good chance of actually > crossing ISP boundaries in one piece, I think we should also > look at draft-geib-tsvwg-diffserv-intercon. The main issue > is that draft-geib suggests a quite small set of DSCPs that > would hypothetically cross boundaries. Personally I think > that is realistic and might even happen, whereas the set > proposed in rtcweb-qos looks implausibly large to me, and > very unlikely ever to be supported in peering relationships. >=20 > Brian >=20 >=20 >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Wed Jun 25 06:24:04 2014 Return-Path: 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 630F51B2C70; Wed, 25 Jun 2014 06:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 zO-VEjL2XdDs; Wed, 25 Jun 2014 06:24:00 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id A088B1B2BE7; Wed, 25 Jun 2014 06:23:59 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 901CF2B44D5; Wed, 25 Jun 2014 14:23:58 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 411952B40E1; Wed, 25 Jun 2014 14:23:57 +0100 (BST) Message-ID: <53AACD6C.3010309@erg.abdn.ac.uk> Date: Wed, 25 Jun 2014 14:23:56 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dart@ietf.org, tsvwg WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/V0EBJGPoXQo-FebmasNedPc9TWk Subject: Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 13:24:02 -0000 A few comments in-line, following on... > Hi Subha, > > thanks for you reply, see comments inline: > >> An authorization mechanism alone is probably not sufficient, because >> DS boundary nodes may need to police (e.g., remark/drop) incoming >> traffic according to some agreed/negotiated traffic profile for some >> of the PHBs, e.g., the EF PHB does not work properly if its traffic >> class is overloaded (see below). >> >> SD: Agreed. The previous line states: " Therefore, the DSCP value >> may be remarked at the network edge through policy to any other DSCP >> value, including best effort.". There is already a mention that >> apckers may be remarked or dropped and any additional mitigation is >> outside the scope of this draft. > > Unfortunately, this doesn't address my comment. DSCP remarking by > provider policy is somewhat different from having policers installed > (e.g., a token bucket w/ marker and dropper) that perform traffic > conditioning according to some installed traffic profile. Static > remarking of DSCPs may be caused by using a different DCSP/PHB mapping > or lack of DiffServ support etc. which is slightly different. > +1 I think if the draft recommends admission-controlled PHBs then the draft needs to be clear that these particular flows may not be carried over the path (in addition to could be remarked to another PHB), which may require sort of fall-back mechanism (that's probably easy to realise). In addition though, these PHBs can (and seem likely to be) policed to a conformant rate. That will result in some form of loss (or remark), which suggests a congestion response (if the traffic is actually elastic), otherwise cease? >> The problem with using EF is that if too many EF marked packets are >> injected into a DS domain, they probably void the EF properties for >> other users within this domain (background is that the service rate of >> EF packets on a given output interface must exceed their arrival rate at >> that interface over long and short time intervals - this is usually >> checked by admission control before use and policing at DS boundary >> nodes during use). Therefore, maybe some discussion w.r.t. RFC5865 >> http://tools.ietf.org/html/rfc5865 may be useful. >> SD: Agreed that admission control is very useful and relevant. This >> draft is intended for the selection and use of the right DSCP for >> webrtc media flows. There is a mention of over-subscription in the >> beginning. > Sure, however, my point was that simply injecting traffic marked with > a DSCP for a PHB that normally requires prior admission control is > somewhat problematic: either guarantees for already admitted flows > are violated or such traffic has to be dropped. I see a potential problem here, if this becomes a default: If widely deployed using EF, the traffic will likely result in this DSCP being ignored/dropped (not given you EF properties0)or in breaking EF properties for other flows (which needs to be policed). >> If a packet enters a QoS domain that has no support for the above >> defined Data Types/Application (service) classes, then the network >> node at the edge will remark the DSCP value based on policies. >> >> Yes, but even if there is support for these classes traffic >> conditioning (e.g., remarking/dropping etc.) may be necessary and >> applied. Remarking to different PHBs may also lead to packet >> reordering within a media flow?! > >> SD: Remarking/dropping may occur, which is mentioned in the draft. > Same issue as above: remarking caused by a static DS domain policy > (PHBx -> PHBy) is different from remarking and other actions that > boundary nodes may perform for individual flows according to > traffic profiles. > > Regards, > Roland > In short... there are different pathologies (per packet conditioning action) when you send packets using EF, for traffic that the network provider didn't provision. This is a different behavior to remarking because the DSCP or PHB was not supported at a boundary. Gorry From nobody Wed Jun 25 16:27:27 2014 Return-Path: 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 C75D61A02EB; Wed, 25 Jun 2014 16:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 8Scw2sh1wJFN; Wed, 25 Jun 2014 16:27:23 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5AB1A0291; Wed, 25 Jun 2014 16:27:23 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so2215051pdj.8 for ; Wed, 25 Jun 2014 16:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dIP8mwMt8T+GJhCTvdsJyY4Y/+N2w6IbYv5dJlC/f+M=; b=IulVlSLgfZZRVeU/rL+28yf47gbyqIHkKVD04ZtdUV22wZe9ruhXqU/aWQbJOsFTN7 PKgrOmVdNlT1JSYov48BNsZA7aCgx54ajXVwhu7ot93G6VoO6lSf2ZVhDtojnvAkXyrT cvPHm2TPct0I2Zrb4FQcuIsQCn7t6eI94pP/XxeuV7Gc9IMfP3S89TWfGNFdwDVG604B Tz6nMkUwMYgkLFwHlsRIoVz8/yinACwofdCuR/U8rFW41D+iQZdik8SuDhZeCAzuI8cG jrJAijTRjoda/h+T9i+2+iPO3AA6pYaXnyPqYw23BMiemp6PpUdERpPNSZVowIcr9axo j0fA== X-Received: by 10.69.17.66 with SMTP id gc2mr16120057pbd.90.1403738843269; Wed, 25 Jun 2014 16:27:23 -0700 (PDT) Received: from [192.168.178.23] (153.199.69.111.dynamic.snap.net.nz. [111.69.199.153]) by mx.google.com with ESMTPSA id qk9sm24937114pac.16.2014.06.25.16.27.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 16:27:22 -0700 (PDT) Message-ID: <53AB5AE1.9040306@gmail.com> Date: Thu, 26 Jun 2014 11:27:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <53AACD6C.3010309@erg.abdn.ac.uk> In-Reply-To: <53AACD6C.3010309@erg.abdn.ac.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/xEdx_YV4eXZJ_ei3rqjNw89Qq_I Cc: dart@ietf.org, tsvwg WG Subject: Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 23:27:24 -0000 On 26/06/2014 01:23, Gorry Fairhurst wrote: ... >> Sure, however, my point was that simply injecting traffic marked with >> a DSCP for a PHB that normally requires prior admission control is >> somewhat problematic: either guarantees for already admitted flows >> are violated or such traffic has to be dropped. > > I see a potential problem here, if this becomes a default: If widely > deployed using EF, the traffic will likely result in this DSCP being > ignored/dropped (not given you EF properties0)or in breaking EF > properties for other flows (which needs to be policed). If you look at RFC3246 (the EF specification) you will find these words: the rate at which EF traffic is served at a given output interface should be at least the configured rate R, over a suitably defined interval, independent of the offered load of non-EF traffic to that interface. In other words, if you do not apply admission control to EF traffic, excess traffic *will* be discarded, because EF has a strict maximum rate. Brian From nobody Thu Jun 26 04:45:50 2014 Return-Path: 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 B6F881B2B48; Thu, 26 Jun 2014 04:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 QzGlZxOe6vLX; Thu, 26 Jun 2014 04:45:46 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3C21B2B47; Thu, 26 Jun 2014 04:45:46 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id DD8442B40E9; Thu, 26 Jun 2014 12:45:44 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 26 Jun 2014 12:45:45 +0100 Message-ID: In-Reply-To: <53AB5AE1.9040306@gmail.com> References: <53AACD6C.3010309@erg.abdn.ac.uk> <53AB5AE1.9040306@gmail.com> Date: Thu, 26 Jun 2014 12:45:45 +0100 From: gorry@erg.abdn.ac.uk To: "Brian E Carpenter" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/dart/pk1kuhlhcG4md2ppz1P7xbw3VB0 Cc: gorry@erg.abdn.ac.uk, dart@ietf.org, tsvwg WG Subject: Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 11:45:47 -0000 > On 26/06/2014 01:23, Gorry Fairhurst wrote: > ... >>> Sure, however, my point was that simply injecting traffic marked with >>> a DSCP for a PHB that normally requires prior admission control is >>> somewhat problematic: either guarantees for already admitted flows >>> are violated or such traffic has to be dropped. >> >> I see a potential problem here, if this becomes a default: If widely >> deployed using EF, the traffic will likely result in this DSCP being >> ignored/dropped (not given you EF properties0)or in breaking EF >> properties for other flows (which needs to be policed). > > If you look at RFC3246 (the EF specification) you will find > these words: > > the rate at which EF > traffic is served at a given output interface should be at least the > configured rate R, over a suitably defined interval, independent of > the offered load of non-EF traffic to that interface. > > In other words, if you do not apply admission control to > EF traffic, excess traffic *will* be discarded, because EF > has a strict maximum rate. > > Brian > Right - so EF is a useful service for many things - but my comment related to whether widely-deployed web apps should be recommending a default EF DSCP for their critical traffic? Gorry