From mallman@icir.org Mon Jan 7 10:36:20 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2773521F8A2F for ; Mon, 7 Jan 2013 10:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3ylKuHurCdW for ; Mon, 7 Jan 2013 10:36:19 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id AF9BA21F8A11 for ; Mon, 7 Jan 2013 10:36:19 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r07IaJtR023649 for ; Mon, 7 Jan 2013 10:36:19 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 153A359346A for ; Mon, 7 Jan 2013 13:36:19 -0500 (EST) To: tsv-area@ietf.org From: Mark Allman Subject: bufferbloat paper Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Smoke On the Water X-URL-0: http://www.icir.org/mallman-files/Document30997.docx X-URL-1: http://www.icir.org/mallman-files/Document60975.pdf X-URL-2: http://www.icir.org/mallman-files/Document83135.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma5539-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 07 Jan 2013 13:36:19 -0500 Sender: mallman@icir.org Message-Id: <20130107183619.153A359346A@lawyers.icir.org> X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 18:36:20 -0000 ----------ma5539-1 Content-Type: text/plain Content-Disposition: inline [I tried to post this in a couple places to ensure I hit folks who would be interested. If you end up with multiple copies of the email, my apologies. --allman] I know bufferbloat has been an interest of lots of folks recently. So, I thought I'd flog a recent paper that presents a little data on the topic ... Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer Communication Review, 43(1), January 2013. http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf Its an initial paper. I think more data would be great! allman -- http://www.icir.org/mallman/ ----------ma5539-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlDrFaMACgkQWyrrWs4yIs6nJwCaAxd0c1H6t+X1lU0Y0CrhEkUQ gBIAoJ68N8zmV07A2xNTd/sykbnD/d/Y =22Uf -----END PGP SIGNATURE----- ----------ma5539-1-- From touch@isi.edu Thu Jan 24 11:35:36 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E1B11E80A5; Thu, 24 Jan 2013 11:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGf7BgYgBWV8; Thu, 24 Jan 2013 11:35:36 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2375811E80A3; Thu, 24 Jan 2013 11:35:36 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r0OJZ5Ni006195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jan 2013 11:35:05 -0800 (PST) Message-ID: <51018CE9.3030700@isi.edu> Date: Thu, 24 Jan 2013 11:35:05 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Allison Mankin Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 6man@ietf.org, Transport Area , IETF Discuss , Transport Directorate X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 19:35:37 -0000 FWIW, this document includes text that somewhat defeats the previous recommendations of TCPM regarding RFC5927. RFC5927 includes specific text indicating that the techniques described are being documented, but that the TCP standard was NOT being changed to include those ICMP validation checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. Joe From fgont@si6networks.com Thu Jan 24 16:13:17 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470A621F850C; Thu, 24 Jan 2013 16:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MumQoqbCd5nj; Thu, 24 Jan 2013 16:13:16 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 84A2C21F84F6; Thu, 24 Jan 2013 16:13:04 -0800 (PST) Received: from [190.174.155.31] (helo=[192.168.1.43]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TyWuD-0004gT-NB; Fri, 25 Jan 2013 01:12:30 +0100 Message-ID: <5101A671.4090906@si6networks.com> Date: Thu, 24 Jan 2013 18:24:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joe Touch Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03 References: <51018CE9.3030700@isi.edu> In-Reply-To: <51018CE9.3030700@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Transport Directorate , 6man@ietf.org, Transport Area , Allison Mankin , IETF Discuss X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 00:13:17 -0000 Joe, On 01/24/2013 04:35 PM, Joe Touch wrote: > FWIW, this document includes text that somewhat defeats the previous > recommendations of TCPM regarding RFC5927. > > RFC5927 includes specific text indicating that the techniques described > are being documented, but that the TCP standard was NOT being changed to > include those ICMP validation checks. > > This document states that: > > Many implementations fail to perform validation checks on the > received ICMPv6 error messages, as recommended in Section 5.2 of > [RFC4443] and [RFC5927]. Are we fine if I remove "and [RFC5927]"? -- Because RFC4443 does recommend that ICMPv6 messages be validated. > I.e., the second RFC does NOT recommend changes; it documents them. This > document should be VERY carefully reviewed to ensure that it does not > undo the previous TCPM concerns about these techniques. We can remove "and [RFC5927]" or change it to "...Section 5.2 of [RFC4443] and documented in [RFC5927]" Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Thu Jan 24 16:19:59 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223CE11E809B; Thu, 24 Jan 2013 16:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRlgpr+bZha3; Thu, 24 Jan 2013 16:19:58 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3659C11E8099; Thu, 24 Jan 2013 16:19:58 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r0P0JW5Q001300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jan 2013 16:19:32 -0800 (PST) Message-ID: <5101CF94.4070208@isi.edu> Date: Thu, 24 Jan 2013 16:19:32 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fernando Gont Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03 References: <51018CE9.3030700@isi.edu> <5101A671.4090906@si6networks.com> In-Reply-To: <5101A671.4090906@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Transport Directorate , 6man@ietf.org, Transport Area , Allison Mankin , IETF Discuss X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 00:19:59 -0000 On 1/24/2013 1:24 PM, Fernando Gont wrote: > Joe, > > On 01/24/2013 04:35 PM, Joe Touch wrote: >> FWIW, this document includes text that somewhat defeats the previous >> recommendations of TCPM regarding RFC5927. >> >> RFC5927 includes specific text indicating that the techniques described >> are being documented, but that the TCP standard was NOT being changed to >> include those ICMP validation checks. >> >> This document states that: >> >> Many implementations fail to perform validation checks on the >> received ICMPv6 error messages, as recommended in Section 5.2 of >> [RFC4443] and [RFC5927]. > > Are we fine if I remove "and [RFC5927]"? -- Because RFC4443 does > recommend that ICMPv6 messages be validated. Sure. >> I.e., the second RFC does NOT recommend changes; it documents them. This >> document should be VERY carefully reviewed to ensure that it does not >> undo the previous TCPM concerns about these techniques. > > We can remove "and [RFC5927]" or change it to "...Section 5.2 of > [RFC4443] and documented in [RFC5927]" That might do it, but it would be useful if another pair of eyes would check. Joe > > Thoughts? > > Thanks, > From touch@isi.edu Thu Jan 24 17:59:39 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FCC11E80DC; Thu, 24 Jan 2013 17:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lGKiHHsV0Hu; Thu, 24 Jan 2013 17:59:38 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9B64611E80D9; Thu, 24 Jan 2013 17:59:38 -0800 (PST) Received: from [128.9.184.216] ([128.9.184.216]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r0P1x0pu026227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jan 2013 17:59:02 -0800 (PST) Message-ID: <5101E6E4.8080407@isi.edu> Date: Thu, 24 Jan 2013 17:59:00 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Allison Mankin Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03 References: <51018CE9.3030700@isi.edu> <5101A671.4090906@si6networks.com> <5101CF94.4070208@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 6man@ietf.org, Transport Area , IETF Discuss , Transport Directorate X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 01:59:39 -0000 Thanks - I wasn't positive about the second one. Glad to have it resolved quickly. Joe On 1/24/2013 5:57 PM, Allison Mankin wrote: > Joe and Fernando, > > I just looked at how RFC 5297 is handled in the draft, to be that other > pair of eyes. > > The first fix is right, to remove reference to RFC 5297 from that > sentence entirely. > > Allison > > On Jan 24, 2013 7:19 PM, "Joe Touch" > wrote: > > > > > > > > On 1/24/2013 1:24 PM, Fernando Gont wrote: > >> > >> Joe, > >> > >> On 01/24/2013 04:35 PM, Joe Touch wrote: > >>> > >>> FWIW, this document includes text that somewhat defeats the previous > >>> recommendations of TCPM regarding RFC5927. > >>> > >>> RFC5927 includes specific text indicating that the techniques described > >>> are being documented, but that the TCP standard was NOT being > changed to > >>> include those ICMP validation checks. > >>> > >>> This document states that: > >>> > >>> Many implementations fail to perform validation checks on the > >>> received ICMPv6 error messages, as recommended in Section 5.2 of > >>> [RFC4443] and [RFC5927]. > >> > >> > >> Are we fine if I remove "and [RFC5927]"? -- Because RFC4443 does > >> recommend that ICMPv6 messages be validated. > > > > > > Sure. > > > > > >>> I.e., the second RFC does NOT recommend changes; it documents them. > This > >>> document should be VERY carefully reviewed to ensure that it does not > >>> undo the previous TCPM concerns about these techniques. > >> > >> > >> We can remove "and [RFC5927]" or change it to "...Section 5.2 of > >> [RFC4443] and documented in [RFC5927]" > > > > > > That might do it, but it would be useful if another pair of eyes > would check. > > > > Joe > > > >> > >> Thoughts? > >> > >> Thanks, > >> > From jsaldana@unizar.es Wed Jan 30 09:21:38 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F09821F8569; Wed, 30 Jan 2013 09:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpkeVvbMBDFn; Wed, 30 Jan 2013 09:21:16 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id AC03221F85B6; Wed, 30 Jan 2013 09:21:14 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r0UHL6li031987; Wed, 30 Jan 2013 18:21:07 +0100 From: "Jose Saldana" To: , Subject: About the possibility of having a BOF about TCMTF in IETF87 Date: Wed, 30 Jan 2013 18:21:11 +0100 Organization: Universidad de Zaragoza Message-ID: <003001cdff0e$33658a50$9a309ef0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: es Thread-index: Ac3/DjLNZdfLStP/QW+3XuE3RhqbAA== X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: Gonzalo Camarillo , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:21:38 -0000 Hi all. With this e-mail I would like to socialize TCMTF (Tunneling, Compressing = and Multiplexing Traffic Flows) within the IETF. We have the idea of = presenting a BOF proposal for IETF 87 in Berlin (July-August), with the aim of = creating a Working Group. In this message I will talk about the problem we are trying to solve, = and I will try to summarize the story of TCMTF within the IETF. - The main idea (see also the Charter proposal below) is to define a = method for saving bandwidth in real-time services which use tiny packets. Some examples of these services are online games, viceoconference, in = addition to VoIP. The overhead of the packets of these services is significant, so = the efficiency can be increased when a number of flows share the same path: packets belonging to different flows can be grouped together, adding a = small multiplexing delay as a counterpart. Currently, there exists an = efficiency improvement method for VoIP using RTP: RFC4170 (TCRTP). It considers = header compression by means of ECRTP; multiplexing by means of PPPMux; and tunneling by means of L2TPv3. However, in the last years, emerging = real-time services which do not use UDP/RTP protocols have become popular: some of them use UDP or even TCP. In addition, new header compression methods = have been defined (ROHC). So widening the scope of RFC4170 in order to = consider not only UDP/RTP but also other protocols is seen as convenient. The = same three layers would be used: header compression, multiplexing and = end-to-end tunneling. Some examples of the scenarios where grouping packets is possible are: aggregation networks of a network operator; a tunnel between two = premises of the same company; the access connection of an Internet Caf=E9 including = a high number of VoIP/gaming flows; an agreement between two network operators could allow them to compress a number of flows they are exchanging = between a pair of Internet Routers; a satellite connection used for collecting the data of a high number of sensors; etc.=20 - The story: * A first draft was written with cooperation of some people from = Transport and RAI Areas. Dan Wing, one of the authors of RFC4170, is also participating on TCMTF from the very beginning. This is the first = version (Feb 2012) http://tools.ietf.org/id/draft-saldana-tsvwg-tcmtf-00.txt * It was presented in the TSVWG session (Transport Area) IETF-83, Paris, March 27th 2012: http://www.ietf.org/proceedings/83/minutes/minutes-83-tsvwg.txt. The presentation is here: http://diec.unizar.es/~jsaldana/personal/present-saldana-tsvwg-tcmtf_v2.p= df * A specific mailing list was created (July 10th 2012): https://www.ietf.org/mailman/listinfo/tcmtf * A second draft was submitted (Dec 12th 2012), " Maximum Tolerable = Delays when using Tunneling Compressed Multiplexed Traffic Flows": http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ * This is the current version of the initial draft: https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. The number = of authors and contributors has been increased. - Many people have participated in the mailing list, mainly from network operators, network equipment manufacturers, a Space Agency (DLR) and Academia. - And finally, this is the current version of the Charter Proposal. We = have discussed and polished it in the list (http://www.ietf.org/mail-archive/web/tcmtf/current/threads.html), and = we have arrived to this agreement: *Description of Working Group v4* 1. In the last years we are witnessing the raise of new real-time = services that use the Internet for the delivery of interactive multimedia applications: VoIP, videoconferencing, telemedicine, video vigilance, = online gaming, etc. Due to the need of interactivity, many of these services = use small packets (some tens of bytes), since they have to send frequent = updates to the other extreme of the communication. Therefore, its overhead is significant, and it becomes even higher when IPv6 is used, since the = basic IPv6 header is twice the size of the IPv4 one. In addition, some other services also send small packets, but they are not delay-sensitive = (e.g., instant messaging, m2m packets sending collected data in sensor networks using wireless or satellite scenarios). 2. The efficiency cannot be increased by the inclusion of a higher = number of samples in a single packet, since this would harm the delay requirements = of the service. But there exist some scenarios in which a number of flows = share the same path. In this case, packets belonging to different flows can be grouped together, adding a small multiplexing delay as a counterpart of bandwidth saving. This delay will have to be maintained under some = threshold in order to grant the delay requirements. Some examples of the scenarios where grouping packets is possible are: aggregation networks of a = network operator; a tunnel between two premises of the same company; the access connection of an Internet Caf=E9 including a high number of VoIP/gaming = flows; an agreement between two network operators could allow them to compress = a number of flows they are exchanging between a pair of Internet Routers; = a satellite connection used for collecting the data of a high number of sensors; etc. 3. VoIP using RTP is a clear example of a real-time service using small packets with high overhead. In order to improve efficiency, RFC4170 = (TCRTP) defined a method for grouping packets when a number of flows share a = path, considering three different layers: header compression by means of = ECRTP; multiplexing by means of PPPMux; tunneling by means of L2TPv3. 4. However, in the last years, emerging real-time services which do not = use UDP/RTP have become popular: some of them use UDP or even TCP. So there = is a need of widening the scope of RFC4170 in order to consider not only = UDP/RTP but also other protocols. The same structure of three layers will be considered: - Header compression: Taking into account that real-time applications = use different headers (RTP/UDP, UDP or even TCP), different protocols can be used: no compression, ECRTP, IPHC and ROHC. - Multiplexing: If a number of flows share a path between an origin and = a destination, a multiplexer can build a bigger packet in which a number = of payloads share a common header. A demultiplexer is then necessary at the = end of the common path, so as to rebuild the packets as they were originally sent. PPPMux will be the main option. Other ones are not discarded. - Tunneling will be used to send the multiplexed packets end-to-end. The options in this layer are L2TP, GRE and MPLS. 5. So the first objective of this group is to specify the protocol stack = for tunneling, compressing and multiplexing traffic flows (TCMTF). Since standard protocols are being used at each layer, the signaling methods = of those protocols will be used. Interactions with the Working Groups and = Areas in which these protocols are developed can be expected. However, the development of new compressing, multiplexing or tunneling protocols is = not an objective of this Working Group. In addition, since the current RFC = 4170 would be considered as one of the options, this RFC could be obsoleted. 6. As a first objective, a document (A) will define the different = options which can be used at each layer. Specific problems caused by the = interaction between layers will have to be issued, and suitable extensions may have = to be added to the involved protocols. 7. If a pair multiplexer/de- multiplexer want to establish a tunnel, = they have first to use a mechanism to negotiate which concrete option would = they use in each layer: header compression, multiplexing and tunneling. This = will depend on the protocols that each extreme implements at each level, and = in the scenario. So document (A) will also include a negotiation mechanism = to decide the options to use at each layer (header compression, = multiplexing and tunneling) between multiplexer and de-multiplexer, and a mechanism = to setup/release a tunnel between a multiplexer and a de-multiplexer. 8. As a counterpart of the bandwidth saving, TCMTF may add some delay = and jitter. This is not a problem for the services which are not sensitive = to delay. However, regarding delay-sensitive services, the Working Group = will also develop a document (B) with useful recommendations in order to = decide which packet flows can or can not be multiplexed and how. The document = (B) will present a list of available traffic classification methods which = can be used for identification of the service or application to which a = particular flow belongs, as well as recommendations of the maximum delay and jitter = to be added depending of the identified service or application. 9. If other interesting features are identified, the group would = re-charter and include them, e.g., a mechanism for a multiplexer to discover a de-multiplexer, and vice versa; a mechanism to select an optimal = multiplexer and a de-multiplexer when there are more than one muxer/de-muxer for a = flow; dynamically applying TCMTF: a higher entity in charge of deciding when = and where, applying or not TCMTF, and what kind of TCMTF, and what = multiplexing period. Additional methods for estimating delay would also be required. 10. In addition, specific uses of TCMTF, such as in wireless and = satellite scenarios, could be considered, and it will be studied whether = modifications or extensions are required on the protocol. 11. Interactions with other Working Groups can be expected, since TCMTF = uses already defined protocols for compression, multiplexing and tunneling = (ROHC, PPPMux, MPLS, GRE, L2TP). =20 *Goals and Milestones* Specification of TCMTF protocol stack (A) and signaling mechanisms. Recommendations (B) of using existing traffic classification methods, maximum delay and jitter to add, depending on the service. ------------------ Thank you very much, Jose Saldana > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > Martin Stiemerling > Enviado el: martes, 29 de enero de 2013 12:54 > Para: jsaldana@unizar.es > CC: wes@mti-systems.com; tcmtf@ietf.org; > Gonzalo.Camarillo@ericsson.com > Asunto: Re: [tcmtf] Improved version of the TCMTF Charter proposal = (v3) >=20 > Hi Jose, >=20 > On 01/29/2013 11:57 AM, Jose Saldana wrote: > > Yes, Martin. The idea is that many interested people may attend IETF > > Berlin in July: at least I know about interested people from U. > > Zaragoza, DLR, Telefonica, U. Zagreb, U. Stuttgart, who could attend > > that BoF. And also co-authors from Cisco (Dan, Michael, and perhaps > > Muthu) may be there. Well, these are the news I have. In addition, > > Mirko and I would also be able to organize the "online games traffic tutorial > there". >=20 > So Berlin is the place to make a BoF. >=20 > > > > So is your idea to have a BoF for discussing the TCMTF WG in Berlin? > > Do you prefer that possibility instead of the "DISPATCH" option that > > Gonzalo suggested? If you confirm that, we would take it into = account > > in order to organize the summer calendar. >=20 > We do not have the DISPATCH option in the Transport Area. >=20 > My proposal is to start socializing the idea within the IETF and to = aim for a BoF > in Berlin. Sending the proposal to the TSVAREA list might be a good = start. >=20 > Martin >=20 > > > > Thanks a lot, > > > > Jose > > PS: This is the option that Gonzalo suggested to Wes (November = 29th): > > "Hi Wes, > > > > sure. When the proponents have a charter proposal ready, feel free = to > > send it to the TSVAREA list for comments while informing all the = other > > lists. If you want, I can take care of informing the DISPATCH list > > pointing to the relevant message in the TSVAREA list when you send = it. > > > > With respect to where discussions should take place, DISPATCH > > participants will find it easier to send comments on the DISPATCH = list. > > However, if sending comments requires subscribing to a different = list > > and sending comments to a different crowd, many may not bother > > commenting. I can monitor the discussions in DISPATCH and send you a > > summary if needed. Since we are talking about very few lists, it > > should be relatively easy to keep things under control. > > > > Cheers, > > > > Gonzalo" > >> -----Mensaje original----- > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En = nombre > >> de Martin Stiemerling Enviado el: martes, 29 de enero de 2013 11:39 > >> Para: FERNANDO PASCUAL BLANCO > >> CC: wes@mti-systems.com; tcmtf@ietf.org; Matteo.Berioli@dlr.de; > >> Gonzalo.Camarillo@ericsson.com; jsaldana@unizar.es > >> Asunto: Re: [tcmtf] Improved version of the TCMTF Charter proposal > >> (v3) > >> > >> Hi all, > >> > >> The BoF deadline for the upcoming meeting was Jan 28. > >> > >> Further, my understanding is the relevant proponents cannot make it > >> to the IETF meeting in March in Orlando, but that there is a plan = for > >> the IETF meeting in Berlin in July 2013. > >> > >> Martin > >> > >> On 01/29/2013 11:13 AM, FERNANDO PASCUAL BLANCO wrote: > >>> Hi all, > >>> > >>> In my opinion the WG is needed. TCMTF discussion have > >>> reach enough interest and enough roadmap to have a room for = itself, > >>> at least an small room. As Jose said, there are two enough active > >>> drafts and there is potentially room for three more, and I think > >>> this is a justification by itself. > >>> On the other hand, I also think that we are problem centered. > >>> At least being in a network operation feet I find TCMTF useful = enough. > >>> > >>> Regards, > >>> > >>> Fernando Pascual Blanco > >>> Telef=F3nica Global Resources > >>> Network Automation and Dynamization > >>> TECHNOLOGY PEOPLE GROUP > >>> F +34913128779 > >>> M +34682005168 > >>> fpb@tid.es > >>> > >>> > >>> > >>> > >>> On 29/01/13 10:56, "Jose Saldana" wrote: > >>> > >>>> Matteo, > >>>> > >>>> Thanks a lot. Well, in this case, I don't agree with you (only in > >>>> this case). > >>>> > >>>> The idea with TCMTF was to create a "small" Working Group, the = same > >>>> way as they are created in other Areas (e.g. RAI). > >>>> > >>>> As Wes said in November, " In my opinion, it is something a > >>>> separate WG should be created to handle, and not something to try > >>>> to do inside the TSVWG, since there are already a handful of = things > >>>> TSVWG is wrestling with, and it creates too much "context > >>>> switching" to have a lot of unrelated topics under work there." > >>>> > >>>> The question is that the TSVWG group has a lot of interesting > >>>> things now, and it would be better to discuss TCMTF separately. = In > >>>> fact, since the Summer, we are discussing it in another mailing > >>>> list. This is good, but in fact many people from TSVWG have not > >>>> followed our > >> discussion. > >>>> > >>>> In addition, a lot of time has passed. TCMTF draft was presented = in > >>>> Paris > >>>> 10 > >>>> months ago. A lot of people from many institutions have become > >>>> interested on it. We have two drafts and three more = possibilities. > >>>> > >>>> Neither am I an expert on IETF, but I understand that things have > >>>> some > >>>> "momentum": if you let time go by, people may lose their = interest. > >>>> And curently interest does exist, as we have seen in the list. So > >>>> why > > not > >> now? > >>>> > >>>> In addition, the new version of the Charter is more > >>>> problem-centered (I hope). > >>>> > >>>> Thanks and best regards, > >>>> > >>>> Jose > >>>> > >>>> > >>>>> -----Mensaje original----- > >>>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En > >> nombre > >>>>> de Matteo.Berioli@dlr.de Enviado el: martes, 29 de enero de 2013 > >>>>> 9:18 > >>>>> Para: wes@mti-systems.com; jsaldana@unizar.es > >>>>> CC: tcmtf@ietf.org; Gonzalo.Camarillo@ericsson.com; > >>>>> Martin.Stiemerling@neclab.eu > >>>>> Asunto: Re: [tcmtf] Improved version of the TCMTF Charter = proposal > >>>>> (v3) > >>>>> > >>>>> Dear all, > >>>>> > >>>>> I don't have a huge experience in IETF, but feel it is important > >>>>> to > >>>> express my > >>>>> opinion this time. > >>>>> I have the feeling building a new WG is a bit premature, > >>>>> considering that > >>>> we > >>>>> just have an Internet draft. > >>>>> I also find the discussion a bit documents-driven, rather than > >>>>> problems- driven. > >>>>> IMHO we could wait a bit, before creating the WG, to see whether > >>>>> the ideas we have really solve real-world problems. > >>>>> > >>>>> That's it. Hope this helps. > >>>>> > >>>>> Matteo > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On > >>>>> Behalf Of Wesley Eddy > >>>>> Sent: 24 January 2013 06:16 > >>>>> To: jsaldana@unizar.es > >>>>> Cc: tcmtf@ietf.org; Gonzalo Camarillo; Martin Stiemerling > >>>>> Subject: Re: [tcmtf] Improved version of the TCMTF Charter > >>>>> proposal > >>>>> (v3) > >>>>> > >>>>> On 1/23/2013 6:58 AM, Jose Saldana wrote: > >>>>>> Hello all. > >>>>>> > >>>>>> > >>>>>> > >>>>>> After reading the messages in the mailing list, I think we have > >>>>>> arrived to a solution. Each of the documents has been discussed > >>>>>> in a separate thread, so I have tried to take everything into account. > >>>>>> Documents (A) and (B) would be in the Charter. Documents (C) = and > >>>>>> (D) would only be announced as possibilities for re-chartering, > >>>>>> and Document (E) can wait a little. > >>>>>> > >>>>>> ... > >>>>> > >>>>> > >>>>> In my opinion, this is decent, though here are two criticisms: > >>>>> > >>>>> (1) In my opinion, it focuses too much on documents to be = produced, > >>>>> rather than fully and clearly motivating why the working = group > >>>>> is needed (i.e. to solve a problem, not to develop = documents), > >>>>> how it's scope is delimited (i.e. what it *won't* touch = isn't > >>>>> clear to me, along with what other areas/WGs need to be > >>>>> coordinated with), and what the end-goal is. > >>>>> > >>>>> (2) There's a focus on defining technical solutions prior to the > >>>>> mention of fleshing out and totally defining the use cases = / > >>>>> requirements. In my opinion, that appears backwards :). > >>>>> > >>>>> That said, I'm generally supportive of this work. In my = opinion, > >>>>> as an > >>>> AD, we > >>>>> would normally feel better having a BoF before forming a WG, for > >>>>> two reasons (1) to get other areas (e.g. RAI) to be aware of > >>>>> what's being proposed, and (2) to vet that there really is a > >>>>> community of stakeholders that are engaged to do the work. In > >>>>> this case, I think the 2nd point is evident from the mailing = list, > >>>>> and I don't have a concern about it at all. > >>>> I > >>>>> think the 1st point can be addressed through the responsible AD > >>>>> coordinating with the IESG and the directorates or area mailing > >>>>> lists that related areas have. > >>>>> Since I'm going away as an AD though, what really matters at the > >>>>> moment is what Martin thinks :). > >>>>> > >>>>> -- > >>>>> Wes Eddy > >>>>> MTI Systems > >>>>> _______________________________________________ > >>>>> tcmtf mailing list > >>>>> tcmtf@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>>>> _______________________________________________ > >>>>> tcmtf mailing list > >>>>> tcmtf@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>>> > >>>> _______________________________________________ > >>>> tcmtf mailing list > >>>> tcmtf@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>> > >>> > >>> ________________________________ > >>> > >>> Este mensaje se dirige exclusivamente a su destinatario. Puede > >>> consultar > >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico = en el > >> enlace situado m=E1s abajo. > >>> This message is intended exclusively for its addressee. We only = send > >>> and > >> receive email on the basis of the terms set out at: > >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > >>> > >> > >> -- > >> martin.stiemerling@neclab.eu > >> > >> NEC Laboratories Europe - Network Research Division NEC Europe > >> Limited Registered Office: NEC House, 1 Victoria Road, London W3 = 6BL > >> Registered in England 283 > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > >=20 > -- > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL = Registered in > England 283 _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From lars@netapp.com Wed Jan 30 09:46:18 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C0821F8867; Wed, 30 Jan 2013 09:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wXvdInk1Fd7; Wed, 30 Jan 2013 09:46:18 -0800 (PST) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id F135521F886C; Wed, 30 Jan 2013 09:46:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,569,1355126400"; d="scan'208";a="238526612" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 30 Jan 2013 09:45:54 -0800 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0UHjqG1003048; Wed, 30 Jan 2013 09:45:53 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Wed, 30 Jan 2013 09:45:52 -0800 From: "Eggert, Lars" To: "" Subject: Re: About the possibility of having a BOF about TCMTF in IETF87 Thread-Topic: About the possibility of having a BOF about TCMTF in IETF87 Thread-Index: Ac3/DjLNZdfLStP/QW+3XuE3RhqbAAARoDYA Date: Wed, 30 Jan 2013 17:45:52 +0000 Message-ID: References: <003001cdff0e$33658a50$9a309ef0$@unizar.es> In-Reply-To: <003001cdff0e$33658a50$9a309ef0$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcmtf@ietf.org" , "tsv-area@ietf.org" , Gonzalo Camarillo , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:46:18 -0000 Hi, On Jan 30, 2013, at 18:21, Jose Saldana wrote: > The main idea (see also the Charter proposal below) is to define a method > for saving bandwidth in real-time services which use tiny packets. ... > In addition, new header compression methods have > been defined (ROHC). So widening the scope of RFC4170 in order to conside= r > not only UDP/RTP but also other protocols is seen as convenient. why an extension of 4170 and not new ROHC profiles? Lars From jsaldana@unizar.es Thu Jan 31 00:47:01 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874B421F85D0; Thu, 31 Jan 2013 00:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4W+-bOSVoaQ; Thu, 31 Jan 2013 00:47:00 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFA121F85CC; Thu, 31 Jan 2013 00:47:00 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r0V8ksSE017275; Thu, 31 Jan 2013 09:46:55 +0100 From: "Jose Saldana" To: "'Eggert, Lars'" References: <003001cdff0e$33658a50$9a309ef0$@unizar.es> In-Reply-To: Subject: RE: About the possibility of having a BOF about TCMTF in IETF87 Date: Thu, 31 Jan 2013 09:46:56 +0100 Organization: Universidad de Zaragoza Message-ID: <002c01cdff8f$88251430$986f3c90$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4VYfsQr5DqoVbCGYPdBLd2Eoe0AIPaXGhl/30MgA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 08:47:01 -0000 Hi, The idea is not improving header compression techniques here. Of course improvements in header compression are interesting, but there are other places for doing that. We only try to put together these three = "orthogonal layers": - Header compression - Multiplexing - Tunneling The question is that when you compress a single flow, you have to do it hop-by-hop (which implies a lot of processing in every node), or you can = add a tunnel in order to do it end-to-end. So if you have a single flow, you = are reducing overhead by means of header compression, but the tunnel is = adding overhead again. But there are scenarios where a number of flows share a path, so in that case you not only compress headers, but also put a number of packets = into a single bundle, and then the tunnel overhead is shared by all the = packets. Our idea is that RFC4170 can be extended to other services. But RFC4170 = is not only header compression but also multiplexing and tunneling. So the = same ROHC profiles for that services will be suitable for TCMTF. However, we = only want to use existing or new header compression methods. We do not intend = to develop new ones here. In this paper (http://diec.unizar.es/~jsaldana/personal/ottawa_ICC_2012_in_proc.pdf) = we presented some results of the obtained savings. For VoIP (RFC4170) we = could save up to 65% of the bandwidth. But for new emerging services, like = e.g., MMORPG games, the saving can be next to 60% (http://diec.unizar.es/~jsaldana/personal/sergei_SPECTS_2012_in_proc.pdf)= . So why not using the same idea in these new services? Does this answer your question? Best regards, Jose > -----Mensaje original----- > De: Eggert, Lars [mailto:lars@netapp.com] > Enviado el: mi=E9rcoles, 30 de enero de 2013 18:46 > Para: > CC: tsv-area@ietf.org; tcmtf@ietf.org; Gonzalo Camarillo; Martin Stiemerling > Asunto: Re: About the possibility of having a BOF about TCMTF in = IETF87 >=20 > Hi, >=20 > On Jan 30, 2013, at 18:21, Jose Saldana wrote: > > The main idea (see also the Charter proposal below) is to define a > > method for saving bandwidth in real-time services which use tiny packets. > ... > > In addition, new header compression methods have been defined = (ROHC). > > So widening the scope of RFC4170 in order to consider not only = UDP/RTP > > but also other protocols is seen as convenient. >=20 > why an extension of 4170 and not new ROHC profiles? >=20 > Lars